abeard

Thanks - we were using the default AbortTa and AbortTs. Shoring these up seems to have fixed the issue. Thank you.

Hi, We are experiencing Fatal Following Errors on single motor motion program aborts. We use a 32kHz external time base while the motion program is running. We then periodically issue aborts to prematurely terminate the motion program. In a separate PLC, we monitor the coordinate system and if the motion program is done we subsequently reset the time base to the local crystal. I suspect that some misunderstood interaction between the PLC resetting the time base and the controlled stop abort is what is triggering the fatal following error. I’ve tried monitoring desVelZero in the PLC to wait until the motor is (mostly) stopped before resetting the time base, but this did not seem to help the problem. Any advice here would be very much appreciated. Thank You. ~Andy

For what it's worth the description in the PPMAC Software Reference Manual worked for me. I didn't try the technique described in the User Manual as the Software Reference Manual technique made the most sense ostensibly.

Note these two techniques differ in phase offset by 180 degrees in the commutation cycle.

Hello, We are using hall-effect sensors for power-on phase referencing of a BDCM. When 'manually' determining the value of AbsPhasePosOffset using hall-sensors, the Power PMAC User Manual states: However, the PPMAC Software Reference Manual documentation for AbsPhasePosOffset states: In the reverse direction sense - these do not result in the same phase offset value and it is difficult to know which is correct without knowing the exact calculation done by the Power PMAC under the hood. Any clarification would be appreciated. Thank you, ~Andy

We understand this and this came up as part of my work to switch to an absolute reference based search (which is working fine). At this point I'm just curious why our stepper based search was consistently converging on 350 commutation units. For what it's worth, the absolute phasing method is working well. We're using the same value for AbsPhasePosSF and PhasePosSF which is 7 * 2048 / 2^18 which can also be written as 7 / 2^7. Our encoder has 18 bits of resolution per revolution. Our PhaseFindingDAC was ~3000 with a very large PhaseFindingTime of 12000 in order to 'lock' in to the phase positions. The motor being used is an Aerotech S-76-149.

Hi, We're using the 'Stepper Method' for finding phase on a Power PMAC with an ACC84E talking to an absolute serial encoder. The phasing has not been very reliable, failing to find phase maybe 1-5% of the time. When it is found, things behave as expected with no discrepancies. When we execute phasing using this method, I'm finding that the position returned in Motor[1].New[0].Pos is consistently around 350 commutation units (rather than the 512 'ideal' or even > 400 recommended). I've increased the PhaseFindingTime to a large number in order to make sure that the motor is 'locked on' to the 0 and 90 degree commutation positions when energized - it is. It appears that the found phase is actually 2/3 of what it should be for our 3-phase, 14 pole motor. I've sanity checked the basics; the position in Acc84E[1].Chan[0].SerialEncDataA is correct (full rotations cycle back to the same value as expected), likewise the motor position is correct (full rotations cycle back to the correct value modulo # of motor units), and it works well if it phases. Regardless, I've been unable to find the source of this discrepancy - the only think I can think of at this point is that the 'Stepper Method' in our case doesn't use 0 and 90 degree positions but rather 0 and 60 degree positions (and probably because of some erroneous configuration on my part?). So I'm at a loss to explain this and any insights here would be greatly appreciated. Thanks, ~Andy

Thanks again to both of you. One last question: we are using 3U042 and 3U081 direct PWM drive amps. Unfortunately, our 3-phase bus power is not controlled by PPMAC IO pins but rather externally via a 120v relay switch. I'm considering changing this so that we control our 3-phase bus power via PMAC/UMAC IOs so that we can enable/disable from startup PLCs directly. Thus my question is, is it possible to directly monitor the bus voltage *after* it has been disabled (on shutdown) and/or *before* it is reenabled on startup to determine if the Amp Capacitors have sufficiently discharged? According to the manual we can get this information via the Adc strobe words, but it isn't clear if it is still monitored or accurate after bus voltage has been terminated. Thanks for all your help.

Thanks!

Apologies for not being more concise. We have a Power PMAC in a UMAC chassis with 2 Axis interface boards and 4 amplifiers. I'd like the sequence for power on/off of the whole enchilada.

The Power Brick AC includes an 'Advised Power On/Off Sequence' in the Power Brick AC User Manual. I've been unable to locate a similar sequence for the Power PMAC. Does one exist and if so where? If not, would someone mind posting it here for future reference. Thank you.

An additional question is what is the best way to verify that this is working properly. Would polling the value of ServoCapt be sufficient or should we verify functionality by viewing the output of a virtual motor tied to the encoder so we can view the encoder table processed value?

We've recently started using Power Brick ACs as a replacement for our Power PMAC chassis. One feature we rely upon is the ability to configure an encoder input in 'pulse and direction' mode. We use this to feed a 32kHz pulse train from a timing card for use as an external time base. We're having difficulty getting this feature working on our Power Brick. Questions: a) Is pulse-and-direction CHA *input* supported on the Power Brick AC? b) Does the setup differ from the Power PMAC and if so how? Thanks, ~Andy

We use an external timing board (Spectracom Tsync) to trigger the DeltaTau via the time-base trigger mechanism. We then use the same card to generate a pulse stream synchronized to absolute time as described above via the external time-base mechanism. This allows us to both trigger at a matched absolute time and remain synchronized to it. We've also tried to synchronize our DT to an EL6688 via ethercat but were not able to get things going. I think it's possible and we were working with Henry and Atul at Delta Tau to this end. I ran out of time on the project though and haven't been able to return to it - perhaps things are further along now.

We've noticed some alarming behavior when issuing the dkill command in firmware version 2.0.0.1. When issued while BrakeOnDelay is set to 0, the command does not consistently turn brakes on or off nor always open the servo loop. This results in I2T faults immediately upon issue of a dkill in the case where the loop remains closed as the brakes fight the servo loop. At other times the brakes are left on when re-closing the servo loop resulting in the same I2T fault. I've not been able to reproduce this when BrakeOnDelay or BrakeOffDelay is set to *any* value, including non-realistic small numbers such as 1 ms.