Trouble Shooting Universal Stepper Controller with Gecko Interface

3DTOPO wrote:

Why did you solder wires to the USC?
No matter what wire I tried and techniques using the push slots, I always had trouble with wires falling out or not having solid connections.

Yes, people did have issues with those.  We changed to 2-part screw terminals on later units.  The old style needed 26 gauge stranded wire with thin insulation for the punch-down tines to work.
Jon

(Sorry for my mess of quotes. There was no preview and not exactly sure how the feature works)

Hmm, so the plot thickens. I tried with power as you suggested, while I have 78V on J7 of the Gecko Interface, turning the Axis Power button on does not apply power to the servos.

I have a physical e-stop. Pressing it works as expected (stops in Axis) and unstopping it works as expected.

Is there anything I can check why power is not being engaged on the Gecko Interface? Thanks!

Once again, my bad! I had a jumper (for trouble shooting) on the Y gecko drive preventing the Gecko Interface from being enabled.

So - good news is the machine is mostly working. Commanded the working axes and they worked as expected. The X, mostly works - I can move it from left to right using the manual control, but unlike the Y axis, it keeps running until I reverse the direction. eg if I command X to run left 0.5" it keeps running until I hit the right button. Then can make it go right.

If it helps I can get a video.

I should add that, the Gecko does keep the X servo stable, so I guess it's somewhere between the Gecko A/B signals and the Gecko Interface or the USC?

Is there any terminals you might verify? I recall being able to check the encoder signal somehow, like some kind of voltage indicates the signal is good? I think it would be interesting to check the signals on the terminals of the Gecko Interface and appropriate pins on the USC.

I have done a continuity check and the the signal pins at J1 of connect to the Phase A/B terminals on the GeckoDrive.

3DTOPO wrote:

Once again, my bad! I had a jumper (for trouble shooting) on the Y gecko drive preventing the Gecko Interface from being enabled.

So - good news is the machine is mostly working. Commanded the working axes and they worked as expected. The X, mostly works - I can move it from left to right using the manual control, but unlike the Y axis, it keeps running until I reverse the direction. eg if I command X to run left 0.5" it keeps running until I hit the right button. Then can make it go right.

If it helps I can get a video.
 
Wow, this is pretty odd!  But, I'm guessing that it is not showing the same movement with the on-screen position display.  So, what is happening is that one of the encoder channels (A or is not getting through to the USC.  The Gecko interface receives the encoder signals on J5, and then this is wired to P3 on the USC.  I assume you have looked for a broken wire between Gecko interface and the USC.  So, if no broken wire, then one channel of the USC's encoder input has gone bad.  If you wire up axis #3 between Gecko interface and USC, then you could make a few changes to move encoder functions and stepper functions from channel 0 over to channel 3 and it should then work.
One other thing to check for is if there is a short between the A and B signals for the X encoder, anywhere between the encoder, gecko interface and USC.
If the position display DOES work, counting in both directions when you get it to move both ways, then the problem is in the Gecko interface, not properly sending encoder signals over to the gecko drive.
As for testing, You can look at the encoder signals A and B on gecko J5 and ISC P3, the A and B (respectively) should be identical.  If not, you have a broken wire.  I don't understand this "keeps running".  Either the USC is sending out pulses continuously because LinuxCNC is not seeing the movement, or the Gecko drive is trying to correct the position because IT is not seeing the motor spinning. 
Jon
 

Thanks for the tips, I'll look into them.

Your assumption is correct; the X drive is moving but the position is not being updated in Axis.

So it appears that I had the foresight to connect the W of the Gecko Interface to the USC.

Do I just swap axis.0.motor-pos-fb with axis.3.motor-pos-fb and unplug J1 and plug it into J4? Or any other changes?

Thanks for all your help Jon! You’re legendary.

//univstep_servo.hal
# connect position feedback to PID loop
linksp Xpos-fb => pid.0.feedback
linksp Ypos-fb => pid.1.feedback
linksp Zpos-fb => pid.2.feedback
linksp Wpos-fb => pid.3.feedback

# connect position feedback to motion module
linksp Xpos-fb => axis.0.motor-pos-fb
linksp Ypos-fb => axis.1.motor-pos-fb
linksp Zpos-fb => axis.2.motor-pos-fb
linksp Wpos-fb => axis.3.motor-pos-fb

So I switched all occurences of .0 with .3 in univstep_motion.hal and univstep_servo.hal (and 00 with 03 along with AXIS_0 with AXIS_3) and in Axis, the X is acting just like it was.

While I swapped out the encoder on the X to test it, I did not use all different cabling coming in from the the encoder.

Since the Gecko properly holds position, I gather that there HAS to be a bad connection somewhere between the encoder and Gecko Interface or between the GeckoDrive and Gecko Interface?

3DTOPO wrote:

So I switched all occurences of .0 with .3 in univstep_motion.hal and univstep_servo.hal (and 00 with 03 along with AXIS_0 with AXIS_3) and in Axis, the X is acting just like it was.
Well, that may not be right.  You ONLY need to change things in univstep_motion.hal, and ONLY change lines with .encoder.00.something to .encoder.03.something and .stepgen.00.something to .stepgen.03.something

While I swapped out the encoder on the X to test it, I did not use all different cabling coming in from the the encoder.
.stepgen.00.someting to .stepgen.03.something.  Do not change anything in univstep_servo.hal

Since the Gecko properly holds position, I gather that there HAS to be a bad connection somewhere between the encoder and Gecko Interface or between the GeckoDrive and Gecko Interface?
 

  Well, not has to be bad connection, but possibly a failed component on the USC board.  Or, possibly a bad solder joint on the USC.  But, I'm just guessing from a distance.
Jon
 

 

[/quote]

jmelson wrote:

3DTOPO wrote:

So I switched all occurences of .0 with .3 in univstep_motion.hal and univstep_servo.hal (and 00 with 03 along with AXIS_0 with AXIS_3) and in Axis, the X is acting just like it was.
Well, that may not be right.  You ONLY need to change things in univstep_motion.hal, and ONLY change lines with .encoder.00.something to .encoder.03.something and .stepgen.00.something to .stepgen.03.something

While I swapped out the encoder on the X to test it, I did not use all different cabling coming in from the the encoder.
.stepgen.00.someting to .stepgen.03.something.  Do not change anything in univstep_servo.hal

Since the Gecko properly holds position, I gather that there HAS to be a bad connection somewhere between the encoder and Gecko Interface or between the GeckoDrive and Gecko Interface?
 

  Well, not has to be bad connection, but possibly a failed component on the USC board.  Or, possibly a bad solder joint on the USC.  But, I'm just guessing from a distance.
Jon