Flat Sequence not Initiating

[endlessOranges]

Hello, I am running a program that controls switching valve actuators and turning a backwash pump on and off in a sequence to perform a bypass on a separation process we are attempting to run. I have timers running in flat sequences to provide time delays before switching the valves back and forth, but when I run the program, the system stops at these sequences, unless I run it in "highlight execution" mode. The problem exists in my two loops I have running under the label bypass system. 

Thank you for your time!

[Bob_Schor]

I'm not sure what you mean by "my program stops at these sequences" -- maybe it is running just fine, but doing what you told it to do, rather than what you want it to do.

I presume you know that your Bypass System loop takes 7 seconds to do one loop.  You open a VISA channel, send a *CC command, wait 6 seconds, send another one, wait another second, then close the VISA channel.  The loop below it similarly waits 6 seconds between opening the DO port and writing a single point (you do not have such a long delay in the Bypass System loop.

Is this what you intend?

Bob Schor

[endlessOranges]

That's exactly what I want it to do. It'll send the first command and I will wait for well beyond six seconds and nothing happens. When I hit highlight execution, the program starts up right before the flat sequence as if it was just waiting there the whole time.

[Bob_Schor]

Sounds like a Race Condition.  I notice you have five completely-independent loops.  Two of them create identical Channels and write data to them (without closing the channel), another uses a DAQ Assistant (try to avoid DAQ Assistant, all Express VIs, and Dynamic Data types -- they often cause more trouble in the long run) without specifying the Device, and far too many Local Variables (strive for none).

Are these loops supposed to be independent?  If not, how do you want data to flow between/among them?

What is probably happening when you turn on the Watch is that LabVIEW is "injecting" itself into the system and shuffling how the various parallel loops contend for processor time, somehow unblocking the Bypass System loop, which you then see running.  Aha, you are trying to send data into this loop using a Local Variable.  Do not use Local Variables for communication between loops (I'll bet if you do a search for "LabVIEW Race Conditions", you'll see this advice repeated ...).

Bob Schor

[endlessOranges]

So I want my first loop to gather data from a sensor and pass it to the next one below it, which runs a rolling calculation over the last minute of data do determine if the sensor has been triggered more than 10% of the time. If so, it passes a true value to system bypass, which should begin the bypass. I am also using the return count from my second visa command to control some functions, as that happened to tie things together well. That bottom loop, should run once the second visa command goes and passes a value of 5 to the return count. The last loop is just for sending data to a spreadsheet when prompted.

[endlessOranges]

So I want my first loop to gather data from a sensor and pass it to the next one below it, which runs a rolling calculation over the last minute of data do determine if the sensor has been triggered more than 10% of the time. If so, it passes a true value to system bypass, which should begin the bypass. I am also using the return count from my second visa command to control some functions, as that happened to tie things together well. That bottom loop, should run once the second visa command goes and passes a value of 5 to the return count. The last loop is just for sending data to a spreadsheet when prompted.

[altenbach]

In addition to what has been said, you VI is full of race conditions caused by the overuse of local variables.

For example you are writing to "return count" in three different places in the "bypass system" loop. If bypass is true, you are writing the 0 and the 1 in parallel and whatever writes last wins (code does not execute left to right, the local write of zero and case execute in parallel because there is no data dependency!), then it gets overwritten six seconds later by the writing to the terminal itself.

Most of your loops try to consume all available CPU power when their case is false, spinning as fast as the computer allows and fighting each other for CPU, possibly starving the processes that really matter, e.g. the collection and analysis loops. You are almost choking the computer!!!

Are you colorblind or the fan of some specific sports team? Is you monitor broken? It is very unprofessional to color the diagram elements like an easter basket. Focus on the code logic instead!

[endlessOranges]

What is a better way to pass things? I want the "bypass control" to set off the condition as soon as the "data analysis" loop gets a value below 0.9. While this condition is happening, I passed a value of 1 to return count to cause the "data analysis" loop to pass a series of 0's into the array to sort of pad my numbers and prevent the "bypass system" condition from triggering immediately again. I want the bottom loop to go off after the "bypass control" condition has concluded and passes a value of 5, which sets off the condition of  "> 1".

The excessive amount of orange is because our company colors are orange and our CEO really likes it seeing it with those colors.

[endlessOranges]

I went and removed all the coloring from it if that makes things nicer to work with.

[altenbach]

---

endlessOranges wrote:

The excessive amount of orange is because our company colors are orange and our CEO really likes it seeing it with those colors.

---

Ah, I thought it had to do with the Texas Longhorns. 😄

You still have all these asynchronous loops and keeping things together is like herding cats. You also still have all these greedy loops.