From 08:00 PM CDT Friday, August 12 - 01:00 PM CDT Saturday, August 13, ni.com will be undergoing system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Array operation only doing first index in regular run (does all indices in continuous run)

Solved!
Go to solution

Hello,

 

I'm developing a subVI to control 4 actuators through a controller. I've tried two versions, one where a "MoveMotor" VI runs in a for loop, indices feeding into the motor #. Another version where four "MoveMotor" VI's are connected sequentially with indices connected separately. Either of these subVI's is deployed in a test-main VI. In the test main-VI, both of them operate as intended in "run continuously" mode, moving each and every motor sequentially. But when I run the test-main VI in regular "run" mode, only the first motor moves, then the run ends. Another funny thing is, if I set "Highlight Execution" and "Retain Wire Values" in the subVI, then do a regular run in the test-main VI, the subVI functions as intended, moving all motors.

 

The main issue is that I need to deploy this subVI in a larger project, and it appears to behave same in the main VI of that project, which is why I created a simpler test-main VI to test it. I've found a similar problem in this forum, where a for loop is connected to multiple wires, in which case runs only the smallest number of times. I've tried removing all other wires on the for loop by nesting the input controls inside of it, but didn't solve the problem. I was hoping anyone could defog a little of my ignorance, thanks in advance! (I attach pics below)

 

Edit: I've attached the test-main VI and the two sub-VI's for reference.

 

test-main VItest-main VIsub-VI 1sub-VI 1sub-VI 2sub-VI 2

0 Kudos
Message 1 of 6
(140 Views)

Here's a link to why you shouldn't use "Run Continuously" as a strategy outside of debugging.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 6
(126 Views)
Solution
Accepted by topic author pjang

Obviously, you are hammering the device, sending the commands in rapid-fire mode before the device is ready for the next, so you only get the first transmitted. In execution highlighting, things slow down so the device is actually ready when the next command is sent. In "continuous run" mode, you are sending rapid-fire commands forever and once in a while one gets through, maybe in the desired order by sheer luck. You are not saying if you get any errors.

Maybe all you need is place a small wait inside the FOR loop?

 

On a side note, it is pretty useless to attach code pictures instead of the actual VIs, especially since you don't say where subVI1 and subVI2 are located. Having a subVI with a "2" on the icon does not help either. That one seems to be subVI 3 that you don't show at all.

There are serious flaws overall, for example all subVI terminal belong on the toplevel diagram and not inside the loop. "Index array" is resizeable, right? You should not wire N if you are autoindexing and the array is of the correct size.

Message 3 of 6
(111 Views)

I've found a similar problem in this forum, where a for loop is connected to multiple wires, in which case runs only the smallest number of times.

 

This isn't a problem, but just how LabVIEW behaves:

ShockHouse_0-1656538171909.png

Your N is wired up as a 4, meaning the for loop will only ever run at max 4 times. So now LabVIEW has to decide, should I run 4x, or should I run the size of the Actuators Position Change array size. It will pick the smallest number. Your Error In, Device Key and CmdLib do not need to be in the for loop. Since they are not arrays, they have no effect on how many loops are run.

 

0 Kudos
Message 4 of 6
(103 Views)

Hi altenbach, honored to be enlightened by the Knight of NI. Yes I'm a completely newbie and I appreciate pointing out potentially disastrous designs. That makes total sense that I'm bombarding the controller with commands, I will try giving the loop a wait before each iteration as you've suggested. I've also attached the VI files, they have some dependencies and need a controller connection so is un-runnable, but just for reference. Will get back to you after trying the fixes, thank you!

0 Kudos
Message 5 of 6
(90 Views)

Hello altenbach, the command-bombing was in fact the problem. Thankfully I wasn't flooding its memory or anything, the controller simply ignores other motion commands while in motion. After putting in a wait function in the for loop, it works as intended. I understood that wiring N is unnecessary when autoindexing and that inputs shouldn't be nested in loops, do you mind pointing me to other obvious flaws (just from screenshots) if there are any more? Again thank you greatly.

0 Kudos
Message 6 of 6
(74 Views)