Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Gate3 position compare
I've been working with the Gate3 card position compare function and I have a problem where the EQU output will not change state when the motor passes the first Comp register if the motor is running in the negative going direction. The position compare output functions as expected if the motor is running in the positive going direction.

The motor is setup as internal pulse and direction (EncCtrl=8) and PFM pulse counting (TimerMode=3). I want to use this motor to actually trigger since the real motor uses a BissC encoder for feedback. I've setup the PFM motor to follow the real motor.

I've plotted both moves (please see attached images); I plotted the Gate3 timerA register, Equ, and the CompA and CompB registers. To make the graphs easy to look at I've scaled the comp registers by 0.0626 (1/16) to account for the difference in fractional count between the TimerA register and the comp registers. With this setup we should see the equ state trigger when the TimerA plot crosses the appropriate Comp (A or B) register plot.

As you can see in the attached plots, the positive going move works as expected. In the negative going direction the card misses the first Comp register, but changes state at the second comp register.

Is this something peculiar to a motor setup as internal pulse and direction, or is there something else going on?

Attached Files Image(s)

This is a known issue. It's a bug in the DSPGATE that will be fixed in the ASIC's next revision.

To compensate for it, you have to preload the rising and falling edges of the compare ahead of the motor's current position and then force the EQU's initial state before passing through the first edge.

For example, if motor 1 is at 100 cts, you could set CompA at 0 cts, CompB at -100 cts, set the initial EQU state low with Gate3[0].Chan[0].EquWrite=1 (to set the initial state low), and then start moving in the negative direction.

This contrasts the older "bracketing" method used in Turbo PMAC.
Hi Charles,

Thanks for confirming this. I'm pretty sure you guys told me this before, however I am revisiting this issue after a couple of years, and I couldn't seem to find my old posts pertaining to this topic (probably didn't look in the correct threads).

Thanks again,
Recently, I came up against this problem too, where power umac and ecc24e3 are used on an laser marking system.
That is:
1). if motor starts in between compA and compB, gate3[0].chan[0].equ toggles only when motor ran toward positive direction, not in negative.
2). if gate3[0].chan[0].equwrite=1 is set after compA/compB setting action, as is said in user manual, next auto-incrementing will be disabled. But I found only when motor current position is less than compA and compB, EQU function works well, but if motor current position is bigger than compA and compB, gate3[0].chan[0].equ won't toggle on first compare position.
3). if no gate3[0].chan[0].equwrite setting is done after compA/compB setting action, as is said in user manual, auto-incrementing will be enabled automatically. But I found if motor current position is less than compA and compB, gate3[0].chan[0].equ still toggled at the first compare event, but if motor position is bigger than them , it worked well, that is skipping first toggling action.

As Charles said above, it's a bug and "will" fixed on "next" version. So, could you please tell me from which version has this bug been fixed? Can I fix it if you send me a patch?

Forum Jump:

Users browsing this thread: 1 Guest(s)