Eric Hotchkiss

I am not able to duplicate this issue. Every time I try to read an SDO from a garbage address, I can immediately read from good adresses again aftwerwards. Maybe it is specific to this ethercat slave. You should be able to recover from this state by issueing "ecat reset" in the terminal. As for the SDO access timeout, this is the time after we send out an SDO that we wait for a response. With a value of 0, the EC engineer shows that this uses the master default value. I have been having trouble getting the actual value.

I made a triggered rapid move from a motion program on an IPC with firmware 2.5.0.4 with no issue just in case there could have been a firmware issue and everything went smoothly. The amplifier shouldn't know anything about whether you are in a linear or rapid move. It could be that the drive is drawing too much current to try to start the rapid move and that is leading to other faults being displayed. To test this idea, lets lower your rapid move speed by about 20% (making sure it is also lower than your programmed feed rate) Also set: Motor[x].JogTa=200 Motor[x].JogTs=100 I doubt these values would be suitable for your application, but they should help in troubleshooting. I have been assuming that you are doing software position capture (Motor[x].CaptureMode=1,2 or 3). If you are using hardware capture (Motor[x].CaptureMode=0), then the drive does know that a triggered move is being performed. Is this the case? Are you using your motor in torque or position mode? (What is the value of Motor[x].Ctrl?) Is this firmware version 2.5.0.0 like in the other thread? This could be related to a distributed clock issue, please try putting ECAT[0].DcClockDiff in a watch window. Does it continually count up/down? Does it cycle between positive and negative? Does it stay constant at some value?

What does the amplifier page look like? You should have had to chose ethercat as the topology when first creating the motor. This should have meant the amplifier page has the correct one (from the esi file) in the pull down.

This is a little funny, 0 should disable amp faults entirely, you should need to set this to a small non-zero value. Status bits that pull their information from pointers can be set manually by pointing at Sys.UData addresses, here are a couple examples: // Amp Fault Motor[1].pAmpFault=Sys.Udata[10].a Motor[1].AmpFaultBit=0 Motor[1].AmpFaultLevel=1 // Fault Sys.Udata[10]=1 // Recover Sys.Udata[10]=0 // Enc Loss Motor[1].pEncLoss=Sys.Udata[11].a Motor[1].EncLossBit=0 // Fault Sys.Udata[11]=0 // Recover Sys.Udata[11]=1 // Limits Motor[1].pLimits=Sys.Udata[12].a Motor[1].LimitBits=0 // Plus Fault Sys.Udata[12]=1 // Minus Fault Sys.Udata[12]=2 // Recover Sys.Udata[12]=0 For an I2T fault, you would probably want to set I2tSet and I2tTrip low enough that any current will cause a fault. Motor[x].I2TSet=1 Motor[x].I2TTrip=1

Steve, Try this, it's working on my CK3E. char bUSB_Ready = 0; FILE *f = popen("mount | grep /media/disk-0", "r"); if (NULL != f) { /* test if something has been outputed by the command */ if (EOF == fgetc(f)) {} else { bUSB_Ready = 1; } /* close the command file */ pclose(f); }

This makes sense. Some ethercat slaves do no support bus shift.

Thanks for the reply. I've forwarded the additional information to our software team.

This sounds very unusual. I am wondering if the amplifier could be losing power or otherwise faulting out. It sounds like you have a Linear move set up and working, but your rapid move may be attempting to move the motor too quickly. After the program fails, On the motor status window, what faults do you see? Does the amplifier show any fault codes? What is the value of ECAT[0].MasterState? What is the response to "ecat slaves?" What is your value of Motor[x].RapidSpeedSel? At the default of 0, Motor[x].MaxSpeed (which limits the speed of the rest of the program) is used for the rapid move. If your Motor[x].MaxSpeed is set to high for actual motor, the amplifier may be unable to keep up. Let's make sure Motor[x].RapidSpeedSel=1 so that Motor[x].JogSpeed is used. It may make sense to temporarily lower jog speed for the triggered move, but at least your max speed doesn't need to be changed. Do you have Motor[x].JogTa and Motor[x].JogTs set? Your rapid move will use these instead of the TA/TS set in the program. Triggered moves can be homing, jogging or rapid from in program.

If there is nothing you consider secret, I'm fine answering questions here. Sorry if I've had a hard time keeping up the last couple days. There shouldn't be any associated slew rate. PMATCH sets axis positions based on motor positions. We do need to figure out what's going on with your system though. What is the firmware version since we are talking about an old bug that may be relevant?

I am not able to replicate this issue. Are you using kinematics? That might complicate the PMATCH. If this gets too specific for a public post feel free to email me at EHotchkiss AT DeltaTau DOT com

Gather.MaxSamples is not used in this mode, and the buffer is used in “rotary” fashion, with new samples overwriting older samples as necessary. You may need to increase your gather period or lower the number of variables to sample.

Is that circle 10 by 10,000 or is the 10^3 just left off? In any case, it looks like it's been re-scaled from the 10 by 30 circle I was expecting from the old plot. You may want to take a look at your speed/acceleration parameters. Even if a motion program has to be slowed down to keep one motor within its max speed, the motors will stay synced up and draw the correct shape (just slowly). You might want to make sure this is going at the intended speed instead of being slowed down every time.

Is this number a large integer? If so it should be a number of servo counts. You can multiply this by Sys.ServoPeriod/1000 to get time in seconds.

