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.

[he,they]

I think the queue is probably doing its job. look to how the image is being handled instead. If the same image buffer is being reused its possible a new snap is overwriting it before the previous one has finished processing, which would explain why you are seeing old image data. Check whether you are passing around the same IMAQ image reference. If you are try making a copy of the image before sending it to the detection and overlay VIs. Also throw a few probes on the image wire to see exactly where the data stops matching what you expect. My guess is the issue is with the image buffer being reused rather than the state machine or queue.

[Bob_Schor]

Hello, @tbayrg.

After reading (again) your original post, and having my (tired) brain "tweaked" by the recent post from @he,they, the "light bulb" in my head began to glow.  I should have asked these questions earlier, but better late than never.

• How many separate "Image Channels" (= cameras operating simultaneously) are you using?  That is, is there a single camera looking at a single "point in space" (where, presumably, objects pass by and show up on a series of images), or are there several cameras looking at several "fixed points in space"?
• I'm going to assume the answer to the previous question is "One camera looking at one direction, with the "object of interest" moving into and out of the camera's field of view.  Note that if this assumption is false, and you want to track multiple objects on multiple belts, let's solve the N = 1 case first, then figure out how to handle multiple cameras and objects.
• I'm going to assume the camera is fixed in space and the object moves at a constant speed into and out of the camera's field of view.  Tell us something about the speed of the object going past the camera -- how much time elapses between the object first entering the camera's view and the object leaving the camera's view.  Note I'm assuming only one object is viewed at a time.
• How much time (in seconds) is the object visible when moving?  Provide two times -- from first entry to last exit (i.e. time when any part of the moving object is visible) and from "entire object first visible" to "entire object last visible" (so the only difference in the two images is the distribution of "blank space" surrounding the object).

     I just noticed (sorry for my sloppy reading of the initial post) you and @he,they used the term "snap" in describing image acquisition.  Here's a question -- how do you determine when to acquire an image?  Do you analyze each image "looking for a feature" or have a Digital signal that says "Part is in place, take a picture now"?  If the first is the case (you examine successive video frames until you find one that shows the part clearly), then you don't want to do a "snap", but rather a "grab" at a suitable frame rate with the camera set up to use image buffers.  The frame rate will be determined by how fast the image moves through the frame of the camera.  Please clarify what other DAQ devices (besides a camera!) you are using to set the timing parameters for this project.

     More things I'd like to know:

• What are the spatial parameters of your images?  How many pixels, such 640 x 480?
• Are images Gray Scale (how many bits) or color (how many bits)?
• Can you provide an image showing the "object" you are studying, using the Camera setting for your "snap"?
• What is the speed of the object you are studying.

Bob Schor