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.

Cool. This is a small data point, but I've ran all day off your recommended plc with no failures.

Great! I'm glad to hear you can reproduce this. Yes this is possible, sounds reasonable and will be easy to implement. My only question is whether or not I need to worry about the plc sporadically dying for the same reason? Thanks for the code samples too.

It's pretty simple, basically just an infinite loop with a move, delay, send and sendall. The same code runs in four different coordinate systems with a single motor each. All coordinate systems are synchronized with a single time-base trigger and remain synchronized via an external time-base such that all four motors move at exactly the same time (down to the same servo period AFAICT). // ... Setup time-base trigger & arming... while ( done != 1 ) { // ... calculate move pos... x(movePos) ta(moveTime/2) td(moveTime/2) ts(0) tm(moveTime) delay(delayTime) send 0 "This is a status update" sendall } This will run for random amounts of time before triggering the runtime-error (I've seen anywhere from 5 to 45 minutes). getsends is always running, etc...[/code]

Thanks for the recommendations Charles. I went ahead and tried your first suggestion but to no avail. Oddly, all 4 coordinate systems stopped at the same time with "CoordExecStatus[n] - Stopped at breakpoint...", this is despite having no breakpoints defined. I have verified that the sendall is the culprit - removing it removes the symptoms at least. If I get a chance, I'll try the timer suggestion as well. Thanks.

I'm receiving coordinate system runtime errors (Coord[n].RuntimeError) sporadically after many minutes to hours of running. We're running four motors in four separate coordinate systems. The four coordinate systems run an identical program which simultaneously moves the motors at the same time using external time base. 'list apc' is showing that the program counter was pointing at 'sendall' immediately following a 'send' command at the time of the abort in all four coordinate systems. I've tried increasing Sys.PreCalc as recommended by other threads here to no avail. I also wrote a plc to monitor the high water mark of the Coord[n].BufferWarn variable - this never exceeded 0. There are also no additional errors such as FeLimit. 'getsends' is running on all communications ports being used. I'm at a loss to explain the RuntimeError and am thinking now that perhaps this is due to a race amongst the four simultaneous calls to 'sendall'. Any help or insight would be greatly appreciated.

I was able to clear the PDO entries using: root@192.168.0.200:/opt/ppmac# ethercat -m0 download -p0 -t uint8 0x1600 0 0 and root@192.168.0.200:/opt/ppmac# ethercat -m0 download -p0 -t uint8 0x1a00 0 0 After which 'Add From Dictionary Objects' became available for use again.

I'm configuring PDO mappings for a Copley Xenus Plus EtherCAT drive. When initially configuring the drive, I was able to add new dictionary objects via the 'Add From Dictionary Objects'. This worked well and I was able to read and write these objects from my motion programs. Now however I'd like to add additional objects to these mappings. Unfortunately, no matter what I do the 'Add From Dictionary Objects' button is greyed out (see attached PNG). I've tried everything including resetting to factory defaults but have been unable to map new elements. Any advice appreciated.

I'm sorry, I should qualify this: the design assumes that the phase interrupt position capture values (e.g. Chan[N].PhaseCapt) is latched at the same time for distinct channels, not the position capture feature (which is channel specific).

Hi, We're currently considering a design which relies on latching two motor positions at the exact same time via two channels on an acc24e3. Does the PPMAC position capture feature indeed latch distinct encoder channel positions at the same time? I'm assuming they are both latched in hardware in response to the *same* interrupt. We would eventually like to extend the technique to latch positions on one DeltaTau Acc24E3 and another Copley Ethercat drive. Neglecting the ethercat process data latency, would the same technique be feasible? Thanks! ~Andy