Flat sequence structure in labview while using same DAQ at different instances

[Arunr88]

Hi,

I have to build a labview code for acquiring analog signals from a row detector circuit having 8 sensor elements. The row detector is mounted on a step motor so as to move the circuit vertically and horizontally by selecting a suitable step size so as to form an array. For example if it moves only 8 steps, it will be able to get an array of values with a dimension 8X8 as the row itself already contains 8 elements. For 8x8 its working properly. But when I modified the same code to achieve both horizontal and vertical steps to get 16X16 array, by appending the two 16x8 arrays; the two matrices showing the same values. I know that the explanation is not sufficient. But anyway, if anyone can find the mistake that I made, it would be really help me to complete my work. I am attaching the VI for your reference. The VI also consists of a control module for the step motor.

[GerdW]

Hi Arunr,

---

@Arunr88 wrote:

But anyway, if anyone can find the mistake that I made, it would be really help me to complete my work.

---

Why is there a huge sequence structure? (Why not implement a statemachine?)

Why do you need those local variables?

Why is there so much duplicated code (like those FFT and all other stuff to find "Detection1-8" values)? Ever heard of using subVIs or loops?

Why does your Stop button miss its label? And why do you need to OR its value with TRUE? (That's pure Rube-Goldberg!)

Why do you use so many DAQAssistent ExpressVIs and so many DDT wires?

It really would help to draw a sketch of the desired algorithm on a sheet of paper! After doing that you may start with coding…

[Arunr88]

Hi GerdW,

Thanks for your reply. I understood what you said. But I am not that much expert in labview. The code is working properly. The only issue is that, getting exactly same value in the two 16x8 matrix, even the code just run without any signals from the detectors. I am not able to find the error. If possible, can you please find the reason for this error?

[GerdW]

Hi Arunr,

---

@Arunr88 wrote:

The code is working properly. The only issue is…

---

…it's way to big and way too hard to debug!

When you need to scroll several thousands of pixels it's nearly impossible to debug!

See this:

This is how two of the frames of your huge sequence structure may look like! (This can be simplified even more!)

Simplifying your code also helps with simplifying the debugging and error searching!

So please simplify your code before trying to search for errors:

• Create subVIs for those two frames containing the MG17 motor handling.
• Create a subVI to handle the 2DPictureIndicator image creation.
• Take care of all those uninitialized shift registers.
• Use AutoCleanup from time to time.

[Bob_Schor]

In looking at your code, I (of course) see the Sequence structure, which you use to "sequence" the order of the functions that you are using.  But you are ignoring the preferred sequence "wire" that is built into almost all LabVIEW functions (and should alsu be included in almost all VIs that you write), namely "Error In" and "Error Out") and the Error Line.  The only place you might consider a Secquence is when you use Timer functions, but since you seem to be using LabVIEW 2021, you can use the "Stall" Malleable VI and attach it to the Error Line.  With the Sequence gone, you can start cleaning up the rest of your Block Diagram, making it much easier for you (and for us) to look at, to understand, and (possibly) to find the problem that you are having.

I urge you to give this a try.  Start by putting Error In and Error Out on your Front Panel, wire them to the lower left and lower right Conncector panes (the "standard location" for the Error Line).  Put Error In outside the left side of the Sequence, and Error Out outside the right side.  Bring the Error line in from the left and start connecting it (sequentially, Error Out of previous function to Error In of next function) starting with the Invoke Nodes.  Leave the Sequences along for now, but keep connecting Error Out to next Error In, going through Frame boundaries as you encounter them.  If you see a Wait (ms) function, replace it with a Stall VIM and wire Error In and Error Out, and continue until you reach the right hand side of the Sequence.  Connect the Error Line from the Sequence to Error out, and then (drum roll, please!), delete the Frame Sequence!

Yay.  Now, when you run your code, you might get an Error Message because some function is mis-behaving.  Maybe you'll even be able to fix your own code if you can see where the Error pops up ...  

You can also start "cleaning up" ...

We can, of course, do this for you, but this is your code, and we are trying to teach you how to write better LabVIEW code, including the practice of using the Error Line and staying away from Frame Sequences (don't worry -- you'll have a chance to use them if and when you have a few years of LabVIEW under your belt and start coding FPGAs ...).

Bob Schor

[Arunr88]

Hi GerdW,

Thank you so much for your support. I will try to simplify the code as you mentioned and let you know the status.

Regards,

Arun

[Arunr88]

Hi Bob,

Thank you so much for your detailed explanation. I will try to modify the code as you detailed here and let you know the status. 

Regards,

Arun

[Arunr88]

Hi GerdW,

I have modified the code as you suggested. But still, the same error exists. Please have a look and let me know your comments.

[Arunr88]

Hi GerdW,

Did you notice the modified code?

Expecting a reply from your end.

[GerdW]

Hi Arunr,

---

@Arunr88 wrote:

Did you notice the modified code?

Expecting a reply from your end.

---

Yes, I noticed your message, but hadn't a lot of (spare!) time in pre-Xmas season…

Now I examined your VI:

Still too many frames, still 2 uninitialized shift registers, still an unlabeled stop button, still missing error handling…

(See attachment for a little improvement!)

---

@Arunr88 wrote:

But still, the same error exists.

---

What have you tried to debug your VI?

Did you use any probes?

Do you get the expected data from your DAQAssistents?

Does those FFT loops give the expected results? (Do you really need the 2001st frequency bin value?)