Is Data-dependency the only thing to stop while loops from running simultaniously?

[Blokk]

Hmm, you should spend some time with learning more basics about LabVIEW. Often LabVIEW is more tricky for those who has text based programming language background than to those who does not have any 🙂 You show the same mistakes and bad practices which some of I also did when I started to learn LabVIEW.

You have to abandon using such principles which are OK to use in a sequential C code for example. Here it will only create race condition and other problems.

First of all, I would recommend you to put aside your project for a few days. Only look at the LV learning material and tutorials. Learn how to build up a LabVIEW project with folders properly maintained, about why type definied enums and clusters are useful and important. How to design and build a state machine with proper timing. Proper timing means the software is always responsible for GUI changes within 100 msecond (or less 🙂 ), etc... How to program a Functional Global Variable, for example to create an Watch Timer...

I already gave you links for learning material above.

You could also have a look at these state machine examples:

http://www.ni.com/gate/gb/GB_EKITCLDEXMPRP/US

These are some possible solutions given during LabVIEW CLD exam, to fulfil the tasks described by the enclosed pdf documentations. Note that, these are neither the best neither always full solutions, but all these got the required 70% grade to get the CLD certificate. Anyway, hopefully they can give you a good idea how a state machine works...

About timing in a state machine: when you have to wait considerable time (second for example) in your execution, you NEVER just put a wait function in your block diagram as it is. This will block the running of your code part, and your GUI will be not responsible. Have a look at the exam examples! All examples use variations of the following techique:

1. In your state machine you have a state where you check for user interactions. Lets call it "check GUI" state. Your state machine always "jumps" between the actual state and this state. In this way the user has the option to change any condition during the "ride", or even abort the execution of the code in a SANE way! (NEVER use the red abort button for aborting your code)
2. You create a "wait" state: this state has only for example a 20-50 msecond wait function inside, and an elapse timer subVI. You state machine must "jump" between during the wait between the "check GUI" and the "wait" states. Since in every 50 msec your execution is "inside" the "check GUI" state, if you want to abort for example the wait, it will not take more than 50 msec to do so! When the elapsed timer subVI inside the "wait" state indicates that the necessery waiting time has elapsed, your state machine can move on to the next state. And so on...

edit: comment for point 2.: actually it is better to have a little ~50 msec timeout in the "check GUI" state (timeout for the Event structure for example), and inside the "wait" state you only check whether the time has elapsed yet without any wait...

[tst]

I haven't looked closely at the discussion, but learning this stuff is useful. Off the top of my head, the only document which comes to mind is this and the ones that follow it - http://www.notatamelion.com/2015/02/23/building-a-proper-labview-state-machine-design-pattern-pt-1/

I don't always agree with Mike, and this isn't necessarily the best way to write something like what you want, but he writes well and this is easy to understand and it should give you some ideas. To put it into some context, here's an image from one of his articles:

The clusters effectively hold variable values (including timers, as seen here) and you can see how an event structure is used to respond to user inputs.

---

@Slothosaurus wrote:

 edit: Also - i'm also 95% sure that you're right about the while loop waiting until the inside loop finishes. I'll select one button go button, then that while loop starts. Clicking another go button would do something, except that the outside while loop has already decided that it doesn't need to run that function (since at the beginning, it was turned off), thus it's waiting for the inside loop to finish before it repeats the check to see which functions need to run. Is that what you meant?

---

Yes. Like I said, execution highlighting can help with this (you can see that the inner loop is actually iterating).

[Slothosaurus]

for the wait section, I need variable wait times. 

The user should imput a sweeping angle for the step motor and a sweep speed in RPM. 

Using that I set the max speed of the motor to the RPM, crank the acceleration to the maximum, then tell it to move the number of degrees specified. Then a wait time is calculated based on the speed, time to calculate the movement, and an extra 5 msec to send the data down the wire, and various other things that might interfere. 

After the wait time is calculated, I'll need to wait that far. 

Using a state machine, I could set increments of 5 msec, then stay in the wait state until all the necesary time has elapsed, at which point I would move to the next state? 

[Blokk]

Using a state machine, I could set increments of 5 msec, then stay in the wait state until all the necesary time has elapsed, at which point I would move to the next state? 

Before starting the wait process, you initialize the Elapsed timer Functional Global Variable (which is a subVI) and set its target time. After the elapsed time reached this target time, this subVI will give out a Boolean True value at its "time has elapsed?" indicator, which will move your state machine to the next state.

Look at the many examples which I gave you the link already. Like the "Car wash" CLD exam example. It works just the same...

[Ben · Accepted solution]

tst called it with his original reply.

Since you can't click two start buttons at the same time, only one can start at a time. That start keeps the out loop from iterating and preventing the read of the second start button.

Add another button "start both" and wire it via a pair of OR gates (one OR gate for each inner loop) to start both of the inner loops. Of course you will then have to figure out to stop both.

Beyond that...

There is a hungry loop with no timer throttling the iterations so CPU is probably high.

The VISA writes are set for syncrounous which forces the code to go sinle threaded each time a VISA fucntion is called. But taht will only affect you after you have both inner loops firting over the VISA acess.

So...

1) Add single start both button

2) Put a wait in that top monitoring loop.

3) Change VISA call types.

...

Just my two cents,

Ben

[Slothosaurus]

Ben, from going over my code some more and learning from you guys, this definitely seems like the right answer. I'm at the beach right now so work is put on a hold (I purposefully didn't bring my work laptop), but this seems correct. 

However, I want to try all of this other stuff, especially learning about state machines and how to wait. Data flow isn't something I'm largely familiar with, as I'm sure you can see. 

A stop both button is probably doable, but since the electron-beam shutter will be preventing the evaporated substrate from reaching the stage before either function is stopped, it seems like even without a stop both button, it should be fine. 

Again, not the best answer, but a usable one for now.