PID motor control problems

[jimmyinct3]

Im having trouble with a linear motor drive application.  Im using a motor/servo drive to power a linear drive.   The drive is running in torque/current mode so that the output current/force is proportional to an analog input which is sent to it (no tuning parameters).  For this particular application, Im using the express vi "configure simulate signal" to create a sin waveform which is being used as the setpoint and then inturn helps determine the voltage sent to the motor and thus, output force.  The voltage from a load cell is then read via PCI 6014 and convetered back to a level which can be compared to the analag output scaling factor for torque mode.  There is a also a PCI 6601 used to determine position, but should not be relevent here.

Without PID.     By using a load cell, I can see that the sin wave is being truncated on the top and bottom, being that it rises to fast in response to the voltage and then plateaus.  The reciprocal happens during unloading and it reaches low load to soon and there is also truncation. I will attach a figure which can demonate the problem better than i can explain it.

 

Without PID.   This is not a saturation effect though as I can raise the magnitude of the input voltage, and the force will follow the same type of waveform but at new load levels.   Ill. attach a 2nd screen shot of new load levels of 2000lbs.

 

I can look at the output current/voltage levels from the servo drive which feed the linear drive and they are perfect sinusoids, following whatever the input voltage is, whether guided by PID or not,  its an exact mirror, without truncation like occurs in the above figures.   There are also no speed or acceleration problems, and this is well under the limit the speed this system can run at, ie running 0.25htz and it can run 50htz at these displamcements.  So these are not the problems.

From what I understand, PID is commonly used to correct for this type of problem and is standard with machines that need to produce force in this manner..  Infact, I was told by the people who make the drive i need to use it to fix this type of problem.   Yet, Im not able to get it to work. I have tried changing the P term accoring to the N?I document below and it dosent seem to fix the loss of the peak, so Im doubtful the I or D terms will do much (and have tried without luck). Ill attach a third screen shot and link inthe general PID guide below

http://zone.ni.com/devzone/cda/tut/p/id/3782

with PID, with P increased so some instablity starts

 

Ive tried reinstallilng labview on a different comptuer, along with PID and am getting identical results.

Ill attach the code I using, not taht Im expecting anyone to look, its rather large.

Any help is greatly appreciated.

Message Edited by jimmyinct3 on 04-19-2010 04:49 PM

Message Edited by jimmyinct3 on 04-19-2010 04:52 PM

Message Edited by jimmyinct3 on 04-19-2010 04:53 PM

[jimmyinCT]

i forgot to say, the figures might be a little bit confusing.

The D to A, which is the analog voltage sent to the servo drive by the 6014, is opposite in voltage than the load that is created.

So with increasing negative voltage, i get larger postive loads in tension.

Positive voltages, which are not used, would produce compression.

[Jochen]

Jimmy,

the first and most important rule for closed loop control systems is torun them in a deterministic environment. Running this application on Windows will result in significant jitter, which makes it very hard or even impossible to get stable system behavior (jitter is at least as bad as wrong PID parameters). So my first advice is to switch over to areal-time operating system. If your PC meets some requirements, you may be able to keep working with your existing hardware.

Additionally to a deterministic environment you need to redesign your vi. Even on a real-time operating system you carefully need to seperate real-time tasks from less time critical tasks. In your vi everything runs in a single loop, including screen outputs, control invoke nodes, dynamic memory allocations with "build array" (very bad) and more stuff, that adds significant jitter to your control loop.

Kind regards,

Jochen Klier

National Instruments

Message Edited by Jochen on 04-20-2010 09:49 AM

[jimmyinct3]

thank you for your time.

the timing issues is something that crossed my mind.

that is part of why we slowed down the sinsuiod waveform to 0.25htz, or one cycle each 4 seconds.

the labview program itself is cycling approximatly 2000 times each second, which is around 8000 PID guesses per period of the loading cycle.

Id really like to be sure about the problem before i sink a lot of money and time into something (real time deployment license for desktop PC) that might not fix the problem.

Its just alittle skeptical about needed real time if PID VI cant make an accurate approximation at this slow rate, even with some windows interrupts occuring.

Is there a problem with the inputs to the PID VI, ie, do the set point and process variable have to be the same amplitude?

Its very hard to do the mapping of I/O through linear relationships.

Message Edited by jimmyinct3 on 04-20-2010 03:22 PM

[Jochen · Accepted solution]

Jimmy,

if your control loop is not running with deterministic timing, higher rates of change of the setpoint impair the situation, so the limited quality of the control loop also limits the frequency of your sine wave. On the other hand, the loop itself is still running at 2 kHz, so the loop time and the jitter have the same order of magnitude, so it will be very hard to get a stable control system with this setup. Reducing the control loop rate is also not a solution, because linear motors are very dynamical systems, that require closed loop control in the kHz-range.

To improve the situation with your current setup, you still could try to better structure your vi, remove dynamic memory allocations and so on, but the improvements will be quite limited. In fact there is a reason, why NI is very successful with products like LabVIEW RT or compactRIO and the reason is the deterministic behavior of these platforms which is required by dynamical closed loop control applications.

To answer your question about the amplitudes: A PID controller tries to generate an output signal, that results in setpoint - PV = 0. So e. g. if your load cell outputs 0.5 V/N and you want to generate a force of 10 N, the setpoint needs to be set to 5. This means, the scalings of the setpoint and PV need to match, but that doesn't mean, that you necessarily need to scale the PV before you pass it to the PID controller. Instead you could scale the setpoints to map it to the feedback signal. The advantage of this approach is the fact, that you wouldn't need to do online calculations on the feedback signal, as you could precalculate a setpoint array before you start the move. For this approach you would calculate your calibration data into the values of the setpoint array.

If you follow this approach, you also could think of using a standard motion control card like a PCI-7352. This board takes care of all real-time control tasks onboard, so no LabVIEW RT is required and you could pass the precalculated setpoint arrays to the board's memory (contouring mode).

I hope this gives you some ideas how to proceed from here.

Kind regards,

Jochen

Message Edited by Jochen on 04-21-2010 09:28 AM

[jimmyinct3]

I reevaluted this problem again today and figured it out.

Ill post the solution just incase it helps someone sometime..

So on this particular motor controler, there is a time constant on the ADC input.

I had to set it to zero to shut off filtering.

then the PID started working like a charm.

i did have to match the input peak to peak valuues of the pid to that of the output.

i just made a simple scalar multipler term for that.

 but it would have never worked without removing the time constant.

anyway, thanks for the help and "kudos"