Simulation Loop ODE Solver

[Barp · Accepted solution]

Brian,

The RK-45 is a variable step size solver, which means that it won't sample in a evenly manner (in other words, you can take 5 step in 1 second and take another step after 5s). However, when you start using hardware Input/Output, you should always try to keep the sampling time constan. This means that should change your solver to a fixed step-size solver, like the RK-1. If you setup the Stepsize (s) equal to 0.001, it will step every 1 ms.

Also, if you go to timing parameters tab in the Simulation Loop configuration, you should also use the "Synchronize Loop to Timing Source" and check the "Auto Period" in Loop Timing Attributes. This change will make your simulation loop to run in "wall clock" defined by your sampling time. Just be careful that the maximum frequency in Windows is 1 kHz.

Hope this helps!

[bcglaxer]

Thanks, Barp. Helpful as always!

Of course, now I have another problem. My feedback loop keeps blowing up. I set the desired current with Operand1 which shoots the signal to the control gains and then to Maxon's VI that sets the current at the motor (I'm using a Maxon 24/5 Servo Controller). The Get Current Must.vi reads the current command and the VCS Get Current Is.vi measures the actual current. This VI tends to report reasonable values, but once it gets to the feedback node it baloons up into the hundreds of thousands which exceeds the maximum current of the controler and shuts it down. Any idea why this is happening? I realize it will be hard to recreate this behavior without the hardware, but the folks at Maxon don't do a lot with LabVIEW so I'm hoping you or someone else here will know what to do.

Thanks!

Brian

[Barp]

Brian,

It looks like you have some gain problem in your PID. Where does those values come from? How did you tune it? Also, one thing that is very important is that the PID implementation that you are trying to do with simulation (as a transfer function) does not have anti-windup capability, which means that if your controller goes beyond the saturation values, you will have 'accumulated energy' that have to be 'dissipated' until the error comes back to the range. To fix that, there is several techniques you could use.

For now, just try to just tune a P controller with smaller gains and, after you are able to get something working, you can try to use a PI and, if it doesn't respond fast enough, use the PID controller.

[bcglaxer]

I tried setting the P gain as low as 1.1 and it still blew up. Maxon says I have communication delays (around 100ms) between LabVIEW and the servo controller but didn't know how to fix that. Is there any way to speed up LabVIEW?

Thanks,
Brian

[Barp]

Brian

Delays can introduce lag in the measurement response and should be taken into account, of course. However, before we take that into account, we should focus on two things: try to find the sampling time and the P gain that will stabilize the system. Without this, you can't control the system. Is the 1.1 the smallest you can have? Try to reduce until you can have any kind of stabilitization. If you can't achieve that, you should investigate for a hardware problem or sensor problem, just to be sure if anything is not correct like inverting wires. Also, try to see how the system responds with open loop control. I don't know if you can just "spin" the motor, but if you can apply a voltage, you can verify if the voltage apply is what you expect and as you increase. Also try to see if you can measure the current as you go.

Anyway, the idea is for your to know if what you measure and what you are trying to control is working as expected. This is where most of the problem rely first. If you are able to control as expected, then the next advice is to obtain a simple model. Like apply a step response and see what your system responds. If you can apply a step, a impulse (apply a input for a short period of time and go back to zero). This will give a basic idea how the system behaves.

Please let me know how everything works and we can go from there.

[bcglaxer]

If I crank the P gains down below 1.1 I can get the system to be stable (I guess the control system on the servo controller is really robust) but when I fiddle with the sampling times, the simulation just seems to take longer to run. I'll set the simulation time to 10 seconds and with a .1 second sampling time, by my watch it will take about ten seconds. WIth a .001 second sampling time, it will take a matter of minutes. I'm not certain this is important for my application, but I'm curious about why this is happening.

Thanks again,

Brian

[bcglaxer]

Hi Barp,

I've been able to make a lot of progress, but the timing of everything still seems strange. In the simulation loop settings, I have set the Initial Time to 0 and the final time to 0.3 seconds, but the entire test seems to take about 10 real seconds. As much as I can tell, labview is recording data for the entire ten real seconds, yet affixing times to the date between 0 and 0.3 seconds.

I've used the following settings:

Initial Time (s): 0

Final Time (s): 0.3

Step Size (s): 0.001

Auto Discrete Time

Synchronize Loop to Timing Sequence

1kHz clock

Auto Period

Priority: 100

offset/phase: 0

Timeout (ms): -1

I'm having a terrible time trying to tune my control gains and I'm wondering if this timing issue is the cause. Any advice?

Thanks,

Brian

[Barp]

Hey Brian,

I assume you have the solver as Fixed Step Size - Runga-Kutta 1 with Hardware Syncronization on. Then, if you try to specify you time as 0.3 s but take 10 s "wall clock", then the computation type of your algorithm it longer then the time you specify.

To fix this, you have two choices: 1. try to transfer your code to a faster computer or multicore:the simulation node takes multicore into account and could improve the simulation speed. 2. try to increase the stepsize: you are using 0.001 s. Maybe try to use 0.002 or 0.005 to see if this would help to finish in time. If you see that the final "wall clock" time comes down, you should be able to control your system.

Also, are you using your controller on Windows? If yes, try to look for external processes that could be "taking" CPU time.

Any additional information like "Computer, CPU, OS" would try to help in thei process.

[bcglaxer]

Hi Barp,

I've increased the step size to .005 and now a 1 second test in Labview lasts about 10 seconds of wall clock time. Is this sort of thing normal? I'm still trying to determine if I can control my system or not (or if I can handle a higher step size), but I have a Dell Latitude D820 with a T2400 Processor @ 1.83Ghz using XP SP2. I didn't find many external processes running and the few that were weren't hogging any CPU time. Think this computer is powerful enough?

Thanks,

Brian

[Barp]

Brian,

The computer is not slow, however, you have RS-232 communication within the loop that could slow down considerably the simulation loop. To verify if this is the case, Simulation has a feature that allow you to execute VIs in a specific schedule than what you have. If you right click on the Driver VIs that you have inside the loop and select "SubVI Node Setup", you will see that you can execute those VIs as "Continuous" or "Discrete". If probably have continuous selected, then change to discrete and choose a sampling time "0.1" just to see if you can have the "wall time" to match the simulation time.

On a side note, Maxon motors drivers allow you to setup current control. Have you consider setup this way? Also, since you are doing current control, it could be possible that RS-232 would not be fast enough to close the loop in a timely matter. Do you have the option to control by voltage?