Eric Hotchkiss

What do you mean? Does "ecat slaves" not get a response unless you are going through a switch? If it is something else, what is the symptom you see? Sometimes the PMAC needs to be booted after the slave is power on and connected by ethernet cable to the master already. That is only when the phy chips don't get along. It's possible that PMAC can communicate with the hardware on the switch without a reboot. Does the drive show an error? Drives will refuse to go into OP if something is wrong. Also, try to "upload logs" like in the attachment and see if the error or error history logs mention anything.

Sang Joon, Did the PMAC actually reboot and come back online? Or did it crash and stay dead? I don't know of anything that should cause it to reboot outside of losing power and then getting it back.

George, Are you encrypting your project? What IDE and firmware version are you using? Can you paste in an example line that causes a segmentation fault even when commented?

I believe Tony is talking about the shift time setting circled in my attachment. It is typically set to half of the cycle time to ensure the master is done writing new values before the slave tries to use them and vice versa.

Can you try changing the order of the devices (by moving cables) so the ECC-203 is no longer first? Are you sure you downloaded the mapping to Power PMAC after making all changes? Does ECAT[0].DCClockDiff change in value when you try to enable? (Add it to the watch window)

Sang Joon Lee, What are you trying to do with the P100 line? A variable by itself doesn't really mean anything in PMAC script.

The feedforward servo gains on the follower motor can end up trying to predict the future behavior of the master encoder, leading to noise. You might try these settings for the follower motor: Motor[x].Servo.Kaff=0 Motor[x].Servo.Kvff=Motor[x].Servo.Kvfb Motor[x].Servo.Kviff=Motor[x].Servo.Kvifb

Pos/ActPos contain the current motor position relative to power on. In homing PMAC moves HomeOffset motor units from the trigger and sets HomePos=ActPos at this position. (Your displayed position is ActPos-HomePos.) If you change HomeOffset between homing moves you will have to do slightly more than subtract HomePos values to find the distance.

Jeff, to look up Ixx24 use the Turbo PMAC Software Reference Manual Available here. http://www.deltatau.com/manuals/pdfs/TURBO%20SRM.pdf?id=635787783266757322 It looks like setting bit 22=1 and bit21=0 means kill only this motor on Amp Fault. The differing behavior could be due to how often the PLC runs to check the input and how far the killed motor drifts in that time. I would definitely suggest using hard stop homing as Dave suggests. In theory it's pretty simple to set up. Once Motor[4].CaptureMode = 2, the #4home command will cause PMAC to move at Motor[x].HomeVel (signed) until following error is above Motor[x].WarnFeLimit, where it will move by Motor[1].HomeOffset, then stop and set position to zero, maintaining closed loop the whole time. Complications arise from how easy it can be to trip a fatal following error. It might require a gentle touch. Suggestions include setting Motor[1].Servo.SwZvInt = 1 (to stop the integrator from building while the motor rams the hardstop), a low home velocity, carefully looking at Motor[4].JogTa/JogTs and Setting Motor[1].HomeOffset to the opposite sign of HomeVel to move away from the hard stop at the end.

Did you add the ESI files for your ecat modules to the IDE? If you go to the "EtherCAT" menu, you will find the "ESI Manager" where you should be able to browse to a file location. What did you do before the error occurred? It would be much easier to diagnose if I knew when it happened. Was this after scanning the network?

That sounds like a problem. The EtherCAT standard has AmpFaultBit as bit 3, which the firmware should automatically use when an EtherCAT address is chosen for Motor[x].pAmpFault. This most likely means your ECAT device still needs to be set up as a drive. Is your AmpEnable PDO only a single bit?

These were 0 when you posted settings. Has changing them improved the drive's behavior. I was referring to the other thread. I'm not familiar with switching the EL7031 between appearing as IO and drive, so I was letting Alex handle it. http://forums.deltatau.com/showthread.php?tid=3073