I'm going to look at just your max speed settings to avoid thinking about acceleration/jerk units. Motor[1].MaxSpeed = 4000 * Mtr1ScaleFactor Motor[6].MaxSpeed = 100 * Mtr6ScaleFactor I'm assuming Mtr1ScaleFactor is the Value of Motor[1].PosSf you are using. Taking a look at "Motor[1].MaxSpeed = 4000 * Mtr1ScaleFactor" to me this says 4000 counts/msec was a good speed, but now I'm changing my units to mm (or whatever) so now now I need to scale that max speed to motor units. If you motor units are already in mm and you want a max speed of 1000 mm/msec, then you would set Motor[1].MaxSpeed=1000. Of course 1000 mm/msec is a particularly high speed, maybe you are looking for 1000 mm/sec or Motor[1].MaxSpeed= 1 [mm/msec]?

I added (the omron version of) the ESI files and I was able to restart the IDE without losing the ESI files from the pull down. Please try changing the permissions on C:\ProgramData\DeltaTau . Note that while ProgramData is a hidden file, you can paste the location into your file explorer's location bar. Setting up EtherCAT involves making an ENI file for PMAC. If you use the built in copy of EC Engineer, the "Import Slaves" option will internally pass that ENI file. If you already have an ENI file, then you can use the "Import Slaves from ENI" option to browse for it. I'm not sure I understand, are you asking about just the ethercat settings?

If you have more than a couple identical slaves, it is possible to delete slave 2 and then copy slave 1 to slave 2. This was specified with names of move modes instead of values of $6060 in etherlab. The defaults could be different between modes. This is not expected behavior. How are you checking if EtherCAT re-enables? If you are checking ECAT[0].MasterState, then you may need to have ECAT[0].RTStateCheck=1, depending on firmware version. When it fails to change, what is the response to "ecat slaves"?

The option is unavailable because EtherCAT is currently enabled (or trying to be enabled). You should be able to select the "Deactivate EtherCAT" or set ECAT[0].Enable=0 in the terminal to allow the "Load Mapping to PowerPMAC From ENI" option. That is the correct location to pull the ENI from, the main point is it's in the configuration folder of the uploaded project. I just copied a project off a 1s drive, did a $$$***, imported the ENI and confirmed that was enough to "Build and Download All" and jog the motor. For the ESI file not showing up. Was this an Omron ESI. It may have been merged into the existing Omron folders. I currently have some Beckhoff ESI files added and I still see the menus that contain the ESI files after re-opening.

The first thing I notice about this motion, is that motor 6 has essentially a constant velocity for a large fraction of the move. This likely means that the motors do not have the same speed/acceleration limits as each other. Please check the following in the terminal for both motors 1 and 6. Motor[x].MaxSpeed Motor[x].InvAMax Motor[x].InvDMax Motor[x].InvJMax Motor 6 also seems to be moving less than motor 1 overall. Please enter the following into the terminal 1 at a time to see axis definitions. If it possible they have different axis scale factors. #1-> #6-> Are these motors identical? Do both motors show the same change in position when rotated one revolution? It shouldn't matter what amplifiers the motors are on.

Some amplifiers require that the PWM signal actually switch to continue to function properly. If we allow a 100% duty cycle by setting Motor[x].PwmSf to a value of 16,384 or higher, there may be an issue. Delta Tau Amplifers with this issue should fault out, but you might as well be safe. For amplifiers without this limitation, PwmSf can be set higher and there is actually a reason to do so. For 3-Phase motors we like to use a feature called third harmonic injection. This lowers the voltage of the peak of a sine wave, but keeps it near the peak longer. PwmSf can be set higher to get back to the expected voltage. If it is set higher than 16,384 that means we are allowing voltage saturation for some part of a sine wave (this only really matters at speed). The GPL 102 shows a maximum of 90% of 16,384 in the hardware specific manual and that should be used. It looks like there is an issue in system setup we will be looking into.

Matsuzawa, I'm not sure if reviving forum posts that could have been the same problem is the best strategy. If you are having trouble installing IDE 4 please send an email to support@deltatau.com so we can look into your issue specifically. Regards,

Glad I could help :)

Typically when a PDO name shows up repeatedly within the ecat map, that indicates the ESI file had non-unique PDO names. In some cases I've seen ignoring the problem lead to strange behavior, like torque mode motors not being able to end open loop commands. The fix for this is to add enough to the names of the PDOs you use to make them unique. I am attaching pages from a PDF explaining how to set up a specific elmo drive. Take a look at page 4 where step 6 begins. This shows exactly how to add a "1" to every PDO name in the mappings you are using, after clicking "Edit" on the correct PDO mapping. PDO Unique Names.pdf

Dave, If this requires installing debian packages, see the Network Time Application Note.

On your IDE 4 computer please try the following and report results. Go to C:\DeltaTau\PowerPMAC\Compilers\opt\powerpc-465-rootfs\usr\src\linux-3.2.21-serengeti-smp\scripts and confirm both Kbuild.include and gcc-goto.sh exist. I am told if they don't you need to reinstall the compiler, but you already did that. In the IDE, go to Tools->Options. Expand "Projects and Solutions" and select "Build and Run". The second to bottom option is called "MSBuild project build output verbosity:". Set it to Normal and click ok. This will give more verbose error messages on build and download. Try to build and download the project again and see what error messages you get. Create a new project, put your usralgo on a motor 0, try to build and download. Does it succeed. What error messages do you get? New Project, add usralgo, does build and download succeed?

I forgot to add, IDE 3 and 4 can coexist on the same computer so the etherlab setup process doesn't take multiple computers. I typically keep the most up to date of both installed on mine.