LabVIEW
Unable to control two hardware simultaneously
Solved!
Goal
I am trying to simultaneously move two stepper motors (Z axis and X axis) at the same time.
Background
I have created two VIs (motorZaxis.vi and motorXaxis.vi) to controller the stepper motor. The VI requires direction and number of steps to move. These VI communicate with the each of the myDAQ (myDAQ 1and myDAQ 2) which sends digital signals and pulse train to each of the stepper motor controller.
My third VI (motorCombo.vi) seeks to simultaneous move both stepper motors at the same time. This program aims to move the Z axis motor UP 100 steps and back DOWN100 steps, and the X axis motor LEFT 100 steps and LEFT 100 steps. The GOAL is that both Z axis and X axis stepper motor should move at the same time.
Issue
When I run the motorCombo.vi, each stepper motor moves sequentially. The Z axis stepper motor moves UP and DOWN first then the X axis stepper motor moves LEFT and RIGHT. They both are NOT moving simultaneously.
Attached are my example VI.
I am using LabVIEW 2017 (64-bit) with quad core PC.
Both stepper motor controllers share the same power supply with 3.4A rating, but both stepper motor controller is set to only use 0.8A for the stepper motor.
You need to make your subVIs reentrant (vi properties...execution), else only one copy can run at the same time.
None of your local variables are needed (motor combo). Get rid of them!
You seem to have potential race conditions in the subVIs (does it matter what starts first (enable IO vs FOR loop), etc.
@aab-ufl wrote:
- Is there an issue if I use local variables? As you can see in my motorCombo.vi, the local variables are for read only. The uploaded VI is just a simple example, but for my application, there are many more wires, and if I don't use local variable, the block diagram gets very confusing with a jungle of wire connection...
- I didn't understand which race conditions you're referring to? Can you please explain?
It is not clear that "motorcombo" is a subVI (no connectors assigned, etc.), so if this is running with the front panel open, anyone can accidentally change one of the controls during run, so the settings after the 1000ms wait could be quite different to the settings used in the first steps. Since these control changes can happen at any time, you are not guaranteed that all four calls are with the same inputs, and there is no way to predict the actual outcome, because it critically depends on timing. The right way is to place the terminals on the left, branch the wires before the sequence structures, and wire to all places where they are used. Now the entire VI will execute with exactly the same settings at all subVI calls. The terminals are read exactly once at the start. Once the data is in the wire, it is protected from changes to the terminal value until it is called again. (This even protects if the controls are written programatically from elsewhere via property nodes). Note that if you would use proer error IO ant your subVIs, you would not even need to use the sequence structure.
Wires are much better because you can at all times tell where the data is coming from and where it is going. Local variables should never be used for cosmetic reason. If your diagram gets "prettier" when using local variables, the problem is elsewhere (bad code architecture, etc.)
Here's how your Motor-combo could look like.
No locals! No sequences! No duplicate subVI Instances! No race conditions!
