5i25 with 7i77

PCW wrote:

A couple things:

1. Expect analog drives to drift somewhat if the loop is not closed
This should not be an issue since the drives should not be enabled
until linuxCNC is running and the position feedback loop is closed.
(actually getting the drive enables working is the first thing to do)

2. When you first connect the drives and enable feedback, you may have the feedback reversed so the drives runaway (till you get a following error)
You should follow setup/tuning instructions like JTs here:

gnipsel.com/linuxcnc/tuning/servo.html

To relate this to pncconf's 'open loop' test - it will drift because there is no PID connected.
The open loop test to to test/conform the feedback and command direction.
When you press the positive button the the feedback should count positively and the axis should move positively.
You can also confirm the scaling is right.

Once you confirm this then you should tune PID in AXIS.

Chris M

To change the sign of the analog outputs, change the sign of the output scale in the ini file, this reverses the direction that the servo is commanded. The output scale in the ini file sets the value for the hal pin hm2_5i25.0.7i77.0.1.analogoutN-scalemax

After working with the machine a bit more I have been unable to find any error in the wiring. When I inverted either the motor or encoder signals, I get an actual runaway servo with the classic characteristics. What I am experiencing does not appear a runaway servo. I am a bit perplexed as to what is going on at this point so I will have to spend the weekend troubleshooting a bit deeper. I will check for stray electrical signals and EMI to the best of my abilities. I have an old analog oscilloscope that I will try my best to examine the waveform coming out of the encoders with. Any suggestions on other things to check for or any pertinent information in general? All help is greatly appreciated

I would verify that the encoders are scaled properly and do not have a noise problem or lose/gain counts.

You can check this even without the linear axis connected by checking the rawcounts pin in hal after multiple turns of the shaft (with an alignment mark/tape on the shaft) every rotation should end up being different by the number of encoder counts/turn
(4X the encoder PPR)

Also you must change the sign of the output scale in the ini file to reverse the outputs
_DO NOT_ swap the drive leads since if the drive has a common input and you wire AOUTx to that pin you will short out the 7I77 analog output.

Setting the following error quite large will help diagnose feedback issues

For initial PID values, I would use a small P (say .1) and everything else 0

Then a halscope plot of commanded position, encoder position and analog out
would help remote diagnosis of whats going on...

Could you elaborate a little bit about how to verify that the encoders are scaled properly? There is a label on the encoder cover that reads LHE-509-2000, so I am tempted to assume that model number indicates a PPR of 2000. I am a little unclear about what you mean in regards to 4x the encoder PPR, could you elaborate on that equation a bit?

Turning down the P value should be very interesting because the only values I have attempted in that parameter so far have been 50 +- 10.

NauticalMachinest wrote:

Could you elaborate a little bit about how to verify that the encoders are scaled properly? There is a label on the encoder cover that reads LHE-509-2000, so I am tempted to assume that model number indicates a PPR of 2000. I am a little unclear about what you mean in regards to 4x the encoder PPR, could you elaborate on that equation a bit?

The PPR "pulses per revolution" usually refers to the number of lines on the encoder wheel. Linuxcnc does not count the pulses, it counts the edges of the pulses of both sensors. So it will count 4 edges for each line of the encoder and wheel that is what the "quadrature" term is referring to. So with a 2000 PPR encoder, Linuxcnc will see 8000 counts per turn.