Dan1223

Would the movetime command provide the calculation you are looking for? I have used this for simple linear moves but I haven't tried using it with a spline move.

Thanks Sina, I figured there should be a way to use the command buffer I just didn't have the time to figure out how.

Sina, Is there a way to use the command buffer to issue the ver command from a plc and have the output redirected into an M-Var or P-Var? Ideally i would like to log the firmware version on power up in plc 1 and store them in variable space. This will allow me to verify that the firmware version are correct before allowing the machine to run.

I have the same controller with sigma 5 motors. The sigma 5 motors have a signature sound. If you use the autotune in the amp you will end up with the same buzz. You also get it with the Yaskawa controller. I was able to reduce this noise in the Delta Tau tuning to a point where you don't notice it. My approach was to lower the proportional gain and increase the Derivative and Velocity Feed Forward gains. I found with all the feedback on the sigma 5 motors proportional gain seems to make them unstable. Here is a typical tuning set i am using with good results. This should give you an idea of how the gains typically scale in my experience with Sigma 5 motors. I130=20000 I131=25000 I132=25200 I133=1000 I134=1 I135=25000

The Turbo UltraLite has 256 16 bit words of standard modbus memory. Our Linux PC reads all 256 words of modbus memory and makes a duplicate memory map in the PC. The PC is functioning as the master and poling the Delta Tau. The only trick is to make sure you do a block read of registers so they are in one data packet. We logged the system time in the PC of the the modbus requests. This allowed us to verify that we are able to get the entire standard modbus memory map back to the linux PC in under 2ms. The only issues we had are all related to other network traffic. This was an issue when we had the Delta Tau on our in house network at which point our updates where at 10-15ms. When we moved it to the machine internal network we haven't seen any issues with speed.

Just as an FYI I have been using the modbus in the Turbo UltraLite controller which is probably pretty close to the brick controller. I am able to read the entire modbus memory block in under 2ms from linux on my system. The biggest problem i have seen isn't the Turbo PMAC it is the Linux computer being loaded with network traffic to other devices. I would expect that the brick can handle the same 2ms update rate i have been able to hold on the UltraLite.

Check the Turbo PMAC Users Manual. There is a section Turbo PMAC Ethernet Protocol

You can switch to PLCC's they run faster. There are a couple of small things like MSR commands which require you send them through the command buffer but the code is complied so it can't be uploaded. I am using complied plc's to protect my code. The motion programs can be uploaded still without a password but you don't have to worry about passwords in the field installs.

