Help with basic algorithm on LabVIEW
 

I'm not too good with LabVIEW and I'm using it to implement some code to run on the cRIO.

The very basic algorithm I have to implement is:

a) Apply a user-defined setpoint to a control system, then measure its output and control effort for a user-defined number of samples, sampling at a user-defined sample time (ie, 40 samples at 20ms).

b) Apply a different setpoint that is dependent on the data acquired at step a), then perform the same measurements.

c) Using the data measured at a) and b), along with some other user-defined parameters, calculate stuff (I'm using MathScript for that), and iterate everything all over again, for a number of user-defined times.


Any ideas on what's the best way to do it? Please ask for clarifications, if needed.

Re: Help with basic algorithm on LabVIEW
 

Big clarification needed: is this to be run from a PC, or will it be a "deployed" program running without benefit of front panels?

Re: Help with basic algorithm on LabVIEW
 

It will be run from a PC - I have a nice front panel set up, and some auxiliary functions (PID loop, simulated - for now - plant, user input, etc.) working.

What I really can't get to work is the algorithm outlined above. Data dependency and parallel executing just doesn't seem to go well with simple algorithms - I'm sure there's a way to get it to work, though. :ahh:

Re: Help with basic algorithm on LabVIEW
 

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

Re: Help with basic algorithm on LabVIEW
 

If you're having problems getting specific sections of the program to run in a specific order, don't fret. Simply use the Flat Sequence control structure, putting each section in a frame of the sequence. The code in the first frame will run to completion, then the second frame, and so on.

Re: Help with basic algorithm on LabVIEW
 

If you make the sub-algorithm a sub-vi, re-use will become a lot easier.

You could make a while loop with shift registers that loop back your parameters, and the user inputs the first round's parameters.

Re: Help with basic algorithm on LabVIEW
 

I tried that, and it didn't work - for my purposes, that is. ;)

Since I'm generating data that is to be sent sample by sample to the control process, using the flat sequence structure (and a for loop inside it, both to generate data and build the arrays of collected information) will give me a batch of data - while freezing the rest of the program, such as the PID calculations - after it runs.

I'm not sure I'm being clear enough, again, please ask for clarifications!

Re: Help with basic algorithm on LabVIEW
 

Hopefully this helps!

Re: Help with basic algorithm on LabVIEW
 

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

Re: Help with basic algorithm on LabVIEW
 

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.

Re: Help with basic algorithm on LabVIEW
 

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

Re: Help with basic algorithm on LabVIEW
 

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?

Re: Help with basic algorithm on LabVIEW
 

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.
Why doesn't a loop in a loop work?


Could you please post your code?

Re: Help with basic algorithm on LabVIEW
 

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.

Re: Help with basic algorithm on LabVIEW
 

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 ;)