Alex Anikstein

Ah, sorry--I forgot that Beckhoff I/O shows up as individual slaves, as opposed to just multiple modules of a single slave, and didn't recognize the coupler part number. Yes, in that case please try with just the EK1100 and the EL7211-0011. If "ecat slaves" shows the EL7211 as Slave 1 instead of Slave 0 as I suspect it will (the 0 in the far left of the response, or the "0:1" in the middle of the response string), please change the second argument of ecattypedsdo to a "1" (so, ecattypedsdo(x,1,x,x,x,x,x) instead of ecattypedsdo(x,0,x,x,x,x,x)).

The fact that it isn't showing up as a drive is most likely related to the fact that we can't properly read form the device with the ecattypedsdo command--for now, I'd say let's focus on that issue. The IDE needs to use that command to determine what slaves are present and potential drives.

Interesting. In that case, the slave that's not responding is actually the EK1100, as the ecattypedsdo command as formatted is talking to Slave 0. Can you try to re-issue the same 3 commands, but with the EL7211-0011 as the only slave device physically connected?

Sutty, Can you issue the following 3 commands exactly as-is and then post a screen shot of the terminal window/response? The first two may take a little bit to get a response (the second in particular may take a while), so I'd issue them one at a time and wait in between. This would be with EtherCAT disabled (the second command will re-initialize the ethercat stack entirely; if EtherCAT was enabled, this will disable it anyways and may fault slaves). ecat slaves ecat reset l0=ecattypedsdo(0,0,1,$1000,0,0,4) l0

In our experience, Beckhoff implements EtherCAT through two different methods--one following the DS 402 profile, and one that is more similar to I/O, following the MDP 742 profile. Based on the responses, we believe that your unit is programmed to use the MDP 742 profile, and that is causing these issues. If you contact Beckhoff, you should be able to get a file that can be written to the EEPROM of the device to reprogram it for DS 402--it may even be available from their website, but I can't see it. Once you have that, if you contact odt (dash) support (at) omron (dot) com, we can send you a document that can help you load the file onto the device.

Pretty much--I might leave the PLC active at all times and just pass a flag back and forth instead, but it's the same general idea. You could even make it more generic: GLOBAL ReadWriteSDOFlag = 0 GLOBAL EcatMasterNum = 0 GLOBAL EcatSlaveNum = 0 GLOBAL EcatReadWriteFlag = 0 GLOBAL EcatIndex = 0 GLOBAL EcatSubIndex = 0 GLOBAL EcatValue = 0 GLOBAL EcatNumBytes = 0 GLOBAL EcatResult = 0 OPEN PLC ReadWriteSDOPLC IF(ReadWriteSDOFlag == 1) { EcatResult = ecattypedsdo(EcatMasterNum,EcatSlaveNum,EcatReadWriteFlag,EcatIndex,EcatSubIndex,EcatValue,EcatNumBytes) ReadSDOFlag = 0 } CLOSE Then just have your motion program set the parameters you want to read/write, set ReadWriteSDOFlag true, and wait for it to go false and read the result from EcatResult.

Unfortunately, commands to read SDOs won't work in realtime processes, such as Motion Programs or realtime PLCs. Waiting for a response from the slave device would block execution of other realtime PLCs and/or the motion calculations. As such, whether in a motion program or a subprogram called from one, the ecattypedsdo command will not wait for a response.

It doesn't work, even with $15 as the subindex instead of 15? For some reason I spaced out entirely when I was looking into your drive and the correct subindex is absolutely 21 ($15), not 15, which does not appear to exist. Just to be sure, can you re-try these two commands and verify that they both fail? l0=ecattypedsdo(0,0,1,$8010,$15,0,4) l0 l0=ecattypedsdo(0,0,1,$8010,21,0,4) l0

If the ambient temperature for the CPU is over 70C, it must be lowered by adding more/better ventilation or cooling. The CPU is rated for an ambient temperature of 0-45C. If the motor is reversing directions, your phasing may not be strong enough. Try phasing the motor at multiple locations and verify that it succeeds at all of them. The ACC-24E3 axis card exists in both a standard (16384 counts/cycle) version and a version with an optional Autocorrecting Interpolator (ACI), which results in 65,536 counts per revolution. If you have the ACI, then yes, 65,536 is correct. Regardless of which version you have, your UMAC Rack needs a lower ambient temperature.

