Trouble Shooting Universal Stepper Controller with Gecko Interface

Thanks!

For stepgen, there are lines for 'velocity' and 'enable' and for encoder there are lines for 'position' and 'scale'.

Do I swap all of those, or some of them?

So swapping stepgen velocity and enable, and encoder position and scale, the encoder is coming up on the 4th axis.

It is not correctly working either; it behaves just like the X axis. It seems more likely that the USC and Gecko Interface is working than two channels X and W both failing in the same way while YZ work.

Below is my univstep_motion.hal:

# HAL config file for Pico Systems USC board

# set sane pulse timing - these are basically Gecko numbers
# both pulse width and space are set to 3.5 uS, to prevent
# problems if the outputs are inverted externally
setp ppmc.0.stepgen.00-03.pulse-width-ns 3500
setp ppmc.0.stepgen.00-03.pulse-space-min-ns 3500
# setup time is set to 1 uS
setp ppmc.0.stepgen.00-03.setup-time-ns 1000

# connect position feedback signals to encoders
linksp Xpos-fb <= ppmc.0.encoder.03.position
linksp Ypos-fb <= ppmc.0.encoder.01.position
linksp Zpos-fb <= ppmc.0.encoder.02.position
linksp Wpos-fb <= ppmc.0.encoder.00.position

# get feedback scaling from ini file
setp ppmc.0.encoder.00.scale [AXIS_3]INPUT_SCALE
setp ppmc.0.encoder.01.scale [AXIS_1]INPUT_SCALE
setp ppmc.0.encoder.02.scale [AXIS_2]INPUT_SCALE
setp ppmc.0.encoder.03.scale [AXIS_0]INPUT_SCALE

# connect PID output signals to step generators
linksp Xoutput => ppmc.0.stepgen.03.velocity
linksp Youtput => ppmc.0.stepgen.01.velocity
linksp Zoutput => ppmc.0.stepgen.02.velocity
linksp Woutput => ppmc.0.stepgen.00.velocity

# connect axis enables to step generators
linksp Xenable => ppmc.0.stepgen.03.enable
linksp Yenable => ppmc.0.stepgen.01.enable
linksp Zenable => ppmc.0.stepgen.02.enable
linksp Wenable => ppmc.0.stepgen.00.enable

# set output scaling from ini file
# input and output scales should (normally) be the same for a USC
setp ppmc.0.stepgen.00.scale [AXIS_3]OUTPUT_SCALE
setp ppmc.0.stepgen.01.scale [AXIS_1]OUTPUT_SCALE
setp ppmc.0.stepgen.02.scale [AXIS_2]OUTPUT_SCALE
setp ppmc.0.stepgen.03.scale [AXIS_0]OUTPUT_SCALE

# add a couple of tuning test links
# if these are useful will want to add them to the other axes as well
# or make these setup with the tuning script
#linkps ddt.0.in Xoutput
#linkps ddt.1.in Xpos-fb

Doh I think I see why! I didn't move the encoder signals from A0 and B0 to A3 and B3.

Doing that now!

The best I can tell, I am now using what was the X gecko drive and encoder as a new W drive.

The step/dir signals are going through A3 and B3. Not using an index so Z3 is jumped to A3.

The GeckoDrive is connected to J4.

I copied the PID/scale/velocity etc configuration from the X definition to Z on univstep.ini. I didn’t make any other config changes.

But the W is behaving exactly like the X drive was. Despite using a completely different pathway. I’ve also done pretty extensive tracing today, and everything checks out.

It almost feels like it’s a configuration error. I tired positive and negative values for INPUT_SCALE and OUTPUT_SCALE. Should I test with one positive and one negative?

I just noticed something though - manually moving (no power on) the now W (was X) causes the fault light to flash on the Geckos. Quickly moving the other axes does not cause the behavior and positions are updated as expected.

Is that a big hint?

3DTOPO wrote:

The best I can tell, I am now using what was the X gecko drive and encoder as a new W drive.

The step/dir signals are going through A3 and B3. Not using an index so Z3 is jumped to A3.

The GeckoDrive is connected to J4.

I copied the PID/scale/velocity etc configuration from the X definition to Z on univstep.ini. I didn’t make any other config changes.

But the W is behaving exactly like the X drive was. Despite using a completely different pathway. I’ve also done pretty extensive tracing today, and everything checks out.

It almost feels like it’s a configuration error. I tired positive and negative values for INPUT_SCALE and OUTPUT_SCALE. Should I test with one positive and one negative?

