while loop inside a timed loop

[Graziano]

Hi everybody!
   I'm using:
       - LV 7.1 + RealTime;
       - compactFieldpoint;

   I've noticed a strange behaviour, when I put a while loop inside a timed loop.  Let's fix timed loop with these settings:

       - 1 KHz clock
       - 1 ms period (yes, I know it's short....)
       - offset 0 ms
       - Phase 0
       - Discard missed period (ON) and MAintain original Phase (ON);
       - Timeout: -1.

   If inside this loo, I put a traditional while loop, waiting (say) for an event to occur, and if this event does not arrive, my cFP-2020 hangs! I mean, it becomes unreachable for the debugger, and, more, if I run a ping to it's address, after some cycles it becomes unreachable also from ping!

   Clearly, this code statement lock the fieldPoint, because if I remove the inner while loop all works.

  I know that with 1 ms period, timed loop always finishes late, but I set to discard missed period and timeout to -1. 
  
   It seems to me that sometimes Timed Loop add heavi overhead to programs, I'm turning to all while loop based tasks, even if my application has to be real-time!

   Advices welcomed! Have a nice day!

graziano

[Wayne.C]

Can you post an example?  I'll try it on my 2120 and see if the extra memory and speed makes a difference.

[Graziano]

hi Centerbolt,
   I've made a silly VI, but if the cocept is as I stated, it should be enough to lock cFP...

   thanks a lot!

graziano

[Graziano]

....actually here's the VI it's friday.....

graziano

[Graziano]

Okay,
   I've tested also my test VI (the one I posted), and it will make you loose control of compactFieldPoint module.  To regain control, reset cFP module, or disable VI by SWITCH  6.
  
   let me know....

graziano

[Wayne.C]

OK.  I locked up my 2020.  2120 is tied up this AM.  I did get it to quit locking up the cFP by putting a "Wait (ms)" in the inner while loop with a wait of 1ms.  I'm guessing that without the delay, the cFP is just sitting there running the loop as fast as it can and is starving all the other processes on the cFP.  I guess all those warnings from Basics I&II were for real.

[Graziano]

Okay,
   good! So my cFPs are not the only one to lock

   I can put a wait of 1 ms, but, anyway, the fact that cFP locks for this software who's consuming resources is quite awful... maybe this is because Ethernet is used as programming port (I prefere traditional Serial,ISP, JTAG or similar programming).

   I'll check, but I think that if you put an endless while loop, you won't lock cFPs........... if so, it's the tmed loop the responsible for the lock!

   Anyway, thanks for your reply, and have a nice week-end!

graziano

[Graziano]

Here it is!

   It's a really silly VI, but it demonstrate that two nested while loops, instead of a while loop inside a timed loop, don't lock! I can also debug!

   Bye!!

graziano

[Jarrod_S.]

I think the issue here is that putting your while loop inside a Timed Loop increases the priority for that task. Timed Loops can have dynamic priorities set over eachother, but they all run between Above Normal and Time Critical priority. My guess is that the debugger and built-in TCP functions run at Above Normal priority or less. This means your cFP isn't hanging, it's doing what it thinks is best. It's trying to finish this task before handling any lower-priority tasks.

The suggestion to put a Wait function in your loop is an OK one. Keep in mind that you can actually set your wait time to zero instead of one and get the same positive benefit of handling other tasks. I would also suggest that you might look into waiting for this event in a lower priority (non-Timed) loop, and then transmit the appropriate data to your Timed Loop using an RT-FIFO or something. That might give you better handling. Just a thought....

[Graziano · Accepted solution]

Thanks a lot for your reply!
   I will test the whole application, and then look for the best practice.... but I still think I will replace timed loops with while loops...

   have a nice day!

graziano