Parallel while loops

[Xiao@Gemini]

Hello everyone, I'm working on LVRT projects, the first while loop handles all the controls and parameter inputs, the second loop is a timed loop which acquiring data, connect to the third while loop with queue function which handles calibration, plot and saves file. However, the second and third while loop delay like two and half minutes when I click run. Can anyone help to improve it? I also want to add an event structure which asks password when the user change the test section, should I create another while loop or put the event structure in the first one? Thank you very much. I attached the code here.

[aputman]

I can't tell which loop is taking over the CPU.  I get dizzy when I look at the block diagram.

Find the loop that is hogging the CPU and add a wait function with a small value (even 0ms is enough). 

[crossrulz]

Your delay is probably from connecting all of those shared variables.  I despise Network Published Shared Variables.  They have never worked well for me.  If communicating with a PC, use Network Streams or TCP to communicate your data.

Also, and RT system does not have a front panel GUI unless you are using the cRIO-903X series and you enabled the front panel.

And front a coding standpoint, you really need to learn to use subVI to break up your code.  Your VI's block diagram is WAY too big and quite noisy, so it is very difficult to figure out what is happening.

[altenbach]

I doubt anyone here has the patience to troubleshoot a diagram the size of Texas and my current laptop monitor prevents me from efficiently looking at it.

How do you measure the delay? Where do the various parts run? Is the RT/FPGA part of the code deployed?

(QUICK comments: Just from seeing some of your elaborate array manipulations (build, decimate, build, concatenate, repeat, etc. ...) you might have a look at the "reshape array" function. You also have serious potential race conditions, for example you are building a huge array of references into a indicators while already reading from a local variable of it. Unless you are lucky and the compiler does some constant folding in the reference arrays, you are reading the local variable way before the terminal is written, so you are reading meaningless content. You are also storing immense amounts of data in charts (many, many(!) charts with many plots and very long chart histories!). Overall, you seem to subscribe to the idea that "more code is better". I think you could reduce your code to 20% and increase functionality and performance at the same time. This all just does not look right but I stop now).

[aputman]

---

@altenbach wrote:

I doubt anyone here has the patience to troubleshoot a diagram the size of Texas and my current laptop monitor prevents me from efficiently looking at it.

---

I had to follow-up on that claim.  Turns out it's true. 

[crossrulz]

---

@aputman wrote:

---

@altenbach wrote:

I doubt anyone here has the patience to troubleshoot a diagram the size of Texas and my current laptop monitor prevents me from efficiently looking at it.

---

I had to follow-up on that claim.  Turns out it's true. 

---

But not quite as big as Alaska...

[CFER_STS]

Time for some remedial LabVIEW training.  Do you have access to NI Online training courses?  You'll want to review LabVIEW Core 1, Core 2 and Core 3.

That said, your user interface loop should probably be event driven, so that you don't need to poll your controls, but instead can simply act on them when they are changed, and then update your indicators either per event or at a low (100ms) rate.

Your timed loop executes at a priority between high and time-critical, and in-lines any code within it, so if you need determinism, you also need to avoid non-deterministic tasks inside your timed loop.  Replace any queues in a timed loop with RT-FIFOs, and if you're using network shared variables, you need to use single-process shared variables with RT-FIFO enabled. You should also serialize your variable calls with an error wire.

Your queue size is presently unlimited, so you run the risk of growing the queue faster than you are dequeuing elements and processing them.  Set a maximum size, or implement some sort of handshaking.

As others have mentioned, you block diagram is unreadable, so I'm not even going to try to parse what's going on there.  At a guess, I think you probably have a bunch of unnecessary memory copies of your data.  You also have no error handling.

[paul_cardinale]

To answer your question "Can anyone help to improve it?": Probably not.  You've created a huge mess.  It's not worth trying to fix.