I just noticed something though - manually moving (no power on) the now W (was X) causes the fault light to flash on the Geckos. Quickly moving the other axes does not cause the behavior and positions are updated as expected.

Is that a big hint?
 

Well, it sounds like you are doing the right things.  I looked at your univstep_motion file, and it looks OK.
It can be normal for INPUT_SCALE and OUTPUT_SCALE to have opposite polarity.  It depends on how the A and B of the encoider and the motor wires are connected.  Why did you change the .ini file?  There should have been no need to touch that.  And the Z axis is axis #2, not the one you are using for the replaced X axis.
As for the fault light, when the motor is moved, it generates a voltage that is sent back to the DC power supply.  That partially powers up the Gecko drive.  Since all drives are presumably connected to the same power supply, it should cause ALL of the drives to light up, at least a little.  Maybe that is a clue that there is something wrong with that Gecko drive, or the power wiring to it.
Jon
 

You beat me too it! I was going to write that the fault lights only come on when I move it fast enough, and I got another axis to do the same. If it has enough potential all 3 fault lights come on.

Any thought about it behaving as it did after using different pathways?

I was thinking I should try to just run the GeckoDrive direct. Is there anything I need to do configuration wise or wiring wise than just move the step/dir wires from the USC to the GeckoDrive?

Neglected to answer why I changed the ini file.

I've tried several different things. The most recent attempt, I just set W up like a new drive. Since W is connected to what was the X servo, I copied the X settings since they match the motor.

3DTOPO wrote:

It almost feels like it’s a configuration error. I tired positive and negative values for INPUT_SCALE and OUTPUT_SCALE. Should I test with one positive and one negative?

 jmelson post=240533 userid=508
It can be normal for INPUT_SCALE and OUTPUT_SCALE to have opposite polarity.  It depends on how the A and B of the encoider and the motor wires are connected.  
 

I guess I was wondering if those are not configured with the correct polarity for the signal it is receiving, might it behave the way it is? That is, the reported position only incrementing in one direction?

The machine has been using negative values for both, but I've swapped A/B a number of times so it may no longer be what it used to.

Does (plus) INPUT_SCALE and (minus) OUTPUT_SCALE have the same effect as (minus) INPUT_SCALE and (plus) OUTPUT_SCALE?

Today I checked that the wire in the terminals in fact connects to the actual board on the encoder connection since the plug was one thing that all the tests have in common. I also wired a new servo encoder using a new wire. My normal setup uses a differential encoder/decoder, but the new wire/servo encoder was wired direct; it did not use the differential encoder/decoder. But made no difference in how it works going through X or W.

Both of those operations eliminate the last things that I hadn't tested that I can think of.

All of these dip switches are currently set to the ON position.
pico-systems.com/osc2.5/catalog/links/univstep_switch.html

Should I try them in any other configuration?

I just tried changing the Switch 2 (which is a working drive) to Off and I noticed the position doesn't update in Axis when set to off.

Makes me wonder if the switch is working as expected for X and W. Guess I should try a physical jumper?

3DTOPO wrote:

All of these dip switches are currently set to the ON position.
pico-systems.com/osc2.5/catalog/links/univstep_switch.html

Should I try them in any other configuration?

I just tried changing the Switch 2 (which is a working drive) to Off and I noticed the position doesn't update in Axis when set to off.

Yes, of course. that causes the USC to ignore signals coming in on P2, and only count steps sent out.

Makes me wonder if the switch is working as expected for X and W. Guess I should try a physical jumper?
 

No, I suspect the switch is NOT the issue.   I am now convinced you have either a bad encoder or bad wiring from the encoder.  The fact that two USC channels see the same issue, and ESPECIALLY that the USC counted movement in the opposire direction when A and B were swapped tells me that the encoder signals as received by the USC are not right.
The USC has different logic levels than the Gecko interface where it converts the levels for the Gecko drives.
The USC requires logic low to be below 1 V and logic high to be above 3,5V.  Can yoi check the levels provided by the X encoder?  If you move the motor shaft slightly, you should be able to see both logic states.
Also, check that A and B can be at diffrent logic levels.  There might be a weak short between A and B.  With the system totally powered off, take an Ohms measurement between A and B.  These should be a high resistance.  Compare good to the bad axis.
The way quadrature works is that there is a sequence of A B; A B-; A- B-; A- B that repeats.  The sequence is reversed for opposite direction.  If A and B are shorted together, there will be no way to determine direction of movement, but there would likely be puses that the USC and/or Gecko drive might count.
So, I would look closely at the encoder signals with at least a DVM.  If you have a scope, MUCH better to see what is going wrong.
Jon
 [/quote]