Richard Naddaf

"Kindly let me know any chances of getting them sooner." I would contact the local sales channel for order status. The ACC-51E does NOT use Gate3, it is Gate1.But technically, yes, you can use it for sine/cosine analog encoder input. It's interpolation is x4095 as opposed to the standard x16384 with ACC-24E3 or x65536 with ACC-24E3 ACI option. This should be taken into consideration configuring the encoder/motor.

@Warren Was this was caused by HMI sending "&1ABORT&1BEGIN&1START" without proper logic or delays?

Power UMAC should be around through ~2030. This is the intention but subject to change of course. All depends on supply chain and component availability. Geo Direct PWM phasing out. Introducing updated PWM models next year. Also, potentially EtherCAT version year after. Turbo UMAC is almost phased out, not recommended for new applications. NC with any of the Power PMAC platforms is available, including UMAC, Brick, Ck3E, and CK3M.

Elem_X needs to be defined on the master side. The Master cannot know the name of a variable defined on the Slave.

Macro auxiliary read and write commands are intended to be used from the "master" only. I do not understand your issue otherwise. Are you saying that if you use P-variable, you get an error? Out of range usually indicates that the variable number is greater than 8191 which is the limit for use with MX commands.

Try this: EncTable[1].type = 1 EncTable[1].pEnc = Gate3[0].MacroInA[0][0].a EncTable[1].pEnc1 = Sys.Pushm EncTable[1].index1 = 13 EncTable[1].index2 = 13 EncTable[1].index3 = 0 EncTable[1].index4 = 0 EncTable[1].index5 = 0 EncTable[1].index6 = 0 EncTable[1].ScaleFactor = 1 / EXP2(13)

Kinematics in either CfromScript or regular script have nothing to do with the scanning frequency. They are called when trajectory calculation is needed. You can use user servo or RtiCplc to execute general purpose calculation at servo or RTI frequencies respectively. Why do you need to execute Kinematics that fast? how does this affect the mechanics of your system?

I doubt that the automatic system setup will be able to configure this for you. Essentially, this is a dual feedback stage. Halls are used for commutation, and velocity loop. Linear encoder used for position loop. This can be set up manually following procedures described in the Power Brick LV (ARM or prior) manual. First, you want to set it up for commutation and velocity using the halls as if they were a quadrature encoder that yields 12 counts per revolution (because of x4). In this step, you would verify current loop, phasing, and open loop functionality. Next, you would point Motor[x].pEnc to the linear encoder conversion table entry, perform an open loop test to make sure the motor moves in the correct direction of the encoder counting. If not, switch EncCtrl from 7 to 3 or vice versa and try again. Lastly, try to tune the position loop.

Setting Sys.PreCalc = 0 is strongly discouraged. As you have seen, it does result in runtime errors. For calculation intensive applications (possibly like yours), users have had to increase it from the default of 1 to ~5-10 to alleviate runtime errors. Generally, this has minimal to no affect to the cycle time or positioning speed. I am not sure why are you interested in setting it to 0. Motor[x].InPos bit going in and out does not cause or accumulate errors.

I doubt that this is a CPU loading issue. So, I would not mess with Sys.MotorsPerRtInt. Be aware that changing this element requires numerous changes to other elements, including I2T settings. One factor to keep in mind is the delays between jog moves and status bit checking. Can you share your timing scheme? Issuing a JOG command to a motor in the middle of another moves' acceleration or deceleration is BAD. This could accumulate following error. Otherwise, you probably want to make sure that you are not sending redundant JOG command(s) repeatedly. I would verify the consistency of the cycle and motor jogging outside of the application. The best way is to do it from a background PLC. Assuming all 5 motors are in coordinate system 1, below is an example. You can increase the CycleCtr value to loop more than once. If this PLC works then the issue is in the the application timing. OPEN PLC CycleTestPLC LOCAL CycleCtr CycleCtr = 0 WHILE(CycleCtr < 1) { JOG 1..5:10 CALL DelayTimer.msec(50) WHILE(Coord[1].InPos == 0){} START 1:1 CALL DelayTimer.msec(50) WHILE(Coord[1].ProgActive == 1){} WHILE(Coord[1].InPos == 0){} CycleCtr++ } DISABLE PLC CycleTestPLC CLOSE

You could point "open" motors to the entries and subtract their corresponding Motor[x].DesPos in a user servo.

$0FBFFF00 is correct. $0BFxxxxx was a typo. We have seen this issue with the UMAC counterpart accessory (ACC-5E3). It turned out to be a hardware ECO. We had not seen it with the Brick series, but it may be susceptible to environment and installation conditions. I have already asked the design team to look into it.

One workaround is to issue MacroControllerInit from a PLC until the ring is active. Something like: GLOBAL MacroInitCtr OPEN PLC MacroInitPLC MacroInitCtr = 0 WHILE(Macro.Status[0].Active == 0 && MacroInitCtr < 10) { CMD"MacroControllerInit" CALL DelayTimer.msec(1000) IF(Macro.Status[0].Active == 1){DISABLE PLC MacroInitPLC} MacroInitCtr++ } DISABLE PLC MacroInitPLC CLOSE Also, note that: - It is recommended to only enable used nodes - Node 14 on the slave should be left off, PowerBrick[0].MacroEnableA =$0BFFFF00

What PMAC product (amplifier) are you using? Also what does your motor mechanics looks like? It sounds like you have mechanical resonances more than anything else. Do the oscillations continue after you come to a stop? For a move and settle type of oscillations, I would recommend using the trajectory pre-filter notch and not the servo loop one. I noticed that IpfGain = 2. I typically recommend it to be equal to 1. I do not know if this is part of the cause, I doubt it. The IpfGain is simply a multiplier of the servo effort in voltage mode. It is proportional to the servo gains. Also MaxDac should not exceed 28000.

I have seen systems using 1 readhead instead of 2. This allows continuous counting without any special setting using a single encoder conversion table. But in your case, there are two read-heads which requires two encoder conversion tables. One idea is to add these in the encoder conversion table and use the result for both phase commutation and servo position.