Gregs

It appears that the ESI file is giving wrong info. That said, a PLC might be used to write the value into Sys.UData[x] and read it out of Sys.IData[x].

You might try setting Gate3[0].PhaseServoDir=3 and Gate3[1].PhaseServoDir=0 and set up the clocks on Gate3[1].

It seems as though the motion program entered a subprogram, thus changing the stack offset, according to the following chart for default settings: Is there a Call or CallSub command in the program that's being run?

You might find some answers in the Turbo PMAC Users manual (attached) under the heading WRITING A HOST COMMUNICATIONS PROGRAM. As for communications manual, there is the PcommServer manual which comes with the purchase of the PCommServer Pro2 library, for writing HMI applications, part number 3A0-9PPRO2-35x. TURBO PMAC USER MANUAL.pdf

Why do you say that it looks like some other parameter is limiting the maximum speed, other than Motor[x].InvaMax? If increasing Motor[x].InvaMax from 60 to 100 mm/s^2 allows the max speed to be reached, isn't that the parameter that was limiting the speed? By the way, being that this is "inverse of maximum acceleration" increasing from 60 to 100 is affected by changing the value from 0.017 to 0.01 (1/60 to 1/100), right?

How well is the motor tuned? Can you show a screenshot of a tuning plot(s)?

Theoretically yes, but it depends on what's not working on the PowerBrick[0] board. What errors are reported with PowerBrick[0] and with setting up with channel 5 on PowerBrick[1]?

That VDC calculation is wrong. It should be sqrt(2) (~1.414) times Vrms: VDC = Vrms * 1.414 = 220 * 1.414 = 311 VDC

Try the "Why is my motor moving slowly?" by selecting "Troubleshooters" in the IDE "Delta Tau" tab. Depending on how the move is commanded, it might be something like Motor[x].MaxDac or Motor[x].MaxSpeed.

I suspect a tuning issue, maybe needing less proportional or more derivative gain. A plot file or screenshot of the tuning step move might be revealing. I suggest sending to ODT-Support@omron.com.

The answers depend on various things: What type of motor? What type of amplifier? What type of Power PMAC? What "PLC" are you using? Power PMACs can be configured for a wide variety of hardware, and as such setup is not a trivial task. Three and four day classes are offered which are meant for getting motion control professionals started on PMAC setup and programming. You might consider getting help from an Omron Delta Tau integrator.

The control type should not be Direct Micro-Stepping. Try Velocity, or Torque.

Try re-initializing ($$$***). The following copied from the Power PMAC Users manual: If the hardware configuration the CPU finds on power-up/reset is not the same as that in the last valid saved configuration, the Power PMAC will come up in an error condition, setting global status bit Sys.HWChangeErr to 1. In this case, the user must make the software system configuration match the new hardware configuration (usually by using the $$$*** re-initialization command), save this configuration, and reset the system before proceeding.

It looks like somewhere you have "JogSpeed" defined as "p63", i.e. a #define JogSpeed p63. That would change Motor[1].JogSpeed to Motor[1].p63, which is an "invalid parameter". I believe that should be Motor[1].MotorMode, not Motor[1].MotorNode. Try setting Motor[1].pPhaseEnc=sys.pushm instead of =0.

How will motors 1 and 2 be commanded to move? Jog moves issued from the PLC? Motion program moves, and if so, what mode, e.g. linear? Either way, I think that cascaded loop might work for this, with motor 1 on the inner and motor 2 on the outer loop, integrated so as to be a velocity correction to motor 1. See in the Power PMAC Users manual under the heading Cascading Servo Loops. Motor 2 would be commanded to move as desired when motor 1 is at 0 velocity.

OK, but doesn't CmdPhaseX work now, using Dave's approach? I believe the problem with not seeing an error message is that you're not looking in the right place. The PLC is on a different thread than the Terminal Window. Try checking Ldata.CmdStatus in the PLC after the CmdPhaseXYZ command. I believe you'll get a "-21" error code. See under the SRM manual's description for the "cmd" command.

Is the correct coordinate system addressed? Power PMAC defaults to coordinate system 0. Either way, it's best to put that in, i.e. #define CmdPhaseX cmd"&n#1$", where n = coordinate system #.

The reference clock is always provided by one of the slaves, generally the first in the chain. PMAC’s servo clock needs to be synched with the reference clock. With bus shift, the master clock is not “synching to the Reference Clock”. Rather, all the slaves synchronize to the master clock, i.e. the servo clock. Master shift is the ideal choice. I don’t know the reason, but I suppose it’s at least because, with PMAC handling all the synching, that puts less burden on the slaves. However, problems can occur if there are local axes, and the easiest way to avoid them is to instead use bus shift. See the attached document, but note that it mostly deals with issues with master shift, not bus shift. However, it does state that "certain EtherCAT Slave devices have been observed to have issues when Bus Shift mode is selected". The ECAT[0].Error can be ignored because it only applies to Etherlab, not to the Acontis stack. What does FBUS.PARAM02 do? What messages do you get when activation fails with bus shift? Synchronizing PMAC and EtherCAT Clocks.pdf

For homing, without absolute feedback, the axis must be moved to a position where an input is triggered to indicate an absolute position. Software alone cannot determine an absolute position. With software, the home position can be set equal to the current position using the HMZ command.

I reread your initial post, and now I don't understand the setup. It sounds like there are two Clients and maybe two Servers, and the UMAC is one of the Servers. If that is the case, I can't speak for the other Clients. If PMAC is a Client to multiple Servers which have the same Modbus addresses, there is no conflicting or overlapping because each Server will have a unique IP address, and those addresses will be mapped to unique addresses in PMAC. For example, see the attached "ExampleSetupScreen" to see how it's done in the Modbus Setup window, copied from the attached "MODBUS TEST SETUP EXAMPLE" document. MODBUS TEST SETUP EXAMPLE.pdf

There is no conflict if each Client on the PMAC uses different Modbus addresses in the User Buffer. However, the same addresses can be written to. It's just that what one writes will get overwritten by the other. I think it might be necessary to hand shake so not reading or writing at the same time. That's how I did it in some test programs.

This sounds a bit like the USB/Eth flash is failing; however, the No EEPROM error is often fixed by reloading communication firmware. Here is a link to a post on the Turbo Forum with instructions: http://forums.deltatau.com/showthread.php?tid=63&highlight=firmware

A couple of other things. You might try manual phasing in order to determine if poor phasing is the problem. Faulty feedback is another thing that can cause following error. Typically, an encoder count error will be a clue if there is a problem with the feedback signal. If the "Suggested M-Variable Definitions" have been downloaded as shown in the Turbo Software Reference manual, M318 will be set =1 if an error was detected. What type of Turbo PMAC is this?

That could be caused by improper tuning. Check your settings. The following was copied from the Turbo Clipper User manual.

What type of Power PMAC do you have? Your post is in the Turbo PMAC section, and the IDE does not work with Turbo PMACs. This issue is better suited for technical support. Please email to ODT-Support@omron.com for assistance.