Trouble Finding Disconnect between Parallel Loops

[tbayrg]

Hello all,

I am having trouble figuring out why there is a disconnect between some parallel loops in my main VI. The general idea is that the feeding loops are state machines that will snap a photo, run a detection subvi and overlay vi, and send coordinates to another state machine for a robotic pickup via queue if there is a part detected, or run a partial/full feeding cycle dependent on if a partial had been run already or not. One of the feeding loops has two parts but I think that is negligible. The state machine that is responsible for part pick has a dequeue element in a while loop with a timeout that determines when a part is ready for pickup then goes through the pickup cycle. 

The problem that I am running into is that the snapped image data will often not update and so the feeding cycle will send incorrect data to the pickup loop. I am unsure at which point in the feeding loop it is doing this because the buffer for the image gets copied onto by the snap and by the overlay subvi but neither can be skipped over in the loops. My instincts are telling me there is something about the properties of image buffers that I am not understanding and I am hoping someone would be able to help find what's wrong with my architecture. Thank you in advance.

I have attached the Main VI and SubVI's and I am using LabVIEW 2020.

[Bob_Schor]

Hello, @tbayrg.  Thank you for attaching your files.

When I was learning LabVIEW (thankfully with 1:1 interaction with my LabVIEW mentor), I bought a copy of "The LabVIEW Style Book" by Peter Blume and read it cover-to-cover at least 3 times.  Here is a key lesson I took away (and have followed ever since) -- Every VI Block Diagram should fit on a Laptop Screen.  Granted, the screens are a little larger ...

How do you make this happen?  Use sub-VIs to encapsulate chunks of code that "do one thing" (like "Initialize DAQmx Devices" or the Consumer loop of a Producer/Consumer pair.  I'm attaching an example and will point out some features:

• The top loop is the Event Handler loop that "fires" when Controls are changed.
• Before the main Channel Message Handler loop runs, all the controls are set to their default value(s).
• The Producer of the Producer/Consumer pair is shown in the middle of the "Get Flow" loop, with a pink "pipe" running to "Coolant Consumer" (green box While-like loop to the lower right).
• Note straight Error lines and (mostly) straight data wires.  Also notice Error Handler trapping errors in CMH states.
• Although it is not visible here, this VI has a Description that says "What it does" and describes the Inputs and Outputs.  All the other VIs (and Type Defs) used in this Project have similar documentation.  A great help when you return to the code 2 years later to fix a bug that slipped through or to "add a feature".

To help you debug your code as it is, one would need several really large monitors.  Take advantage of the "Third Dimension" (depth, or sub-VIs) that LabVIEW provides (and encourages).  It also make testing the code much simpler.

Bob Schor

[tbayrg]

Thank you for the advice, I realize it may be quite hard to read when looking at my code so thanks for helping me learn how to clean it up. I was hoping to make my code functional before I started simplifying and grouping things into sub VI's. I've since started a new main vi to see if restructuring the producer and consumer loops into a single state machine would fix my problem or at least expose the issue that I am currently having.

My introduction to LabVIEW was going through an even larger jumbled mess of a main vi with tens of layers of sub VIs, so starting to create my own web of SubVIs intimidates me a bit. 

If I manage to find the problem I'll post again. Thank you again for your help.