Did you check Ixx17? I think this is your problem. See below from the SRM xx17 Motor xx Maximum Program Acceleration Range: Positive Floating-Poin Units: counts / msec2 Default: 0.5 Ixx17 sets a limit to the magnitude of the commanded acceleration for certain programmed moves in certain modes on Turbo PMAC. 1. Non-segmented LINEAR mode moves: If the Isx13 segmentation time parameter for the coordinate system containing Motor xx is set to 0, which takes the coordinate system out of segmentation mode, then Ixx17 serves as the maximum velocity for Motor xx in LINEAR-mode moves in the coordinate system. If a LINEAR move command in a motion program requests a higher acceleration magnitude of this motor given its TA and TS time settings, the acceleration time for all motors in the coordinate system is extended so that the motor will not exceed this parameter, yet full coordination is maintained. If Isx13 is set to 0, CIRCLE mode moves and cutter radius compensation can not be performed. In this mode, Turbo PMAC cannot extend the acceleration time to a greater value than the incoming move time, because to go further would require re-calculating already executed moves. If observing acceleration limits (especially for deceleration) requires acceleration or deceleration over multiple programmed moves, the Ixx17 limit in this mode cannot guarantee that the limits will be observed. Special lookahead is required for this capability. In this mode, the Ixx17 acceleration limit can lower the speed of short programmed moves, even if they are intended to be blended together at high speed. The algorithm limits the speed of each move so that it can decelerate to a stop within that move. Without special lookahead, it cannot assume that it will blend at full speed into another move. 2.SegmentedLINEARandCIRCLEmodemoveswithlookahead: IftheIsx13segmentationtime parameter for the coordinate system containing Motor xx is set greater than 0, put the coordinate system in segmentation mode and the special multi-block lookahead function is active (lookahead buffer defined and Isx20 greater than 0). Then Ixx17 serves as the maximum acceleration for Motor xx in all segments ofLINEARandCIRCLEmodemovesinthecoordinatesystem. Ifasegmentofoneofthese programmed moves requests a higher acceleration magnitude of this motor, the segment time for all motors in the coordinate system is extended so that the motor will not exceed this parameter, yet full coordination is maintained. 78 Turbo PMAC Global I-Variables Furthermore, the Turbo PMAC will work back through already calculated, but not yet executed, segments, to make sure the change in this segment does not cause violations in any of those segments. Note: Ixx17 is not used for segmented LINEAR and CIRCLE mode moves when the special lookahead buffer is not active. The Ixx17 acceleration limit calculations assume that the coordinate system is operating at the %100 override value (real-time). The true acceleration will vary proportionately with the square of the override value. The use of the Ixx17 limit permits the setting of very small TA and/or TS values (Ixx87 and Ixx88 by default). Do not set both of these values to 0, or a division-by-zero calculation error could occur. It is advised that the TA time is set no smaller the minimum programmed move block time that should occur. Example: Given axis definitions of #1->10000X, #2->10000Y, Isx13=0 and Ixx17 for each motor of 0.25, and the following motion program segment: INC F10 TA200 TS0 X20 Y20 The rate of acceleration from the program at the corner for motor #2 (X) is ((0-10)units/sec * 10000 cts/unit * sec/1000msec) / 200 msec = -0.5 cts/msec2. The acceleration of motor #2 (Y) is +0.5 cts/msec2. Since this is twice the limit, the acceleration will be slowed so that it takes 400 msec. With the same setup parameters and the following program segment: INC F10 TA200 TS0 X20 Y20 X-20 Y20 The rate of acceleration from the program at the corner for motor #1 (X) is ((-7.07-7.07)units/sec * 10000 cts/unit * sec/1000msec) / 200 msec = -0.707 cts/msec2. The acceleration of motor #2 (Y) is 0.0. Since motor #1 exceeds its limit, the acceleration time will be lengthened to 200 * 0.707/0.25 = 707 msec. Note: In the second case, the acceleration time is made longer (the corner is made larger) for what is an identically shaped corner (90o). In a contouring XY application, this parameter should not be relied upon to produce consistently sized corners without the special lookahead algorithm.

I believe you are hitting the Ixx17 Motor max program acceleration limit. I have "jog" from a motion program before simply by blending short moves inside a loop. In my case i had a long move to accelerate up to speed and then tried to blend shorter moves at the same velocity until a trigger event. At which point i wanted to decelerate with the same profile i used to reach velocity. The issue I ran into is that the blended moves would slow down to a velocity which allowed the move segment to travel from the current velocity to zero speed in the time of the move while not exceeding the Ixx17 acceleration limit. This seemed to be true even though there was a blended move at velocity following the segment move being preformed. I had to raise the Ixx17 limit during these moves even though it exceeded what my system could physically perform and simply trust the fact that program contained a blended deceleration move was a valid rate for my system.

Instead of setting up a serial to Ethernet converter you can enable the Ethernet Modbus on the Turbo PMAC. I am using Modbus for my control interface. We have a Linux PC running the system and setting up Modbus was easier for our software development team. When I log data I have a ring buffer in the controller simply a block of P-Vars with as many data points as I need to insure are stored. I then have two p vars, which are locations in the array. One is the next point to store a value on the DT side. The other is the last value read over Modbus. I copy the P-Vars to Modbus memory in a single PLC so I know all of them update at the same time for the remote host. On the linux side I simply request the entire Modbus block of data. The data I am looking for is the section of the array between the two indexes. I then update the index value for the last read location over Modbus. From the DT side the Modbus memory is just mapped M-vars. The nice thing about Modbus over Ethernet is that there are a lot of drives to support it.

