daves Posted March 25, 2014 Posted March 25, 2014 I found my calculations in my RTI exceeded some limit and caused the PPMAC to grind to a halt. There were not many calculations really so I tried to investigate the timings. Is the following correct or am I confusing myself? There are actually 100 lines in this example but I have shortened the code below #define _PPScriptMode_ #include "../../Include/pp_proj.h" void realtimeinterrupt_plcc() { double d; int i; d = GetCPUClock(); ADC00 = ADC00 + 1; // etc ADC99 = ADC99 + 1; pshm->P[17] = GetCPUClock() - d; } I see P17 around 10 microseconds. If I have 2.2kHz RTI I only have 500 microseconds to play with (not including other tasks). It appeared that when I got to 200 microseconds in my real code everything choked (this is only 2000 additions and assignments). Is this true? Also the task manager shows RTI calc time at 15 microseconds whatever, why is this? Thanks Dave
Omron Forums Support Posted March 28, 2014 Posted March 28, 2014 Hi, Can you please elaborate on what you mean by "grind to a halt"?
daves Posted March 31, 2014 Author Posted March 31, 2014 Sorry Charles the phrase may have been over dramatic and not helpful. The first symptom was my the PPMAC failing to react to my Windows front-end issuing ASCII commands like "b4r" (comms is done using my own background c-app with a TCP mechanism recreating the old GetMem/SetMem/GetResponse) As I added more code to my rticplc I saw all communications slowing down and what were once regular-frequency read/write operations taking erratic lengths of time. The IDE also became less and less responsive. For example with useralgo.rticlpc=0 the terminal would give a response to "vers" in a millisecond or two, with useralgo.rticplc=1 it would take 20, 30, 40ms. Even pressing each key would be unresponsive (I assume due to slow watch window entries which I also noticed). I have since realised the task manager was not giving useful feedback on task times making me think I was only half-loading the RTI interval but really I was filling it with servo and rti tasks. Adding a bit more code eventually caused the WDTFault to go to BGFault. It looks like background tasks are being starved. I seem to remember ASCII comms is the first thing to go in UMAC when the foreground is overloaded? I think I would like to see an error status if the system does get to a state where commands are ignored (I admit I might not be monitoring the response correctly I haven't checked).
Omron Forums Support Posted April 2, 2014 Posted April 2, 2014 Having a large amount of real time tasking can indeed cause background tasks to be suppressed. I am not sure if there is a status bit indicating that any communication was suppressed, although it is not likely that any exists. Perhaps if you sent me your C code, I could help you optimize it. There are many tricks to cut down the processing time. If you want to send it in, send it to support AT deltatau DOT com, ATTN: Charles. If it's too sensitive for me to see, I can send you some training materials with tips on making code more efficient. Just send us your email and I can send it.
daves Posted April 3, 2014 Author Posted April 3, 2014 Thank you for the assistance. I have mailed you. It is sensitive but I have stripped a load of stuff out and we trust DT :)
Recommended Posts