Sluggish performance on my controller code

[Panzonbackwards]

Hi,

I have pasted an image of my code below.  The upper portion receives inputs from three channels of a load cell.  When I run this code alone I can sample at a period of 5 ms, but it is inconsistent and samples sometimes at 10ms (when it is set to run at a 10ms period.). 

The bottom portion of the code controls an actuator and I believe this is what is really slowing down the loop run time.  At peak performance the entire code runs at 15ms periods, but more likely at 20 or 30 ms periods.  Also, the timing is very inconsistent.  It will run every 20 ms for 5 or 6 iterations and then there will be a 30 or 40 or 50 ms cycle. 

I know Windows can be blamed for inconsistent timing, but this seems like it might be something else.  Does anyone have a suggestion in improving the efficiency in my code?

Thanks for giving me a hand,

Jason

[JackDunaway]

The single best functional enhancement would be to divide your single loop into multiple parallel loops. Functionally divide the tasks you are trying to accomplish into each of the loops: for instance, a UI Loop, a DAQ Loop, and a Machine Control Loop would be a good start for you. This may not necessarily increase performance in and of itself, but it allows an easier troubleshooting procedure where the culprit of the late timing more easily stands out.

Things to watch out for in high priority, fast loops:

1. Property nodes or invoke nodes. They force a thread swap into the UI thread.... practically, this means they are very CPU intensive if you run them in a loop.

2. Disk writes/networking, or other non-deterministic means of data transfer in an otherwise deterministic loop. Use producer/consumer loop pairs to handle this task.

There's nothing that stands out to me why your loop is running late, but I can't see any subVI's. Are you able to post code and subVI's? Just a final hint: when posting images to the forum, always use PNG rather than JPG for a lossless compression, and oftentimes smaller filesize.

[johnsold]

Jason,

Avoid the use of local variables to pass data between different parts of your code.  They force a switch to the UI thread and may be slow.  They can also lead to race conditions.  Use wires.  If you switch to parallel loops as Jack suggested (and I agree), queues or notifiers are good ways to transfer the data.

You have a subVI marked Safety E-Stops.  1. If this is a safety issue, use a hardware E-Stop.  Do not rely on the software to get the message out on time. Let the software monitor the status of the hardware E-Stop and do an orderly shutdown.  2. The references for the motion control do not enter the E-Stops VI, so how does it actually stop the motion?  This may happen outside the loop shown, but it is an important question. 3. Even if the E-Stops inputs cause the loop to stop, all the other code in the loop will still complete before the loop stops.  All the motion control stuff might run one more time.  This may not be a big issue, depending on the timing, but should be considered.

Lynn

[Ben]

---

@Panzonbackwards wrote:

Hi,

I have pasted an image of my code below.  The upper portion receives inputs from three channels of a load cell.  When I run this code alone I can sample at a period of 5 ms, but it is inconsistent and samples sometimes at 10ms (when it is set to run at a 10ms period.). 

The bottom portion of the code controls an actuator and I believe this is what is really slowing down the loop run time.  At peak performance the entire code runs at 15ms periods, but more likely at 20 or 30 ms periods.  Also, the timing is very inconsistent.  It will run every 20 ms for 5 or 6 iterations and then there will be a 30 or 40 or 50 ms cycle. 

I know Windows can be blamed for inconsistent timing, but this seems like it might be something else.  Does anyone have a suggestion in improving the efficiency in my code?

Thanks for giving me a hand,

Jason

---

If you think the code at the bottom is the issue, then put a case struture around it and comment it out.

I suspect the issue is building an array on the edge of teh loop.

Switch over to a Producer/Consumer architecture should fix that.

Ben

[Panzonbackwards]

Thank you all for the helpful suggestions.  I have attempted to use the Producer-Consumer architecture as well as removing the local variables. I haven't been able to get this code to work properly.  It tells me that there is an error dequeuing in the consumer loop.  Any ideas?

Also, I broke up my code into two producer loops - a data acquisition loop and a motor control loop.  I directly wired the inputs from the DAQ loop to the motor loop rather than queuing them.  Is this incorrect?  I tried to put a queue to bridge on of the links, but I wasn't sure if that's the proper queuing technique.

Thanks again!

Jason

[johnsold]

Jason,

You do not really have a producer/consumer architecture because the middle loop has data dependencies from the top loop.  You cannot have any wires going form the output of one loop to inputs of another loop if you want the loop to execute in parallel.  That is what the queues are for!  

Lynn