Help with basic algorithm on LabVIEW

[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

[Manoel]

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!

[Greg McKaskle]

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

[Manoel]

Originally Posted by Greg McKaskle

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

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!

[Greg McKaskle]

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

[Manoel]

Originally Posted by Greg McKaskle

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

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?

[Greg McKaskle]

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