Manual setup of Acontis EtherCAT motors may be a bit complicated simply because it is unfamiliar. If you want to go down this route, I would suggest setting up another EtherCAT motor and taking a full configuration to compare the motor parts against. If you don't have another ecat drive I can do this with a 1S and email the results. You might try setting these bit numbers. I believe they are both ignored once PMAC sees the address is in an ethercat range, but the IDE does set them. I believe there may be something else you can do to the drive to get it to show up as a servo drive.

I realized my post might be confusing so I attached a screenshot. Is the Amp Fault Input set to the status word for the correct drive like in the picture?

This typically indicates that there is a fault on the drive side. I would at least check the device for errors. And this makes it hard to view the issue as only a drive problem. It sounds like the process where the drive tells PMAC it has enabled and cleared faults isn't happening before the timeout. Does it look like Motor[8].pAmpFault is set to the status word?

I don't think that will work as you are expecting. One Gate3 will always generate clocks for the CPU and for other Gate3s in the system. Phase/Servo software tasks run on the CPU in synchronization with all of the hardware. There would not be a second Servo software task to run on the second clock signal. Depending on whether the motor requires current loop closure and commutation, you may be able to use "Servo in Phase" for the fast motor. This feature is mostly intended for galvos. Take a look at Motor[x].PhaseCtrl in the SRM for more information. Another option would be to set the phase/servo period based on the fast motor and then use Motor[x].STime to slow down the rest. This would work with any type of motor.

Can you try this command? I'd like to try something a bit more universal to ensure SDOs really are all failing. l0=ecattypedsdo(0,0,1,$6060,0,0,1) l0

What firmware and IDE version are you using? I might need that info to find answers about how SDO commands can fail.

I can't think of anything you could be doing wrong. Are you able to read any SDO values?

Nothing comes to mind, but are you calling the subprogram from a PLC or Motion Program? Are you sure it ran? Maybe have it increment a variable on the next line.

The values of PhaseFindingDac and PhaseFindingTime are quite low and likely will not lead to reliable phasing. This process has to have the motor and if enough time and current are not provided it can give random results. Motor[x].AbsPhasePosOffset=1877 could be a check that the motor has moved far enough, but that value might not be set up correctly. It also sounds like you want to be doing halls phasing. I would suggest taking a look at the Brushless Motor Phasing section starting on page 134 of the PowerBrick LV manual available here. http://forums.deltatau.com/filedepot/download.php?f=Power%20PMAC/Manuals/Hardware%20Reference%20Manual/Power%20Brick%20LV%20User%20Manual.pdf [FILE REMOVED] This manual is not exactly the same as your hardware, you will need to change PowerBrick to Gate3. It is just a useful manual to go through the whole setup process because it is a manual for an all in one form factor. It will show you how to either set up Halls Phasing with correction or an automatic method that moves the motor depending on what you prefer. I think you mean Gate3.Chan[j].CountError, but set it equal to 0 in a startup PLC. For these types of questions you should really reach out to your local support channel. If that doesn't work I'm happy to help, I don't want to leave anyone with a PMAC stranded, but please start with them.

I don't think that was necessary. The RMA wasn't either. To get a firmware update, you should email your local support channel, possibly your distributor or OEZ. That being said, your firmware is pretty up to date, I don't think firmware version is the problem. I think you just need a little help setting up your phasing. I will try to address this in the other thread.

ARM LS1021a would be the CPU type not the firmware version. To see your firmware version enter "vers" into the terminal. It should be 4 numbers like 2.5.2.0. This is also visible near the top of the screen on new enough IDE versions. Each firmware version is compiled for each CPU type (ex Dual Core ARM, PowerPC 460, PowerPC 465). Whether the CPU has EtherCAT or not is irrelevant to what firmware version is installed.

Sorry I was mistakenly thinking we were talking about the environmental temperature like Alex. If a component on the 24E3 itself is 70 C I would not be worried. This is likely unpredictable phasing. What are the values of the following variables? Motor[x].I2tSet Motor[x].PhaseFindingDac Motor[x].PhaseFindingTime Motor[x].AbsPhasePosOffset

No, this is not normal. The 24E3 should come with a fan meant to be placed just underneath. Is it installed? Is the 24E3 in a cabinet? Does the cabinet have a fan?