Jump to content
OMRON Forums

DAC Glitch on Acc24E3


JeffLowe

Recommended Posts

Acc24E3 with 18 bit DACs. Non-commutated torque mode motor, Phase =16, servo =8 KHz.

We are experiencing a 2.5 Volt, 62.5 usec wide glitch. This can be captured with an oscilloscope, but Gather of Gate3[0].Chan[3].Dac[0] does not show the glitch, only the aftermath (Ringing in following error and the proper servo response to it). Can this be the result of clock settings, and If so, what are the recommendations?

Link to comment
Share on other sites

  • Replies 6
  • Created
  • Last Reply

Top Posters In This Topic

  • 6 months later...

I wouldn't expect Phase/Servo clocks to be an issue. See if reducing Gate3.DacClockDiv by one tick helps. If you continue to have this issue contact support@deltatau.com with the oscilloscope plots.

 

This has been identified as a design flaw within the Gate3 chip. An uncommutated analog motor operating around zero will occasionally fiip sign/magnitude, that is a small negative number may be clocked out as a large positive number, and converse.

There are workarounds.

Link to comment
Share on other sites

This has been identified as a design flaw within the Gate3 chip. An uncommutated analog motor operating around zero will occasionally fiip sign/magnitude, that is a small negative number may be clocked out as a large positive number, and converse.

There are workarounds.

 

Is there any documentation or comments on what the workaround might be?

Link to comment
Share on other sites

This has been identified as a design flaw within the Gate3 chip. An uncommutated analog motor operating around zero will occasionally fiip sign/magnitude, that is a small negative number may be clocked out as a large positive number, and converse.

There are workarounds.

 

Is there any documentation or comments on what the workaround might be?

 

1) address servo dac to an unused memory location and write a user written phase routine to copy memory to DAC.

2) Set the motor up as a commutated axis and set the Phase encoder to an unused memory location preset to 0.

 

Note we only discovered this with an air bearing spindle operating at low to moderate speed, ie, no friction operating around 0 +/- 50 counts.

Link to comment
Share on other sites

The issue appears only when the combination of two events occurs.

 

First, the write operation from the processor to the memory-mapped DAC register is coincident with the transfer of the contents of the memory-mapped register to the active shift register (which occurs on the rising edge of phase clock.

 

Second, a large number of adjacent bits change from 0 to 1, or 1 to 0, from the previous command value. This typically would only happen when changing between a very small negative value and a very small positive value. Not all of the bits can "flip" in time, and an erroneous value is shifted out to the DAC for a single phase cycle. It appears there is not enough (extremely) local capacitance to move that much charge that quickly.

 

In the large majority of applications, the write operation is never close to the rising edge of the phase clock, so the first condition is very seldom met.

 

Even when the issue does occur, the resulting physical perturbation is so small and brief that it is not noticeable in most applications, being smaller than typical mechanical and electrical disturbances, particularly the stick-slip friction phenomenon, or gearing lost motion, that occur in most applications on such a command sign change.

 

This is why the problem has just been noticed recently after 10 years of use of the ASIC.

 

If it does occur and is a problem in a particular application, it is simple to alter the timing of the processor write relative. If the write occurs as a phase-interrupt task, it basically cannot be coincident with the transfer, because the tasks start reliably on the falling edge of the phase clock and finish far before the rising edge.

 

So even if PMAC is not doing the actual phase commutation for the motor, it is easy to set up the phase routine to be a pass-thru for the servo command (virtually the same as for direct PWM control of DC brush motors, freezing the commutation angle at zero) to eliminate the possibility of a glitch.

Link to comment
Share on other sites

The issue appears only when the combination of two events occurs.

 

First, the write operation from the processor to the memory-mapped DAC register is coincident with the transfer of the contents of the memory-mapped register to the active shift register (which occurs on the rising edge of phase clock.

 

Second, a large number of adjacent bits change from 0 to 1, or 1 to 0, from the previous command value. This typically would only happen when changing between a very small negative value and a very small positive value. Not all of the bits can "flip" in time, and an erroneous value is shifted out to the DAC for a single phase cycle. It appears there is not enough (extremely) local capacitance to move that much charge that quickly.

 

In the large majority of applications, the write operation is never close to the rising edge of the phase clock, so the first condition is very seldom met.

 

Even when the issue does occur, the resulting physical perturbation is so small and brief that it is not noticeable in most applications, being smaller than typical mechanical and electrical disturbances, particularly the stick-slip friction phenomenon, or gearing lost motion, that occur in most applications on such a command sign change.

 

This is why the problem has just been noticed recently after 10 years of use of the ASIC.

 

If it does occur and is a problem in a particular application, it is simple to alter the timing of the processor write relative. If the write occurs as a phase-interrupt task, it basically cannot be coincident with the transfer, because the tasks start reliably on the falling edge of the phase clock and finish far before the rising edge.

 

So even if PMAC is not doing the actual phase commutation for the motor, it is easy to set up the phase routine to be a pass-thru for the servo command (virtually the same as for direct PWM control of DC brush motors, freezing the commutation angle at zero) to eliminate the possibility of a glitch.

As Curt noted, this is an extreme edge case, specific to air bearing systems. We only stumbled into this when we started doing an exacting balancing of our amplifier input. This balancing was a necessity as the ACC-24E3 Amplifier Enable relay starts to fail in an on state after a couple years and our spindles were running away.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...