Help with basic algorithm on LabVIEW

[Manoel]

Originally Posted by BLAQmx

Do you think you can draw your algorithm as a flow chart? If you can it will be much easier to change your pseudocode (flow chart) into LabVIEW code (data flow).

Do you have any part of your program already implemented in LabVIEW? If you do post a screen shot or a VI so others can give you tips on what to do next.

Cheers,
Mark

Hopefully this helps!

[Greg McKaskle]

I'm confused as to what you are wanting, so I've attached a typical low-tech UI wrapped around a loop that does single point I/O, ctl, and output and accumulates the values for further processing. Perhaps some part of this helps.

If you want a higher tech UI using the event structure, I'll post one of those too, but since RT doesn't do events, these simple polling UIs are often useful.

By the way, the False case is the wire going through, and a delay of 50ms, just to slow down the UI and avoid reading stuff 1,000,000 times a second. You could also put processing or display of the entire dataset there.

Also, I'll describe the other thing that is often useful. Build a simple subVI that takes in your setpoint, the process variable and the output. Chart all of them on the subVI similar to how you'd see in a textbook. You can drop these near any control block, and wire it up. While the panel is closed, not much is going on, but you can open it, bump the setpoint and watch the oscillations and other effects of the control. You close the panel when you don't need it.

Greg McKaskle

[Manoel]

Originally Posted by Greg McKaskle

I'm confused as to what you are wanting, so I've attached a typical low-tech UI wrapped around a loop that does single point I/O, ctl, and output and accumulates the values for further processing. Perhaps some part of this helps.

If you want a higher tech UI using the event structure, I'll post one of those too, but since RT doesn't do events, these simple polling UIs are often useful.

By the way, the False case is the wire going through, and a delay of 50ms, just to slow down the UI and avoid reading stuff 1,000,000 times a second. You could also put processing or display of the entire dataset there.

Also, I'll describe the other thing that is often useful. Build a simple subVI that takes in your setpoint, the process variable and the output. Chart all of them on the subVI similar to how you'd see in a textbook. You can drop these near any control block, and wire it up. While the panel is closed, not much is going on, but you can open it, bump the setpoint and watch the oscillations and other effects of the control. You close the panel when you don't need it.

Greg McKaskle

Hi Greg,

Thanks for the help, but the control part is already working - in simulation, at least.

What I really need to do is the simpler stuff that I outlined above:

- output a specific setpoint, and measure output and control variables for a period of time
- only after the first experiment is over, output a different setpoint, dependent on the output variable measured in the first part of the experiment, again, for some defined period of time
- calculate using the data obtained in the two experiments, then iterate

You can replace setpoint, output and control variables with any name you want, since that's not the part that I'm stuck - it's the algorithm itself.

[Greg McKaskle]

I think the thing I'm missing is what your overall goal is, autotuning perhaps?

If you take the nested loop I posted and after the inner loop, where the label Save to disk, etc. is located, and you put your code to analyze the data and recompute the coefficients, then have them update the local variables before the next loop runs. Then change so that the Run button controlling the case turns into some logic for how often you want to run or simply to run every iteration and control how often the outer loop runs.

Greg McKaskle

[Manoel]

Originally Posted by Greg McKaskle

I think the thing I'm missing is what your overall goal is, autotuning perhaps?

If you take the nested loop I posted and after the inner loop, where the label Save to disk, etc. is located, and you put your code to analyze the data and recompute the coefficients, then have them update the local variables before the next loop runs. Then change so that the Run button controlling the case turns into some logic for how often you want to run or simply to run every iteration and control how often the outer loop runs.

Greg McKaskle

Yes, the goal is autotuning, but I think that is irrelevant with respect to the simple problem I'm facing.

