Alex Anikstein

Roman, The Power Clipper is a 465 CPU, not a 460. Please try again using the "2.1.1.3 powerpmac465.zip" or "powerpmac465 2-4-0-180.zip" file from the File Depot, depending on which version you wanted to load.

The version of the IDE manual on the File Depot is not correct for the newest released IDE (4.3.2.19). Instead, you can find the manual for a specific IDE version included in the IDE installation under the "Help" dropdown menu. This version should include proper feature locations and recommendations. Our Application Notes are often made using a specific version of the IDE, but unfortunately, we do not go back and update them very often for newer IDE layouts. If there is a specific issue you're having difficulty with finding or configuring, we can try to point you in the right direction, or even just having the proper IDE manual may help find things, but that is the best I can offer currently.

John, Were both computers addressing the same system? If not, is there anything that might explain it between the systems (number of motors active/enabled, maybe changes to Sys.MaxMotors or something since last boot)? I'm on Windows 10 and cannot replicate it yet with the hotkey or the menu button, but I'm going to have more people test this specifically. Can you send us a picture of the error message, either posting it on the forums or emailing it to odt-support@omron.com?

The spikes may be due to some noise on the encoder--if you look at the "Interactive Feedback" pictures, the encoder reaches some arbitrary points not actually on the circle. In addition to checking the phasing, I would also double check the soldering (if you have an adapter or anything) and that the encoder tape is clean and properly aligned/spaced.

Tuning an EtherCAT drive often results in very different gains than a local drive. For normal (not EtherCAT) motors, Kp/Kd values often are in the hundreds/thousands/ten thousands. For EtherCAT Torque Mode, it is not uncommon to see fractional values (<1). Unfortunately, I cannot recommend gains for that particular drive as I have not tested it. If you are happy with the performance in position mode, feel free to continue using it like that. If you need to put it into Torque mode, start off with very small values (Kp = 0.001, all other gains = 0) and then go from there. As windell emphasized, make sure your motor is in a safe state first as it may be unpredictable.

That is correct--in Turbo PMAC, the encoder must be bounded at all times between the CompA and CompB registers in order for the auto-increment feature to function.

Ethernet/IP Support is undergoing development and testing. The current projections are that it will be ready for release in April 2020.

(Moved post to Power PMAC)

(Moved to Power PMAC forum)

Hannsx, Can you email me at Alex dot Anikstein at Omron dot Com? I'm curious as to why you need this drawing, and I'd rather send it via email than posting it here, anyways.

Hannsx, If you're referring to the holes in the casing for mounting screws, the drawing in the top left of the page Eric referred to shows just that:

Doug, 1) On the Amplifier page, did you make sure to click the "Accept" button on that page? If there is an "Update Database" button, at one point I know there was a bug associated with that and EtherCAT drives, though from your screenshot, you seem to be using a newer version of the IDE after that was fixed. 2) Did you map your input and output PDOs? If there are no PDOs mapped that can be used for those signals, they may show up as Hardware Mismatch. 3) If you click on the "Hardware Mismatch", can you just verify that there is nothing else in the dropdown--that Hardware Mismatch is the only option?

Matheus, If you're already using a system command to do the gather, try instead system "gather >> /var/ftp/gather/data.txt" (after the gather has already started but before your motion/data to gather occurs) or "gather -w >> /var/ftp/gather/data.txt" (before you issue the gather command--the "-w" will tell the pmac to "wait" for a gather to start).

Can you confirm--does Masterstate ever go to 8 at this point if you let the system sit long enough? I've seen it go to 2 at first, but then goes to 8, which is the correct status when the system is in OP mode. Additionally, can you try to issue an "ecat reset" after it gets in the state where it doesn't work to see if that changes anything?

It appears as though that is a bug. In the meantime, please re-order your files manually so that they're in alphabetical order, however I will flag this to the software team to be addressed.

Not really, the +5V ENCPWR signal is passed through via hardware, not controlled by the PMAC logic. What form factor specifically are you using, though, and is there something in particular you want to accomplish? There may be other ways to get the same result.

Typically, you would set the starting point (X0) to -200000, then set the span of 200000.

The IDE will download the files in the order they appear in the project manager (with respect to a specific folder). In previous versions, this was always alphabetical, and there was no choice. We had managed this by using prefixes before each file (typically numbering them--"01-", "02-", etc.). As Tony noted, as of IDE 4, this is no longer required, as you can now manually re-order the files and therefore the order in which they download.

andyf, At this point, our documentation that is exclusive to Power PMAC (namely, the various CPUs and then cards containing the DSPGATE3) are only available through the File Depot. Other accessories which can be used with either Power or Turbo PMAC are available on the "Manuals" section of our home page, without requiring a user account to access them. That can be found here: http://www.deltatau.com/Manuals/Default.aspx Here are specifically the manuals for the ACC-65E and the ACC-84E.

You may want to look into Coord[x].SegMoveTime more than Sys.RtIntPeriod. If too little time is being given for segmentation, that can cause watchdog faults. Additionally, have you looked into taking our Training Class, or watching some of the training videos? For instance, discusses setting up kinematics. What type of kinematics are you implementing, anyways? Some types are naturally going to cause a heavier computational load and are more likely to cause this kind of issue.

The kill command does not tell the amplifier to stop moving the motor, but rather, tells PMAC to stop outputting data to the amplifiers/motors. Because of this, the motors will coast to a stop. If you want a controlled stop, look into the "abort" command, which should bring motors in a given coordinate system to a stop at rates controlled by Motor[x].AbortTa and Motor[x].AbortTs.

If you are using kinematics and issue a "rapid" move, PMAC will simply send each individual motor to their own final endpoint. Try that, without changing your axis definitions. as that may do what you want.

Linda, That would not work as you wrote it--the axis definition statements are on-line commands, but "linear x10 y10 ..." and "rapid x20 y20 ..." would be program moves. What are you trying to do, however? If you are attempting to control a robot/system that uses kinematics, it is likely better to use kinematics at all times after your motors are in closed loop and homed, and then just use linear moves any times you are trying to go directly from one point to another. Is there a reason you specifically want to do a rapid move?

Also, are the clock settings the same (Gate3[0].PhaseFreq/Gate3[0].ServoClockDiv)? That's the other big "non-tuning related" thing that has a large impact on tuning.

Allen, I'm not sure if your X and Y Distances are absolute or incremental, so I will assume those are absolute positions. In that case, the first two moves of your code would look something like: ABS //As opposed to Incremental RAPID //Simple point to point move X15.5 Z10.00593659 //Go to start point INC //Future commands will be issued incrementally--could be left absolute PVT 100 //Switch into PVT mode, with each segment having 100 ms X -0.01:1 Z 0.03117989:-4.43579 //Move X 0.01mm incrementally backwards with a velocity of 1 mm/ms, move Z 0.03 units forwards with a final velocity of -4.43 mm/sec X -0.01:1 Z 0.06277107:-8.56177 //Move X 0.01mm incrementally backwards with a velocity of 1 mm/ms, move Z 0.06 units forwards with a final velocity of -8.56 mm/sec I would note that your signs seem off--you move positive when your velocity is negative and vice versa. Because you command the velocity at the endpoint with a PVT move, you can command a move like that, but it likely is not what you want. Your system would need to overshoot drastically, then reverse direction and travel through the desired point at the desired time with the desired (backwards) velocity in order to satisfy the move.