Delay next iteration of loop based on conditional statement

[JDSuper]

Hi there, 

I am developing a program to control a DC power supply using a simple proportional control algorithm. 

However, the DC PSU has an inrush limiting capacitor which needs to charge before a current will be seen at the output. In previous control programs we set the output to 50 Amps for 30 seconds before ramping the current up to our setpoint using an manually created profile imported from excel. 

I have experimented with the proportional control code and it works fairly well, but could of course be improved. That's not the reason I am posting today. 

My main issue is timing the loop, or next iteration of the loop.

In my program I would like to: Check if the current value is 0. If true, set the next value to 50 and hold it at that value for 30 seconds. 
At the moment it appears the output is being set to 50 in the first iteration, and then to the next value according to the algorithm and then being held for 30 seconds. 

Can someone take a look at the attached code and help me to resolve this? Or point me in the direction of a better method?

Thanks, 

[Bob_Schor]

Many long-time LabVIEW users do not install the "latest version" of LabVIEW, hence cannot open the code you attached.  Can you please "Save for Previous Version" and go back 3-4 years (most of us have LabVIEW 2019 or 2021 installed).

What you describe should be fairly simple to achieve...

Bob Schor

[Yamaeda]

You basically just need to expand your case structure to a State machine. Separate your requirements into steps/states and have 1 case handle each.

Help -> Find examples -> Fundamentals -> Loops and Structures

[JDSuper]

Apologies. 

I thought I had saved for 2021 version. VI saved in 2020 version is attached. 

Having looked at my code for the past few hours I see my initial error. I was observing the "next value" variable rather than the "current value". 

Still, I would appreciate feedback as to how I have implemented this and how it might be refined, or done better in future. 

Thanks, 

JD

[altenbach]

Your code is seriously flawed, you simply need a state machine running at a reasonable pace, switching states as a function of time.

• None of your controls can be read once the VI starts. A VI in edit mode does not belong in a measurement setup.
• Equal comparisons with floating point values are extremely dangerous (=0, =50), especially is they are the result of computations involving fractional values.
• A 30 second wait does not belong in a toplevel loop!
• Your waits should be U32, not orange.
• There is a "+1" primitive.
• Of you show the digital display of the chart, you would not need the "next value" terminal.

[altenbach]

See if this can give you some ideas....

[JDSuper]

Hi Altenbach, Thanks for the response and for the attachment in your next comment. It's really helpful for me to see how I might improve my code. 

Just to state, this is definitely not in a measurement set up in its current state, its purely part of my own LabVIEW learning process trying to understand how something like this would work. With the aim of maybe being able to develop something more robust that. 

If you don't mind answering some follow up questions, I have replied to some of your comments below:

• None of your controls can be read once the VI starts. A VI in edit mode does not belong in a measurement setup.

By controls do you mean the numeric controls such as set point, gain etc? Is there a better place to have these so that they can be read? 

• Equal comparisons with floating point values are extremely dangerous (=0, =50), especially is they are the result of computations involving fractional values

This was a concern if we took this VI to a real situation, as the returned value of current is likely not to be precisely 50 and there would be some ripple/overshoot most likely. I can see that you have instead used elapsed time as the condition for controlling the case structure. I will try to use this kind of structure in future. 

• A 30 second wait does not belong in a toplevel loop!

Could you explain this a bit more?

Edit: Is this because the loop is waiting for 30 seconds, commands such as stop or any variance in process input will not be registered until the next loop iteration. 

• Your waits should be U32, not orange.

Ok. 

• There is a "+1" primitive.

Can I ask why is this bad? I see that you have just used the increment function instead 

• Of you show the digital display of the chart, you would not need the "next value" terminal.

Thanks, this also makes sense. 

Thanks again for the response and for taking the time to modify the VI and include as an attachment. 

[altenbach]

Many questions, and it seems you already answered some yourself.

A top-level interactive loop always need to spin at a reasonable rate so it can react to user interactions. Any controls that are before the loop will only get read once before the loop starts and it might be confusing to the users if they can change them during the run, but nothing happens. If you want to lock them during processing, they could be temporarily greyed out/disabled.

A real application needs to be a state machine and all states need to be exactly defined. You should allow the user to change the controls during run (define a reasonable range in the allowed input values in properties) and the program needs to correctly respond, depending on what state it is in. There needs to be an idle state, there needs to be a button to start processing and another button to reset, etc. The program should run when opened and start in the idle state waiting for user commands like an application, and close when done.

The time constant of the ramping function needs to be tuned to the loop rate.

I am sure you aware of floating point limitations. A simple example would be the following:

Trick question: What is the "output" value in the above code once the while loop completes?