Yes in theory the EtherCat network is very fast. In practice I have not seen an amplifier which is able implement that speed on EtherCat. Check out this document from Yaskawa about their Sigma 5 amplifier with the EtherCat option. http://www.yaskawa.com/site/dmservo.nsf/536df907f9fe9d5586256c4e0056b851/86256ec30069fdef8625771a006b3d92/$FILE/FL.SGDV-EC.01.pdf Sigma-5 with Real-Time Ethernet Communication Ethernet for Control Automation Technology System Performance • 1.6kHz velocity loop bandwidth delivers increased machine throughput by slashing settling time As I stated i don't understand why but every EtherCat amplifier I looked at ended up at this same sub 2kHz bandwidth. If you know of a 10kHz amplifier and motor combo on EtherCat please share I would enjoy working with it.

I tested a few different EtherCat amplifier and I also looked at some PowerLink amplifiers. They can close the servo loop quickly inside the amplifier itself if you are able to wire the feedback to the amp. This allows for the much faster servo rates at the amplifier. But if you need to coordinate though the motion controller the rate is about 2kHz. The closest i got to an answer as to why is that PowerLink can't process data faster then 2kHz. The recommendation I received was to wire an encoder input to the amplifier and allow the amplifier to close the servo loop internally to solve this issue. To sync two servos faster then 2kHz on PowerLink it is recommend that you use an encoder output from one amp wired to the encoder input of the other amp. This can lead to some tricky issues with a secondary encoder or high speed vector locking. Both EtherCat and PowerLink run on standard Ethernet hardware. PowerLink have some hardware requirements but basically it is standard cat 6 Ethernet. I am speculating the underlaying issue is the current ethernet hardware as both EtherCat and PowerLink seem to have the same limitation.

Having tested several different drive systems recently I came to the conclusion that Yaskawa Sigma 5 motors over Macro utilizing the acc85M from Delta Tau provided the best control solution for my current project. I am using the Turbo PMAC Ethernet Ultralite controller. I haven’t actually used the Ethercat drives on the Power PMAC but I have looked at several completive products using Ethernet based drives this includes Ethercat and Powerlink. I have run several different controllers and drives on a 5 meter long belt driven rail beam system with a moving mass of approximately 200lbs. The testing performed included utilizing a laser informatory system to verify the velocity stability and positional repeatability. The major difference I found is the servo update rate. A motor controlled over macro allows you to update the servo loop at 8kHz. Ethernet based amplifiers only allow you to update the servo loop at approximately 2kHz. The best I have been able to determine this is just a physical hardware limit of the Ethernet based amplifiers. The higher servo update rates over macro allow you to control the servo with a torque output resulting in improved velocity stability. Most Ethernet based amplifiers address the issues of a slower network speed by closing the torque loop in the amplifier and controlling the servo in a velocity or position mode. This can result in having to run two turning loops or difficulty closing the servo loop on a secondary encoder. As I haven’t yet worked with the Power PMAC I can’t speak to how the speed of the servo loop is handled over Ethercat in this system. I will add that I am able to completely configure the Yaskawa Sigma 5 amplifier and a Copley amplifier over the macro network. We produce several systems a month at our factory. This design allows us to set the hardware address switches, load the Delta Tau source code and the system will configure the amplifiers at power up. If an amplifier is replaced this will be detected at power up and it will be programmed with all the required settings. Coding of the auto setup over macro was time consuming but has resulted in greatly simplified system startup. I have come to the conclusion that using the Macro network for the servo motors and utilizing the Ethercat network for remote I/O or motion which can accept slower update rates such as VFD motors is a good general design approach.