Why does PID.vi not work inside a For Loop?

[drphil]

This is a someone inconsequential question, but can someone please explain why PID.vi does not seem to work when in a For Loop? As per the documentation, one is to use array inputs for multiple parallel PID controllers, but shouldn't a For Loop be the equivalent of this? I've attached an example vi that demonstrates this. When sending array inputs to a For Loop containing PID.vi the resulting calculation outputs the result for the first iteration on *every* iteration even though the inputs into PID.vi on subsequent iterations are different (verified by probes and highlight execution). 

...  In my project a PID control can be turned on/off in favor of manual control (% of scale manually inputted). On the first code attempt, it seemed like a waste to run the PID.vi for all channels when some were in manual control. This led me to try a T/F case structure inside a For Loop to run either PID.vi (True case) or calculated manual control (False case). But this was clearly not working. [note, this is not in the attached example code]. This was easy to work around by first sending all channels as an array to the PID control, then sorting out in the For Loop/Case structure which channels use the PID result and which use the manual scale result. However, for my LabVIEW learning I'd like to understand why PID.vi doesn't work in a For Loop.

Thank you,

[altenbach]

The PID VI (you can look at the diagram!) keeps state across calls in uninitialized shift registers. In your FOR loop, you only have one instance of the subVI, So the repeated calls step on each others toes, scrambling all internal data.

In the array polymorphic instance, data is maintained in arrays, one for each input. Use that! There is a very good reason it exists!

[AFLAMENT]

Please RAZ= true

[altenbach]

---

@AFLAMENT wrote:

Please RAZ= true

---

Bad advice! This is not a viable solution of the PID is called repeatedly in an outer while loop as it typically is. PID control is not a one-shot thing!

[AFLAMENT]

Don't scold me Champion ^^ ,problem is solved

I agree with you, PID inside a "for loop" isn't a good idea 

[Jay14159265]

---

@AFLAMENT wrote:

problem is solved

---

is it? 

[altenbach]

Yes.

[billko]

---

@AFLAMENT wrote:

Don't scold me Champion ^^ ,problem is solved

I agree with you, PID inside a "for loop" isn't a good idea 

---

He wasn't scolding you; he was pointing out bad advice.  I'm pretty sure that if Altenbach disagrees with your solution, the best thing to do is learn from it instead of getting all insecure and huffy about it.

[AFLAMENT]

Your answer is so ...interesting, thanks for your personal opinion. All my apologize Altenbach if I hurt you😶

[rolfk]

---

@AFLAMENT wrote:

Your answer is so ...interesting, thanks for your personal opinion. All my apologize Altenbach if I hurt you😶

---

I doubt you hurt him. In the worst case you moved a few steps up on his iggy scale. We are used to people arguing about criticisms to bad advice.

Your RAZ input set to true clears the internal state so yes you won’t have channels influence each other. Unfortunately you also cleared any state for each channel so next time you call this code it starts with a fresh state again. Basically calculating the PID initial state each time which is pretty much the same as if you had no PID in there at all. Not very useful!

You usually want to place a PID in your code for some reason rather than just having it calculate the initial state over and over.

And if you don’t call this code section repeatedly in your program, then a PID function makes no sense.