daves Posted September 19, 2011 Posted September 19, 2011 Hi I have the September release of the IDE and firmware. One of the things I was really looking forward to was the ability to have libraries of functions available to C programs. This is reportedly included in this version, but I am struggling a little. I have the following library under "C Language/Libraries/lib1", h and c files: void DoThing(int Value); #include #include // Global Rt/Gp Shared memory pointers //------------------------------------------------------------- // The following is a projpp created file from the User defines //------------------------------------------------------------- #include "../../Include/pp_proj.h" void DoThing(int Value) { char buffer [50]; sprintf(buffer, "Thing %d", Value); Send(2, buffer); } In a background C app I add #include "../../Libraries/lib1/lib1.h" and then I can happily call DoThing(1); Great. Now in a CPLC I can add the include line and the call to the function. The project builds and downloads with no errors. However I cannot start the CPLC any more (or it immediately bails out with no error status I can see) and it certainly does not execute the library function. Am I doing something wrong? Dave
Omron Forums Support Posted September 19, 2011 Posted September 19, 2011 I need to see your project. Send me an email (click on my username and select "Send CharlesP an Email"), and I'll reply, and then you can send me the project.
Omron Forums Support Posted September 19, 2011 Posted September 19, 2011 Dave, It's there in the release. When you install the released IDE check out the example ModbusLibExample under :\Program Files\Delta Tau Data Systems Inc\2.0\Power PMAC Suite\PowerPMACProjectExamples This example program will show how to use library functions. The idea is you will create the C lib which is set of common functions and then use it in the background C programs. Thanks, Atul
daves Posted September 19, 2011 Author Posted September 19, 2011 Thanks Charles. I am at home now (the UK working day has finished). I will send tomorrow.
daves Posted September 19, 2011 Author Posted September 19, 2011 Hi Atul, thanks for responding. Yes, I saw the Modbus example. This example only uses Background C apps as well. I have no problem getting that to work (maybe that was not clear from my original post where I said I "can happily" call that). I am having difficulty in using it in CPLCs, either BgCplcs or RtiCplc. Dave
Sina.Sattari Posted September 21, 2011 Posted September 21, 2011 Daves, I just talked to one of the developers and here is what he responded about using library functions in BGCPLC and RTICPLC: The BGCPLC and RTICPLC are running in real-time and they are scheduled to run using the real-time scheduler. These libraries are compiled and can be used in background (non-real-time) space, but not in real-time. The RTICPLC and BGCPLC don't have a reference to these libraries, hence they would cause a run-time error and crash the real-time task scheduler. Regards,
dro Posted September 21, 2011 Posted September 21, 2011 Daves, Currently the Libraries are only compiled and linked with the Background C Applications. If you include your lib header file and call the function within BGCPLC or RTICPLCs, the code will compile, but it will crash the Power PMAC RT. The reason for the crash is that once a real time thread calls the BGCPLC or RTICPLC function, it won't be able to link to your Library functions at the runtime and it is going to crash. Please do not use your library functions within the CPLCs, since we are not linking those libraries. Regards Dro Daves, I just talked to one of the developers and here is what he responded about using library functions in BGCPLC and RTICPLC: The BGCPLC and RTICPLC are running in real-time and they are scheduled to run using the real-time scheduler. These libraries are compiled and can be used in background (non-real-time) space, but not in real-time. The RTICPLC and BGCPLC don't have a reference to these libraries, hence they would cause a run-time error and crash the real-time task scheduler. Regards,
daves Posted September 22, 2011 Author Posted September 22, 2011 Thanks for the replies. Currently the Libraries are only compiled and linked with the Background C Applications. This is disappointing. I am sure you can see how useful it would be to have a standard library of functions which can be shared between CApps and CPLCs. The project folder structure hints this is the intention. I will have to continue having my functions in .h files and #including them to each file. If you include your lib header file and call the function within BGCPLC or RTICPLCs, the code will compile, but it will crash the Power PMAC RT. The reason for the crash is that once a real time thread calls the BGCPLC or RTICPLC function, it won't be able to link to your Library functions at the runtime and it is going to crash. Please do not use your library functions within the CPLCs, since we are not linking those libraries. Perhaps this should not build or download. The BGCPLC and RTICPLC are running in real-time and they are scheduled to run using the real-time scheduler. These libraries are compiled and can be used in background (non-real-time) space, but not in real-time. The RTICPLC and BGCPLC don't have a reference to these libraries, hence they would cause a run-time error and crash the real-time task scheduler. The naming here is slightly confusing: 'Background CPLCs' are not run in 'Background Space' like 'Background Programs' but executed by the Real-Time scheduler (I guess something has to schedule them, "Writing C Programs in Power PMAC 2011-01.pdf" starts to explains this). I'll take your word for it and accept that Libraries currently do not work with things in the C Language folder except the Linux apps. I would suggest this would be a useful enhancement for the January release. Thanks for the explanations Dave
KEJR Posted September 23, 2011 Posted September 23, 2011 Dave, I understand that it is frustrating that some things in the PPMAC work one way and others in another. If you know a little about the underlying RTOS technologies (you might read up on xenomai RTOS) it makes sense, and it was good to see the responses from the folks at Delta tau explaining this. I am going to offer to answer your question in a different way and that is that you really don't ever need to use CPLCs or the script PLCs in my opinion. I've found I can do everything from a C app. If your preference is C (as mine is) then do everything in a C app with multiple threads and call motion programs when you need to do your motion. The reason for this is that in what DT calls the "Background C applications" (poor terminology... sorry guys) is really a full linux application, at least in the sense of console application that has access to the xenomai pthreads interface. I forget the terminology but basically you can spawn new threads that can then be scheduled by the realtime kernel xenomai. This is different than kernel RTOS threads, but I have found it to be very successful. You can configure them to use a FIFO scheduler that will wake up in 1ms time ticks just like the DT provided CPLCs are. The real benefit here is that your code can be compiled in one application object file that you have almost complete control over the execution of the threads. If you want to you can split your code into different files using the IDE and in that sense it is programmed like a traditional C application. I wrote some functions for creating new xenomai realtime threads in the "Background C applications" and have tested several threads running at 1ms intervals. I also have libraries that call motion programs (and deal with errors of said motion programs if they occurr), delays, digital IO functions, functions to interface to an HMI, etc. Currently my library is being compiled in every time using a #include, but I will be transitioning to the library interface they provide as soon as I install the new software. One other good thing about the background C apps is that you can access the filesystem if you need to. Sometimes I'll do this when an error occurs to write to a log file, etc. What happens is that when you call a "linux" type of command like file open or read, write, it kicks you back into being scheduled by the Linux kernel until you execute a real time command such as pthread_wait_np(NULL) or something like that. While this is all scary sounding, it just works. I have a main() function in my app that consists of calls to create threads and then a call to run. It is so clean looking you wouldn't think you are running an RTOS because the uglies get hidden by my library functions. If you want I can help you out in more detail. I took the time to write this because you sound like you want to program this like a "real" C program with libraries and I think this is the way to go for that. Try it as a test! I spent alot of time up front structuring my system and now it is the most integrated controller I've used especially since I can now write my applications with C instead of some modified proprietary garbage language based on VB, pascal, or worse. KEJR
Omron Forums Support Posted September 23, 2011 Posted September 23, 2011 KEJR, I am glad you have had such success in creating your own thread scheduling from the Background C Application. I would be interested in seeing what you have done in order to document that information so that other customers might be better able to do something similar what you have done. Would you be willing to send me your project, or perhaps a non-confidential stripped down version? If so, please feel free to contact me via email by clicking my username and then clicking "Send CharlesP an Email". Thanks for your contribution to the forums.
Omron Forums Support Posted September 26, 2011 Posted September 26, 2011 Dave, I understand what are you saying and we will look into it . I agree with you that if it crash then we shoud flag the error , but I believe we can actually do it right. We will update the thread once we figure out the pros and cons of extending the C lib. functionality to RT and BG plc. Atul
daves Posted September 27, 2011 Author Posted September 27, 2011 Thanks for the reply KEJR. This all sounds very interesting to me (coming from a programming background). However my bosses (coming from a real-world engineering background ;)) just want our Turbo PMAC projects up and running on PowerPMAC as soon as possible. The route chosen, for now, has been to keep the existing structure as closely as possible (there is a lot of fiddly synchronization architecture we don't want to refactor yet). This means 'translating' PLCs into PLCs, PLCCs into CPLCs, and my simulated Dual Port RAM communications running as a CApp. I will also be adding the newly planned features (including logging, and on-board data-capture to the file system) as CApps. I am just thinking of 'clever' ways to improve efficiency and coding style as I go through our existing project (and possibly expecting unreasonable features from the IDE). I will try to read up more on xenomai RTOS if I get chance and will probably have some questions for you in the future! Thanks again Dave
daves Posted September 27, 2011 Author Posted September 27, 2011 Thanks Atul. I didn't mean to make unreasonable requests of the system, I was just excited about the libraries. If you think you can achieve this then this is really good news. I appreciate your help and interest in what would make my (and possibly other people's) development easier. Dave
Recommended Posts