[Fatal Following Errors on Motion Program Abort]

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

[Fatal Following Errors on Motion Program Abort]

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

[AbsPhasePosOffset Documentation Inconsistency]

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.

[AbsPhasePosOffset Documentation Inconsistency]

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

[AbsPhasePosOffset Documentation Inconsistency]

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:

 

Note the value of PhasePos when this transition occurs. If the direction sense of the Halls matches that of the commutation cycle, assign this value to Motor[x].AbsPhasePosOffset. If the direction senses do not match, assign the negative of this value plus or minus 1024 (1/2-cycle) to Motor[x].AbsPhasePosOffset.

 

However, the PPMAC Software Reference Manual documentation for AbsPhasePosOffset states:

 

If the direction senses of the sensor and the commutation cycle match (so Motor[x].AbsPhasePosOffset is positive), put this value in Motor[x].AbsPhasePosOffset. If the direction senses do not match (so Motor[x].AbsPhasePosOffset is negative), put the opposite of this value in Motor[x].AbsPhasePosOffset.

 

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

['Stepper Method' Phasing w/ Absolute Serial Encoder]

When you have an absolute encoder, the only purpose for the stepper-motor phasing search is to establish the difference between the sensor zero position and the commutation cycle zero position. This difference is put in Motor[x].AbsPhasePosOffset, and then in subsequent startups... -- no need for a search.

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.

 

I did just confirm on my test system that the two steps are 90 degrees apart, not 60. I got about 500 commutation units between steps each time I tried this search.

 

You claim a motor with 7 commutation cycles per revolution. How many encoder LSBs do you have per revolution and what are your settings for AbsPhasePosSf and PhasePosSf?

 

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.

['Stepper Method' Phasing w/ Absolute Serial Encoder]

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

[Power PMAC Advised Power On/Off Sequence]

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.

[Power PMAC Advised Power On/Off Sequence]

Thanks!

[Power PMAC Advised Power On/Off Sequence]

When you say "Power PMAC", are you referring to a UMAC?

 

The main concern with Power On/Off is that the amplifier in the Power Brick series is never powered or used before the logic is online and that the soft start circuitry has time to complete its tasks. For just a Power PMAC CPU, this is not a concern, since there is no "amplifier/bus power".

 

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.

[Power PMAC Advised Power On/Off Sequence]

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.

[Pulse and Direction Input Power Brick AC]

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

[Pulse and Direction Input Power Brick AC]

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

[Absolute time in PPMAC]

Many of our observatory users have fed a precision pulse stream into an input on an axis card like the ACC-24E2A as a "time-base input", as you note. This technique does not change the physical time between consecutive servo clocks, but allows us to count the number of pulses between consecutive clock cycles, and make the velocity of the programmed moves proportional to the number of pulses received. This has worked very well to keep moves from drifting off over time -- but again, this is relative time.

 

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.

[Potential Bug in dkill/ddisable When BrakeOn/OffDelay is 0.]

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.

[Sendall Coordinate System Race Condition?]

I'm virtually certain the PLC will not fault out. I will let a test run all day on my box here in the office and let you know at the end of the day.

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

[Sendall Coordinate System Race Condition?]

OK, I have been playing with your code throughout the day and experienced program failures as well. My initial suggestions do not seem to help.

 

Great! I'm glad to hear you can reproduce this.

 

I think due to the nature of the send and sendall commands, it might not be a good idea to use them in a motion program directly. Instead, I propose that you set a csglobal flag in the motion program that indicates to a waiting background Script PLC to send your status updates via send and sendall. Is that a possibility for your architecture?

 

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.

[Sendall Coordinate System Race Condition?]

Could you also post a short excerpt of the kind of code that is causing you a problem? I can test it here on my system.

 

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]

[Sendall Coordinate System Race Condition?]

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.

[Sendall Coordinate System Race Condition?]

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.

[Clearing EtherCAT PDO Mappings]

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.

[Clearing EtherCAT PDO Mappings]

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.

[Position Capture on Multiple Channels and/or Ethercat]

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).

[Position Capture on Multiple Channels and/or Ethercat]

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