LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to control two hardware simultaneously

Solved!
Go to solution

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. 

 

simultaneously-motor-movement.png

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. 

0 Kudos
Message 1 of 5
(1,425 Views)
Solution
Accepted by topic author aab-ufl

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.


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 2 of 5
(1,413 Views)

@altenbach 

 

Thanks a lot. Your solution worked. I only had to change Execution (VI Property) of two subVIs: Digital - SW-Timed Pulse.vi and Counter - Finite Output - Pulse Time.vi. I changed them to Preallocated clone reentrant execution

 

This link explains in detail: http://zone.ni.com/reference/en-XX/help/371361M-01/lvconcepts/reentrancy/ 

 

I do have additional questions through: 

  • 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? 
0 Kudos
Message 3 of 5
(1,364 Views)

@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.)


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 4 of 5
(1,346 Views)

Here's how your Motor-combo could look like.

 

No locals! No sequences! No duplicate subVI Instances! No race conditions!

 

 MotorXZ.png

 


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 5 of 5
(1,333 Views)