Motion Control and Motor Drives

cancel
Showing results for 
Search instead for 
Did you mean: 

Drive and Encoder work in Open Loop but not in Closed loop

So I've done some motion in the past (long ago) and someone else wired it all up and set it up and I just coded it.  It all seemed to work.  I've just started a new project where I'm responsible for all of the hardware and software and I'm encountering what I would call a very strange condition that doesn't seem to fit my understanding of how everything is supposed to work.

 

Here is my setup

Motor: Parker LV233-02-FL running in parallel at 24VDC

Encoder: USDigital E4T-100-250-D-H-D-B

Driver: Danaher P-70530

NI UMI 7774

NI PXI 7334

NI Motion 15.0

MAX 16.0.0f0

Running on a NI-PXIe chassis under Win7

 

So for setting it up, I pulled all the motor specs and entered them into the Danaher P7000 program.  Doublechecked everything there.  It is all correct.  For the encoder, I entered everything into the Motion settings in MAX. I figured out to use 4 times the cycles per revolution given in the documentation in the encoder.

 

Everything appears to work open loop.  The motor is 200 steps/rev.  If I run it 200 steps open loop it does exactly 1 rev.  And watching the encoder, it gets exactly 400 counts which is what I expect. If I cut the power to the motor and turn it by hand, the encoder still gets 400 counts/rev.  And the polarity is correct in that positive motion equals positive counts.  I'm 99% sure I got all that setup correctly.   I even tried reversing the polarity of the encoder inputs in MAX just in case and still got the same results.

 

Here is my issue:

When I run it in closed loop I keep getting following errors.  I have no idea why.  If both the motor and encoder work as expected in open loop, then why does it not work in closed loop?  Are there some PID settings I need to change or something?  

 

As far as troubleshooting:  I verified all the settings as above. Rang out all the connections.  It seems like all of that would be correct since it works in open loop.  I tried changing axes and had the same problem.  I have 2 7334 cards so I switched cards. Same problem.  I don't have another UMI board at the moment.  I tried setting the following error setting to 0 as suggested in the help to disable checking the following error and still got the error.  I set it as high as it would go and was able to run the motor for short distances.  However when doing this I noticed I was not getting the counts I was expecting.  I also tried adjusting the acceleration and speed and that makes no difference. I still get the same erratic behavior.

 

What is it about enabling the feedback that is messing with the encoder readings? Do I need to change some PID settings?  I t would seem to me that if MAX was reading in the encoder correctly in open loop, that it should still read it in correctly in closed loop.  Am I missing something here?

Anyone have any ideas?  Any more troubleshooting things that I missed?

 

Sam

 

 

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 1 of 9
(3,396 Views)

I should also add that once I got the PXI chassis set up, one first things I did was update the firmware on the Motion Controllers.

 

They are running:

68331 Firmware 7.40.3003

DSP Firmware 7.32.3003

FPGA1 Firmware 7.00.3001

FPGA2 Firmware 7.00.3002

 

Hope that helps.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 2 of 9
(3,369 Views)

The cause of your following error may be that the Encoder Input Resolution is set improperly in MAX. This setting should be 4 times the number of pulses per revoltion of the encoder, because it reads both the rising and falling edges of the A and B lines and sends MAX the number of edges read, not the number of pulses. Please see Case 1 in the KnowledgeBase article linked below for more information. There are some other good steps for troubleshooting following errors in this article as well.

 

KnowledgeBase 3QGEF7D3: Following Error in a Motion Control System

Aaron Douglass
Applications Engineer
National Instruments
0 Kudos
Message 3 of 9
(3,350 Views)

Thanks for the suggestion, but I had alreadey found that document and tried all those.  The one I didn't try is case 3 - changing the PID settings for the servotune, because I am using a stepper.  Are there PID settings for a stepper?  Also I've tried various velocities and accelerations and nothing seems to make a difference.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 4 of 9
(3,348 Views)

Here is the configuration from MAX if that helps.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 5 of 9
(3,339 Views)

After doing some more digging, I think the problem you are running into is that your encoder is 100 count per revolution, but your motor is 200 steps per revolution. Since your motor is higher resolution than your encoder, MAX thinks the encoder feedback is behind the motor position and throws a following error. 

 

There are two options to resolve the following error that I see. One is to use open loop control, as you have already done. The other is to get an encoder that has a resolution of at least 200 counts per revolution. 

 

Note: If you are micro-stepping, you will need an encoder with a resolution greater than or equal to the number of micro-steps per revolution. 

Aaron Douglass
Applications Engineer
National Instruments
0 Kudos
Message 6 of 9
(3,324 Views)

That does seem to make sense, but the encoder is 100 cycles/rev, which means that MAX sees 400 counts/rev (because it sees each transition) which would be higher than 200 steps/rev.  Am I thinking about that right?

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 7 of 9
(3,321 Views)

The number of counts (400) for your encoder refers to the number of edges the encoder is reading. There are two channels on each encoder. Each channel has 100 positions, which is the resolution. The quadrature encoder counts the leading and trailing edge of each position on each channel, which brings us back to the 400 counts. The resolution is still 100 though. The additional channel does not add resolution, it allows the encoder to tell which direction the motor is turning. 

 

One software setting you can try before making a hardware change the number of Pull-In Tries to zero in MAX. This setting can be found at Device and Interfaces»NI-Motion Devices»Default 73xx Configuration»Axis x»Axis Configuration»Stepper Settings. You could also try increasing the Pull-In Window.

 

 

Aaron Douglass
Applications Engineer
National Instruments
0 Kudos
Message 8 of 9
(3,308 Views)

That makes a lot of sense.  I ordered a new encoder.  I'll let you know if that works.   I suspect it should fix the problem.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 9 of 9
(3,218 Views)