Elapsed Time in sub VI

[djnbae]

I am trying to use a sub VI to distinguish between a passing and failing value. If it is a failing value it should wait 10 secinds and send an alarming signal back to the main VI, but the elapsed timer never counts up. Why isn't the counter counting up to 10 and passing changing "alarming" to true? What am I doing wrong? Is there a better way to do this?

[Gregory]

Hi djnbae,

You have nothing running in a loop, so your code only executes once. You will need the loop if you want to see anything happening over multiple runs of the code, such as "counting".

[djnbae]

How do I do that without holding up the execution of other items in the main VI?

[Gregory]

I couldn't tell you without seeing your Main VI

[altenbach]

• Your VI makes no sense.
• You failed to attach the file IO subVI (I have an old, pre-2014, subVI with the same name in my downloads folder, so it loads that one with many broken wires)
• I tend to ignore VIs that have the front panel and diagram maximised to the screen, especially if the actually used area is much smaller than that. Very annoying! You have no right to take over my entire desktop!
• USING ALL CAPS FOR DIAGRAM COMMENTS MAKES THEM MUCH HARDER TO READ.
• If these are the subVIs, also attach the calling VI. Strip out all irrelevant code, such as the file IO, etc. and focus on the core of the problem. Place all required VIs in a folder and zip that folder before attaching to keep things together.
• Placing long waits into subVIs will tpyicaly stall the calling VI for that duration. Use a state machine instead.

[djnbae]

I have attached my main VI. I am hitting my head against a brick wall, so any suggestions would be greatly appreciated.

[Blokk]

There are many potential race conditions in this code, I really advice to take some tutorials (courses) in LabVIEW. You should properly understand what data flow means, learn how to set up and use a state machine, timing using a state machine, Event driven programming (Event structure, User Events), Queues, type definitions, etc... After understanding the basics (lets say Core 1-2 course material), you could examine some basic design patterns (partly the Core 3 learning material).

[Gregory]

Unfortunately that's a huge block diagram and it's going to be hard to give any suggestions that don't involved a lot of re-doing / starting over.

Perhaps you can store the time the alarm was triggered in a shift register. In your main VI you can see when the current time minus the alarm time is greater than 10 seconds, then reset the alarm time to -1 or something so you know to ignore it until another alarm is triggered.

[altenbach]

Ouch! As I said, reduce the problem to a small example. We don't want to sort out that gigantic mess. (And don't maximise to the screen!)

• You are reading duplicates of the same local variable in parallel in the same loop. Why?
• Why aren't most controls/indicators connected to anything?
• The VI is full of race condition. For example there is no guarantee that the "initialization" executes before the loop start.
• There is huge amounts of duplicate code that can be consolidated into one. (e.g. many case structure only differ by a diagram constant. Correclty written that program would comfortably fit on a single screen.
• Some indicators seem connected to a wire, but aren't (e.g. "Site 2 Rack Air Temp (Blue)")

[djnbae]

You mention using a state machine instead of the sub VI I wrote, could you give me a simple example how to accomplish this?