LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

flat sequence - one machine working faster than other one

I'm sorry, but the code is so poorly structured I have no idea what it is supposed to be doing. You need to get into the tutorialsthat are available online. Find out about dataflow, and event driven programming. Don't ever use a sequence structures or the Stop function again. As it says in the help, it is like clicking the abort button.

 

As someone once said, "Stopping your program by clicking the abort button is like stopping your car by running it into a tree: it works, but there can be unfortunate consequences..."

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 11 of 13
(270 Views)

Where to start?

 

1. STOP using STOP. STOP works like the Abort button on the toolbar. That should only be used as a troubleshooting tool to stop runaway code during development.  One long-time participant ing the Forums has said that "Using Abort to stop a VI is like using a tree to stop a car. It works but has unintended consequences!" In particular you do not get orderly shut down of the instruments being controlled and do not close the VISA sessions, report errors, and so on.

 

2. You only need to set the Timeout once on each VISA session. If you are trying to use the timeouts to solve your timing issues, it probably will not work.

 

3. You never Close the VISA sessions. This may leave the ports locked up until the computer is rebooted. You should also set the instruments to off or to a safe mode before closing the VISA Sessions.

 

4. Long waits (1-10 seconds) can make a program very unresponsive to the user (such as when pressing the Stop button). It is usually better to use shorter waits and a loop to repeat the wait while checking for other user inputs.

 

5. Avoid the use of sequence structures.  You MIGHT need two or three single frame sequence structures around a few of the Wait functions. Dataflow eliminates the need for all others. A better architecture would probably eliminate the need for those few.

 

6. When using termination characters on a serial port, do not use Bytes at Port. Set Byte Count to a constant value larger than the longest expected message and let the termination character do its job.

 

7. Use an enum and one case structure rather than a numeric input, 4 equals?, and 4 case structures for the Function Type selection. This result in the function appearing in the selection label of the case structure and can easily be expanded if you need to add another waveform. This also provides a front panel control with user-friendly strings such as "Sinusoidal" and "Ramp."

 

8. Use appropriate data types. Especially use integer data types for N inputs on for loops, selector inputs to case structures, and other places where only integers make sense.

 

9. If the instruments can accept multiple commands on one string (separated by ; or other delimiter), concatenate the strings and use a single write.

 

10. Keep the diagram size to the size of one screen. If you need to scroll around all the time your programming productivity will be substantially reduced, the probability of errors is increased, and whoever needs to fix bugs or add features six months from now will not swear at you (as much).  If the diagrams get too large (and yours are not far from the threshold), LV cna get confused, the diagrams get corrupted and you can lose your work. Keep backups.

 

11.  The matter of "synchronizing" your instruments is not only a LabVIEW programming issue but also one of the capabilities of the instruments. You only read from one of the instruments and only in one place. Most instruments can return status information. USe that to determine when to tell the other instrument to go to the next task.

 

Now, how can you do all this? Use a state machine architecture. There are templates and examples which come with LV and hundreds of posts on the topic on the Forums. Use subVIs. For example setting the voltage, offset, frequency, and burst cycle count could logially be done in one or two subVIs. Two makes more sense if you often change the voltage and burst parameters separately. One is better if all those values stay the same throughout one run or are always changed simultaneously. Without knowing more about your instruments and what you are trying to do, it is difficult to give specific advice.

 

Lynn

 

 

0 Kudos
Message 12 of 13
(266 Views)

Thank you Lynn. 

I'll follow your advice.

 

 

Maria

0 Kudos
Message 13 of 13
(238 Views)