LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stability Issue - Case Structure

Hi,

 

I build a system with a case structure that would send some command and follow them when i push a button (Changing Switch-Waiting-Flow-Waiting-Flow- Switch), but it appair that sometime, the program don't work

 

The problem here is the fact the program work most of the time but sometime, no. So I was wondering what could do that or what could I change to be more stable

 

I have join a picture of the problem area but if u find any other coding that need optimisation in my program, I would be more than happy to do the switch,

 

 

Regards,

 

SG

Download All
0 Kudos
Message 1 of 9
(3,547 Views)

2MB of code? You really need to do optimization on your code. Please attach the code in 2011 version.

-----

The best solution is the one you find it by yourself
0 Kudos
Message 2 of 9
(3,530 Views)

From the structure of the code it appears that you have a background in programming in a text-based language. This prevents you from taking full advantage of the power of LabVIEW.

 

Things to avoid: 

- Local variables. Unlike text languages the variable in LV is the wire. A local variable is not a representation of the data but a remote access point to a control or indicator. Using locals is much slower than wiring, is very prone to race conditions, and creates duplicate copies of the data. For transfering data between parallel loops a queue is often the preferred choice.

- Timed loops and Timed sequence structures: These are generally for use on real-time OSes and platforms.  When running on a desktop OS regular while loops are preferred. The data acquisition hardware can most likely provide adequate timing precision.

- The DAQ Assistant: This is useful for quick and dirty evaluations. For robust data acquisition processes learn to use the DAQmx VIs. This also allows you to avoid the Dynamic Data Type and all its complications. I know of no experienced LV user who likes the Dynamic Data Type.

- Very long delays: These make the program very unresponsive to the user or to errors. It is better to use a short delay and repeat it several times with checks for user input between calls to the short delay.

 

Fixes: Look at the Producer/Consumer Desoign Pattern or Template.  All of the DAQ code can probably be in the Producer loop. All of the analysis, display, and saving to file can be in the Consumer Loop. It is possible that you may need a third loop for the PID calculations.  You also need some error handling and a shutdown process to assure that the controlled system is placed into a safe state before the program exits.

 

And please remove the fat cat from the front panel before posting to reduce the size of the file.

 

Lynn

Message 3 of 9
(3,511 Views)

You entire code is highly flawed and you are well advised to start with some tutorial before trying to attempt such a program.

 

  • The outer while loop and the E-stop button serve absolutely no purpose. Because the inner loops can never complete, the outer loop cannot iterate. The E-stop is read at program start and then never again. Its value is irrelevant.
  • The code to create a 1D array of four booleans (see picture below) is complete Rube Goldberg. A simple "built array" is all that is needed.
  • I assume your problem is with the code you show in the picture. Since the loop conditionally contains code that waits for a very (very!) long time, the loop cannot iterate and everything else needs to wait until everything has completed. This means that, depending on the state, the code will wait a very long time (e.g. 20 minutes) until the booleans are read again.
  • Once you stop that loop, the other loops will continue to run and the loop you just stopped will never run again until you abort and re-run the VI again. Why does it have a stop button that does not seem to be part of the visible user interface?
  • If the boolens need to be ready to be read at all times, that part of the code would need to be in a seperate loop.
  • There are many other things that make absolutely no sense:
    • What up with all these local variable?
    • (upper right loop): building a scalar value into an array of one element and then taking the array max will just return the original scalar value. You can delete all that code without change in functionality.
    • Using a compound "or" node with only one input simply returns the input.
    • What's with all the overlapping and right-to-left wires?

 

My recommendation would be to take a LabVIEW course (or do all available tutorials), delete all code, retaining only the controls and indicators, then start with an established design pattern. The current code is beyond repair.

 

 

Message 4 of 9
(3,503 Views)

Thnak You for the reply ! 

 

Sorry for the cat picture, i totally forgot it, 

I am putting Timed Loop because I am afraid the iteration time could variate in the process and I really need to have my data check/save every 5 minutes. 

I have follow all the Labview Free Tutorial but I didn't know about the DAQ assistant or the local variable. 

 

  • What's with all the overlapping and right-to-left wires? What do you mean by that ? 

 

 

 

 

Thank You,


SG

0 Kudos
Message 5 of 9
(3,407 Views)

@sillusus wrote:
  • What's with all the overlapping and right-to-left wires? What do you mean by that ? 

Just looking at the small section of code in the picture above, it shows very poor coding practies that make the program hard to read and understand.

 

Here are some examples:

 

  •  The wire from the "manuel mode" terminal goes right-to-left for no good reason at all
  • The four boolean terminal are not vertically arranged in the order they are wired to the merge signal node, leading to unecessary wire crossong
  • The state enum wire is hidden underneath the case structure, making it impossible to tell where it actually connects (several places).
  • etc.
  • It is just a total mess!

 

0 Kudos
Message 6 of 9
(3,372 Views)

Working on that ! Thank you ! 

 

I just have two more question at the moment (if you don't mind) :

 

- If I cannot use the Timed Loop or the local variable for my system, how can i use the iteration of the while loop as a one second standard ? I will just remove every local variable and every timed loop for case sequences. 

 

- Like suggest I will convert or generate a NI DAQmx VI code/task, I just want to make sure i understand that completly, I am using a DAQ assistant for sending data to my bench, i will transform it to NI DAQmx VI task and If I am using a DAQ assistant for looking at variable from the bench, I will use a NI-DAQmx code ?

 

 

I did buy the course for Labview (Course One) for setting up my knowledge and clearing the code to be more efficient,

 

SG

0 Kudos
Message 7 of 9
(3,302 Views)

With all those locals you're running into the classical problem of Race Conditions, meaning you cant tell when the locals update and which version is read. Luckily it's not a very big program so doing as Altenbach writes and start over with better understanding is the right way to go. (I got a bit scared when i saw the 2Mb size until i noticed the cat, 2Mb of code is _scary_ in a single VI)

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 9
(3,288 Views)

sillusus wrote:

- If I cannot use the Timed Loop or the local variable for my system, how can i use the iteration of the while loop as a one second standard ? 


I am not sure what you are trying to say here, but you can use anything you want. However, a well designed state machine probably does not need more than two loops (one for the UI) and probably only needs very few (maybe even zero) local variables.


@sillusus wrote:

 I will just remove every local variable and every timed loop for case sequences. 


What is a "case sequence"?

0 Kudos
Message 9 of 9
(3,277 Views)