In the simplest terms, what I want is to run a for loop for a number of times, without blocking execution of the rest of the code (hence, a flat sequence doesn't work) and, after that loop is finished, run a different loop, again without blocking execution.

I need to have data dependency between the two for loops, but not for each iteration, only when the loop has completely finished. I'm thinking a state machine that changes state comparing the current iteration count with the desired number of iterations, should work. Will it or will it not work, or is there a better way?

[EricVanWyk]

Originally Posted by Manoel

In the simplest terms, what I want is to run a for loop for a number of times, without blocking execution of the rest of the code (hence, a flat sequence doesn't work) and, after that loop is finished, run a different loop, again without blocking execution.

I don't understand why a flat sequence doesn't work. Do you need the loop to continue to function while you are computing new values?

My understanding is this:
You have other tasks unrelated to this that must continue.
You run your control for a while.
Stop this control loop (but nothing else)
calculate new inputs for the control loop
run the control loop with the new inputs for a while

A flat sequence won't stop other tasks.

Originally Posted by Manoel

I need to have data dependency between the two for loops, but not for each iteration, only when the loop has completely finished. I'm thinking a state machine that changes state comparing the current iteration count with the desired number of iterations, should work. Will it or will it not work, or is there a better way?

Why doesn't a loop in a loop work?


Could you please post your code?

[Alan Anderson]

Originally Posted by Manoel

In the simplest terms, what I want is to run a for loop for a number of times, without blocking execution of the rest of the code (hence, a flat sequence doesn't work) and, after that loop is finished, run a different loop, again without blocking execution.

LabVIEW runs everything at the same "level" at the same time. If you put "the rest of the code" next to the sequence rather than inside it, the loop inside the sequence won't block it.

I'm pretty sure your description of what you want isn't getting your situation across clearly enough for us to understand the problem. The way I'm reading it, there doesn't seem to be a problem.

Is there something inside the loop that needs to be used by "the rest of the code"? If that's the case, you might try using a global variable to extract the value from inside the loop and use it in the parallel task.

Is there something in "the rest of the code" that needs to run synchronously with the loop execution? If so, you could try turning that part into a subVI and include it as part of the loop.

[Manoel]

Originally Posted by Alan Anderson

LabVIEW runs everything at the same "level" at the same time. If you put "the rest of the code" next to the sequence rather than inside it, the loop inside the sequence won't block it.

I'm pretty sure your description of what you want isn't getting your situation across clearly enough for us to understand the problem. The way I'm reading it, there doesn't seem to be a problem.

Is there something inside the loop that needs to be used by "the rest of the code"? If that's the case, you might try using a global variable to extract the value from inside the loop and use it in the parallel task.

Is there something in "the rest of the code" that needs to run synchronously with the loop execution? If so, you could try turning that part into a subVI and include it as part of the loop.

OK, as I organized my code to share with you guys, I think I made significant progress.

I have attached the code below.

Running the main VI, toggle Activate control to initiate the PID calculations. When clicking Run IFT, the IFT_loop VI is called, and that's the only part not working the way I want it to.

Looking at the code for that particular VI, you can see I have a flat sequence with a for loop in each frame. The problem I'm facing is that I want to output the "Setpoint out" to the main VI in every loop of the program (every 20 ms), and not only when the frame is finished, as it is currently implemented. Using property nodes to set the value is probably a bad idea, and it's not working anyway. I believe I'm missing something really simple now, and I think the problem is now clear to understand. If it is frustrating trying to help and not understading the problem, imagine not being able to explain it clearly, as I was before (hopefully not now). Communicator's fault, of course

[Jared Russell]

Once you get your code worked out I'd be very interested to see how you have gone about implementing autotuning/optimization. My MS thesis was on simulation-driven approaches to optimal controls.

[Greg McKaskle]

It makes much more sense now. This is why we still program computers with code, and not descriptive paragraphs in a forum.

LV executes as a synchronous dataflow push language. Since it is synchronous, it means that nodes synchronize their execution and data production. It means a subVI will not produce its outputs and write to its caller's wires until it completes. It also will not begin until all of its inputs have arrived. In your case, this means that the IFT runs once each time your PID and model run. Its internal loops run to completion, and return the last value in the loop each time it is called.

What to do about this. You have two options. I'll describe both and let you decide which direction to go.

Option A is to merge the IFT loop and state with the loop in the caller, Main. Assuming your setpoint will change more slowly than your PID and other elements will execute, you will continue calling IFT each iteration, and occasionally it will change the setpoint, advancing it to the next value in the sequence. It will need something to trigger off of, and I think time is the appropriate choice here. You can use the coputer clock and have each of the subVIs read the clock and make changes as time advances. It will be somewhat more flexible if you move from computer time to an abstract system which you advance independent of the computer clock. This would be necessary if your system responds on a very different time scale than the computer -- simulation of an ice age or tokamak reactor for example.

The second choice is to move some of your dataflow from synchronized wires into unsynchronized storage such as a global variable. If you take the setpoint, and perhaps MV --since this doesn't change, I'm not sure what to do with it -- and make a global variable called setpoint, you can now have unsynchronized loops access the setpoint. Your Main program now has two loops, the one which calls PID and model using the current value of setpoint, and the independent loop that updates setpoint to perturb the system. You may also find it useful to grab the setpoint and change it by hand to see how the system responds. You'd do this by either opening the global panel or making your Main panel have a mode where you write a panel value to the global untimed.

I think that this less synchronized approach may work fine for you, and possibly be easier to program. It introduces globals, but LV makes parallel access to globals quite safe. If the loop time increases or you want more guaranteed synchronization, the merged loop is better in that regard.

Hope this helps.
Greg McKaskle

[Manoel]

Originally Posted by Greg McKaskle

Assuming your setpoint will change more slowly than your PID and other elements will execute, you will continue calling IFT each iteration, and occasionally it will change the setpoint, advancing it to the next value in the sequence.

Greg,

The problem is that, when IFT is enabled, the setpoint changes (or should change, if the program was working ) for every loop of the main program.

Basically, the sequence I want in the main loop with IFT enabled is this:

Run PID, run the simulated plant, store MV and PV in an array (until the array is N elements long), and calculate a setpoint to be sent to the PID block in the next loop.

I have tried a state machine as well, but with every solution I come up with, the problem is the same: the setpoint should be updated every iteration and it is not.

[Greg McKaskle]

I understand that you want the setpoint to change , but by using a wire to carry the values between them, it will not and cannot. If you switch to using a global variable, it will allow the loops to run independently -- there will be no dataflow wires between them. This is the simplest way. If you get it to work, you can also play with the state machine again.

Greg McKaskle

[Manoel]

Hi Greg,

I got most of the program to work (using MathScript), I'll post it when it is working 100%.


Now I have to deploy it to the cRIO, and with that comes a question: how to retrieve data from it? If I save a spreadsheet file, which path should I use? And how do I get it back, FTP?

Or is there a way to save the file to the PC, or send data straight to it (without the dashboard, of course. I'm trying to keep it as simple as possible).


Thanks again!

[Greg McKaskle]

If you save the data to file, ftp is a pretty easy way to retrieve the files. You can see things onscreen using the normal RT panels as long as the data content or rates allow it.

Another option is to use tcp or variables to transmit it to the PC.

Greg McKaskle