It does look like that subindex is 4 bytes. Still try other sizes as Eric indicated (in case I'm misreading this), but try to also issue the ecattypedsdo command while EtherCAT is disabled. the drive may be doing something to block you from accessing (even just reading) that parameter to prevent it from being changed on the fly. If it works with EtherCAT disabled, then there may be some other command you need to issue to the drive first to disable it before it lets you change gains, but since it'd be pretty drive specific, I'm not sure what it would be.

Dave, My suspicion is that you issued "gather" to Linux before the data was being gathered. The procedure would typically be: 1. Use the Plot Tool to configure your data acquisition. 2. Click "Gather Data" 3. Once it starts, click "Stop" 4. Issue Gather.Enable =3 in the terminal window. 5. Open SSH connection to PMAC 6. Log in to SSH 7. Issue "gather" at the Linux prompt in the SSH session If you do that, you should immediately see data streaming to the SSH session, which can be stopped by either issue "ctrl + c" in the SSH session (to close the "gather" program which is streaming the data) or by issuing "gather.enable=2" in a GPASCII session (which will actually make PMAC stop gathering data). Steps 1-3 are not essential, but they are the easiest way to configure the Gather Settings correctly. If you know how to, you can configure them manually or copy them out of the Plot tool and issue them from a PLC instead so that it can be done more programmatically. Finally, if you are using "gather -w" instead, then you can do steps 5-7 before step 4, though I would still recommend doing steps 1-3 first. If all of that doesn't work (for either of you), feel free to email me and I can try to help troubleshoot it that way. I do seem to remember one firmware version had broken symbolic links for gather, so it would need to be issued explicitly with the full path--if you follow the steps and it still doesn't work, that might be the issue, for instance.

There's no easy way to do quite that (that I can think of), but if you open your own ssh connection to the PMAC, you can stream the data yourself and do whatever you would want with it. If you have the PDK, there should be an example doing just this, but if not, the short version of it is that you can issue "gather" after PMAC has already started gathering and PMAC will immediately stream all of the data it is gathering to your ssh window. If you issue "gather -w" instead, it will instead enter a waiting state such that, whenever PMAC starts gathering, it will stream. After you have connected the firehose, so to speak, it is up to you to decide what to do with the data. You could gather as long as you want by setting gather.enable = 3 ("infinite" gather) such that you may not even need multiple gathers, but the resulting file could be very long and hard to parse.

tecnico, Someone will email you shortly to help try to troubleshoot your issue.

On January 1st, all of the "@deltatau.com" email addresses were taken down and everything was moved to "@omron.com" addresses. If you had emailed us prior to then, many of us had notices about it in our email signatures, though admittedly, not all of us. If you received any emails from individuals at Delta Tau since approximately last April or so, they would have come from our new email addresses, so you may already have received messages from our new accounts and just not noticed. As for the general tech support, that has been moved to ODT-Support@omron.com. Since this isn't exactly "Power PMAC" related, I will eventually either remove this from the forums or move it to a different forum, but for visibility, I will leave it here for now.

Where are you issuing the commands? If you are trying in the terminal window, that syntax is incorrect--it would be "&1 abort" and "#1 Jog/". If you are trying from inside of a script, the syntax for the first set is still incorrect--it would just be "abort 1", as you abort an entire coordinate system, not a specific motion program. I suspect that your commands are "working" the first time, but addressing the wrong motor/coordinate system.

George, You are correct, this is a firmware bug. While there has not yet been a firmware release since that was discovered, it will be releasing soon, and we may be able to give it to you early in the meantime. Please email "ODT-Support@omron.com" and reference this thread. In the email, please also include your system's response to the "cpu" command when issued in the IDE. Different CPUs require different firmware, and this will help us make sure we give you the correct file.

Can you confirm whether or not PMAC is reading it as a limit switch, or reading it as the correct limit switch? In the "Motor Status" tab of a "Status" window, select the correct motor number and manually toggle the limit switches--you should see bits "PlusLimit" and "MinusLimit" go true and false. If you do not, then verify Motor[x].pLimits and Motor[x].LimitBits, along with verifying that your switches are wired into the correct inputs.

I agree with Eric, in that I'm not sure why knowing the number would be more efficient than using the name. That said, one other thought is that when you perform a build and download in the IDE to load your project, we should map all global variables to pp_proj.h with their corresponding P-Var number. For instance, if I make a blank project but declare GLOBAL MyFirstGlobalVar In pp_proj.h, I get the corresponding line: #define MyFirstGlobalVar pshm->P[8192] Depending on your application, you may be able to read that file as text, then parse it for your desired variable name.

What are you doing while the system is paused? One thing that comes to mind is that typically, one form of the command to start a motion program is something along the lines of "& b r". If the "b " or even just the character "b" were issued while the system were paused, that would reset the program counter to the beginning of the motion program. That said, I'm not sure if the normal method to resume execution would be enough to start the program running again.

It depends. In general, when PMAC tries to enable a motor, it will try to automatically clear any faults. If the fault was momentary and has passed (following error getting too high, for instance), then just issuing another command to the motor (such as "#1J/") would clear the fault and also execute the command. If the cause of it is still true (such as an encoder cable is unplugged), then PMAC will try and fail to clear it because the underlying source must be addressed first.

Power PMAC in general only supports Cyclic Synchronous Position, Velocity, and Torque modes for any slave drives.

Andy, Are you sure that your Motor[x].AbortTa and Motor[x].AbortTs are set to reasonable values for your system? Those parameters are only really used when issuing an abort to control the deceleration profile, so if they were set wrong, you likely would not notice it otherwise.

Jeff, I suspect you may not have the manuals for the ACC-59E3. For newer hardware containing the Gate3 chip (so products such as the Power Brick or Power Clipper, but also products like the ACC-24E3 or the ACC-59E3), we have them on the File Depot under Power PMAC -> Manuals -> Hardware Reference Manual. The specific manual for the 59E3 can be downloaded from here: http://forums.deltatau.com/filedepot/download.php?f=Power%20PMAC/Manuals/Hardware%20Reference%20Manual/ACC-59E3.pdf [FILE REMOVED] Pointers for the 59E3 change a bit depending on the addressing of the card and depending on whether it is the 12- or 16-bit version, however we have an explanation with examples on digital pages 16-17, numbered as 15-16 in the bottom right corner. Those examples assume that the 59E3 is at Index 0--if that is not the case, consult the chart on Page 13 digital/12 numbered to find the base address. In general, they take on the format of: ptr ACC59E3_0_IN1->s.io:$900020.16.16; // First analog input from Gate3[0], 16-bit version, read as a signed value. If you were to change the "s.io" to be "u.io", it would read the register as having unsigned data (that would roll over) instead of being signed data (that saturates). There is also "i.io", which would be signed data that rolls over. As for the 24E2A, the various limits are broken out as individual bits of Gate1.Chan[j].Status, and can be accessed either by looking at their respective bits of that register or with Gate1.Chan[j].HomeFlag, .PlusLimit, .MinusLimit, and .UserFlag respectively. If you do not want to use the pre-made structures, you could use: PTR PlusFlag->Gate3.Chan[j].PlusLimit

Ronald, I'm not sure where you read that homing mode is supported--while we do support the three synchronous cyclic modes, we don't support homing mode. That said, engineers and some customers have gotten it to work before, but even then it still requires a PLC to execute because it is not supported in firmware. A sample PLC that has worked on some 3rd party drives is: //Variables global sdo_result global AmpHomeInProgress global AmpHomeComplete global homestatus global homeerror global sdoretry global servowait //Settings -- Consult Drive Manual for appropriate values sdo_result = ecatsdo(0,0,$607C,0,###,0) // Setup home offset sdo_result = ecatsdo(0,0,$6098,0,###,0) // Setup home method sdo_result = ecatsdo(0,0,$6099,0,###,0) // Setup home speeds sdo_result = ecatsdo(0,0,$609A,0,###,0) // Setup home acceleration open plc 3 AmpHomeInProgress = 0 AmpHomeComplete = 0 cout1:0 // Place motor into open loop mode for homing sdo_result=ecatsdo(0,0,$6098,0,34,0) // Home w/ index pulse // likely will be different for users sdo_result=ecatsdo(0,0,$6060,0,6,0) // Set Drive in Homing Mode sdoretry = 0 while (sdo_result != 6 && sdoretry < 10) // Verify for drive to gets into { // home mode servowait = sys.servocount + 2 while (sys.servocount < servowait) {} sdo_result=ecatsdo(1,0,$6061,0,6,0) sdoretry = sdoretry + 1 } ampctrlword=ampctrlword | $1F // Start homing homeerror = 0 while (AmpHomeComplete == 0 && homeerror == 0) // You should add a timeout { // to this while loop for homestatus = ampstatusword & $3400 // a real production systems homestatus = homestatus / 1024 switch (homestatus) { case 0: AmpHomeInProgress=1 break; case 1: break; case 4: AmpHomeInProgress =1 break; case 5: AmpHomeInProgress = 0 AmpHomeComplete = 1 break; case 8: homeerror = 1 break; default: homeerror = 2 break; } } sdo_result=ecatsdo(0,0,$6060,0,8,0) // Place drive back in position mode ampctrlword = $F // Put amp ctrl word back to normal sdoretry = 0 while (sdo_result != 8 && sdoretry < 10) { servowait = sys.servocount + 2 while (sys.servocount < servowait) {} sdo_result=ecatsdo(0,0,$6061,0,8,0) sdoretry = sdoretry + 1 } jog1^0 homez1 disable plc 3 close Some notes for the above: [*]This code is written as PLC 3, and specifically homes Motor 1. Both of these can be changed if needed. [*]The above code should cause the motor to move. Be sure that it is safe to do so--it is strongly recommended to test it on a system in which uncontrolled motion cannot cause any damage first [*]The above code uses the "ecatsdo" command, which will not work with Acontis. Instead, "ecattypedsdo" must be used. If using with an Acontis system, be sure to convert the commands properly (noting that most of the parameters are re-ordered). Look at the slave device manual to determine the number of bytes for a given parameter. [*]This code has a while loop without any timeout--as noted by the in-line comments, adding a timeout is recommended.

Christer, There are some Power Brick systems that have the 465 CPU in them, however almost all of them use the 460 CPU. Are you sure that your system is compatible with the 2.0.2.14-465 Firmware, rather than the 2.0.2.14-460EX firmware? If you can still communicate with the Power Brick, you can verify which firmware is needed by issuing the command "CPU". A 460 CPU will respond "PowerPC, 460EX", while a 465 CPU will respond "PowerPC, APM86xxx". If you are unable to communicate with the unit currently but truly believe it to be a 465 CPU, you are welcome to contact ODT-Support@omron.com with the serial number and ask us to verify which CPU is inside of your unit.