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

Re: Help with basic algorithm on LabVIEW
 

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.

Re: Help with basic algorithm on LabVIEW
 

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

Re: Help with basic algorithm on LabVIEW
 

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.

Re: Help with basic algorithm on LabVIEW
 

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

Re: Help with basic algorithm on LabVIEW
 

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!

Re: Help with basic algorithm on LabVIEW
 

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

Re: Help with basic algorithm on LabVIEW
 

OK, I've tested my program using a NI-ELVIS platform and everything is working as it should. Problem is, when trying to run it on the cRIO, I found out it doesn't support MathScript (how I wish I knew that early on).

Can I run the I/O part of the program (sensor readings and motor outputs) on the cRIO and the rest on the PC? I tried using globals to pass data between the VIs but it did not work. Did I do something wrong, or this approach is impossible?

Should I start porting my code from MathScript to G? Please, someone say no! ;)

Re: Help with basic algorithm on LabVIEW
 

What I'd do is contact your local sales rep. I don't remember hearing what version of LV you are using, but LV 2009 supports MathScript on the cRIO. So if you can explain your need, I suspect they will be able to help you out.

If they seem unreceptive, let me know in a PM and I'll see if I can find a way.

If 2009 doesn't support it, don't be too afraid of moving from the script to LV. It is often useful to take another pass at your code and think about each step in detail, for translation. You will often find questions for yourself such as, "why didn't I do it this simpler way?", or "I'm not sure why that ever worked!".

And of course it is better to ask yourself those questions than to have someone else ask them in your presentation.

Greg McKaskle

Re: Help with basic algorithm on LabVIEW
 

OK,

I'll try to get a copy of LV 2009.

Just to make sure, before I start thinking about porting the code: there's really no way to pass data between VIs that aren't running in the same platform (one on the PC and the other on the cRIO, in my case)?


Thanks again!

Re: Help with basic algorithm on LabVIEW
 

I didn't mean to imply that. There are plenty of ways. But to back up a step. The easiest approach should be to get a copy of 2009.

If it comes to it, the best ways to share data are Network Variables and TCP communication. There are subcategories of network variables, but I doubt it is worth going into unless you have questions.

Greg McKaskle

Re: Help with basic algorithm on LabVIEW
 

Greg,

Since it appears LV 2009 will not work yet, can you help me out on setting those Network Variables to pass data between the VIs running on the PC and on the cRIO?

Re: Help with basic algorithm on LabVIEW
 

There are three options I'll bring up.

Perhaps the easiest way to do this is to use the VI server to call functions and pass parameters and get return values. If you make a subVI with your data inputs and outputs, you can deploy it to the other target and call it using the VI Server.

To do this, you open a reference to the application providing the TCP address. The reference from that will let you access the VIs on the target and do things like call the subVI by reference. You may be able to do the operation in the remote call, but more likely you'll just copy the values to a global or queue or something on the target and return values from existing operations.

Option two is to use TCP, possibly UDP to send data buffers between targets. This is actually the way that the VI Server does it, so their performance will be similar. Both computers will open a port and one will write and the other read. Note that the timeout may need to be shortened to keep it from blocking your program. Look for examples that show how to do this.

Option three is to install or ftp the .out files to the controller to enable the network variables. Honestly, this is my least favorite option as I don't have much experience with it. Additionally, you'll find it to be a bit of a resource hog in 8.5.

Feel free to PM if you want to go into more details. Additionally, you may be able to find good info on this on devzone, on comp.lang.labview, or possibly on info-labview forums.

Greg McKaskle