Difference between PID gains in MAX and application

[jspaarg]

When I set MAX to the same gains that I am using in my application, the motor seems to behave differently when I use the interactive functions than when I use move commands in my app.

Has anyone experienced this?

windows XP.

PCI-7355, Motion version 7.2

MAX version 4.0

[Savageaggie]

Jspaarg,

Thanks for your post.  The PID control loop settings used in MAX will be the settings that the NI Motion driver will use to control motion on your board.  Before the settings from MAX take place, you must save and initilize your board to load the control loop values to the controller in firmware.

You also have the ability to change the values from LabVIEW through the "Load All PID Parameters.flx" VI.  This VI allows you to set all 8 PID parameters for the selected axis.  Once you make these changes, to have them take effect you will again need to initialize your board just like you would in MAX.  Use the "Initialize Controller.flx" VI to apply the new settings and download them to the firmware on your motion board.

Thanks,

Scott Savage

National Instruments

Applications Engineering

www.ni.com/support

[jspaarg]

Thanks for the response.

I know that about the PID settings.

In my app, I have a tuning function which saves the gains to my own file.

When my app launches, it reads the PID settings that it has saved and writes them to the 7344.

I cannot use them in MAX and I realize this.

Using the Control parameter config in MAX (or whatever the actual name is), I set the PID parameters to EXACTLY the same that I have in my app.

The motor seems to  behave differently when run from MAX as opposed to run from my app with IDENTICAL parameters.

My question is:

Why?

or

Am I seeing things?

[Savageaggie]

Jspaarg,

Thanks for your reply.  This is very interesting behavior.  LabVIEW uses the parameters in MAX (unless you overwrite them) to send motion control to your motor.  If you have the exact same parameters set in MAX as you change in LV (every parameter, not just the PID values) you must see the same result, as the parameters are shared by the driver for both spaces.  If you are not using NI-Motion version 7.2.1, please update to that version (we just released an update to 7.2 to make it more robust).  You can find the 7.2.1 update download here.  NI-Motion 7.2.1 is an update for 7.2, so if you are running a later version of the driver, you must first upgrade to 7.2, and then install the 7.2.1 update patch.

Thanks,

Scott Savage

National Instruments

Applications Engineering

www.ni.com/support

[jspaarg]

I have noticed a number of strange things in my system and have posted several threads with some of my observations.

I am running Motion 7.2 on Windows XP pro.

I  am using four amplifiers; three are on linear motors, one on a ball screw.

The amplifiers are Copley-Accelus, the linear motors are Parker-Trilogy, I don't remember the ball-screw mfg.

Two of the four linear motors drive the parallel tracks in an H-Bridge (X and X')

The third linear motor drives the crossbar.

The crossbar motor continually "drops out"; i.e. it gets following errors and will not restart.

The parallel motors seem to build up tension even though they report being at the same position.

The ball-screw works fine.

The behavior is inconsistent, particularly in the crossbar (Y axis).

Sometimes the holding force is non-existent and I can push it off with a slight finger-nudge.

Sometimes the holding force requires leaning into the motor to get it to break (which is how it should operate).

The failure mode is that a move command is issued and the amplifier seems to lose its internal enable.

It is only within the last few days that I am suspecting the amplifier, but the observation that the motor behaved differently with the same PID values from the two sources (which it should not), was more than a little disconcerting.

[Savageaggie]

Jspaarg,

I agree, all of this is strange behavior.  It could be the amplifier, the software driver, or the board.  I would suggest upgrading to Motion 7.2.1 and see if you stil notice anything out of the ordinary.  The holding torque for each axis is a combination of voltage out of our card and the amplifier.  You can verify the card by monitoring the analog voltage out.  If this seems to dip with a corresponding low holding torque, it could be that a part on your board has failed.

Thanks,

Scott Savage

National Instruments

Applcaitions Engineering

www.ni.com/support

[jspaarg]

Thanks for the advice.

I am new to this motion stuff but have been around the block for a lot of years on embedded systems (I've probably done things similar to the7344 on-board code).

Assuming that you have detailed knowledge of the 7344 and a significant amount of knowledge on general amplifier operation...

If my holding force changes with the same PID values,

I will check the output voltage when that happens (is a meter good enough, or do I need a scope?)

If the voltage is different does that guarantee a controller card failure?

If the voltage is the same, that would eliminate the controller card, but does it guarantee an amplifier failure?

Thanks

[Savageaggie]

Jas,

A normal DMM should be able to read the values fast enough, just work with small incremental changes in position (I have used a DMM before for troubleshooting the DAC).  If the voltage being output is in fact does dip unexpectedly, it would indicate that something on the PC end is bad (firmware on the board is damaged, software driver is corrupt, tuning settings are incorrect, etc).  If the voltage appears to be constant but the motor loses holding torque, then the other half of the system is suspect and almost guarantees that the amplifer is bad.

Thanks,

Scott Savage

National Instruments

Applications Engineering

www.ni.com/support