curtwilson

There is no standard way of doing this, so you will have to employ some "tricks". You will want to set up both motors to close their loops using the position encoder. They will need to be enabled and technically closed loop in all sections of the sequence. Both will be commanded with the same trajectory (you may want to use the leader/follower gantry method). When you want to effectively disable a motor, set Motor[x].Servo.MaxPosErr to 0 and Motor[x].MaxDac to 0. It is still technically in closed-loop enabled control, but it is always outputting a zero command. To switch modes at the right time, you will need to build your moves out of PVT sections, and set these element values with synchronous assignments. For example: inc; // Specify distance Motor[1].Servo.MaxPosErr == 10000; // Default Motor[1].MaxDac == 28000; // Default Motor[2].Servo.MaxPosErr == 0; // Disabling Motor[2].MaxDac == 0; // Disabling pvt20; X200:0.2; // Accel section Motor[1].Servo.MaxPosErr == 0; // Disabling Motor[1].MaxDac == 0; // Disabling Motor[2].Servo.MaxPosErr == 10000; // Default Motor[2].MaxDac == 28000; // Default pvt30; X600:0.2; // Constant speed section Motor[1].Servo.MaxPosErr == 10000; // Default Motor[1].MaxDac == 28000; // Default Motor[2].Servo.MaxPosErr == 0; // Disabling Motor[2].MaxDac == 0; // Disabling pvt20; X200:0; // Decel section ...

Yes, that was exactly what I had in mind! One quick note: When a motor is enabled that has no hardware mapped to it, it may use Sys.Udata[0] for some automatic functions. You probably want to move it to any other Sys.Udata (1 or greater).

I think your best bet is to use the "auxiliary fault" function here. (I am a little surprised that this is not rolled into the standard amplifier fault bit, but auxiliary fault was meant for special cases like this.) You ~10-msec sampling routine needs to put your sampling result into a fixed bit of an integer register (possibly Sys.Udata in the shared buffer). Then you point to this register with Motor[x].pAuxFault and specify the bit with Motor[x].AuxFaultBit. Also set AuxFaultLevel and AuxFaultLimit. Now when the fault occurs, PMAC will automatically "kill" this motor, and stop all other motors in the coordinate system, either to a closed-loop zero-velocity state, or a disabled (killed) state, depending on the setting of Motor[x].FaultMode.

You need to put a "synchronizing line label at the beginning of the program line (Nxxx -- without a colon) So if your line is: N1500 X10 Y20 Coord[x].Ncalc will be set to 1500 when PMAC calculates that line in the program. Coord[x].Nsync will be set to 1500 when the move to (X10 Y20) actually starts executing. In the case of a blended move sequence, this could be a substantial amount of time after the move was calculated.

Now I can see the picture -- I don't know why I could not before. The idea is the same as I suggested before, but including different "S-curve" times (the velocity profile is S-shaped). For example: F20 ta100 ts50 // ta+ts = t1 td200 tsd25 // td+tsd = t2 X100 Remember that if you want separate deceleration times, you must specify them AFTER specifying the acceleration times.

Your image did not come through. But it is easy to do what you want to do. You just need to specify the deceleration time AFTER the acceleration time (because specifying the acceleration time changes both accel and decal). For example: F20 ta100 td200 x10

Your behavior indicates that lookahead is not active for some reason. In segmentation mode, the move-by-move limits are not active, but the segment-by-segment limits require lookahead to be active. In the Executive program, select the View tab, then select "Specialized Buffers". Does it show a lookahead buffer? Even though you don't seem to need much lookahead, try defining a larger buffer and a longer lookahead distance.

To clarify, the special thing about the "LinToPvt" mode is that it takes a move description that is simply axis points and vector speed, and automatically computes each axis velocity ("V") and the common move time ("T"). It then executes the moves exactly as if they were directly programmed in PVT mode. The details of the algorithm(s) to compute V and T are proprietary. The best way to evaluate what they do is to data gather on sample trajectories. Most people who have used the mode prefer type 3 as providing the smoothest trajectories. Several also like to use it with Coord[x].PvatEnable=1 so the method computes 5th-order PVAT moves.

In lookahead, PMAC compares the rate of acceleration from the programmed trajectory to the Ix17 motor acceleration limit. It also compares the velocity to Ix16. As far as velocity is concerned, if I5190 is at the default value of 1000, so your feedrate is in axis units per second, your peak motor speed is 50 cts/msec, which is equal to I116, so lookahead will not reduce this. (If I5190 is 60000 so feedrate is axis units per minute, your peak motor speed is 0.833 cts/msec, less than your limit.) For the "pure" S-curve acceleration you are using, the peak acceleration is V/TS. With I5190=1000, this is 50/50 = 1 ct/msec^2. So lookahead might stretch out the acceleration profile some to keep each segment under the I117=0.5 limit. But this will not reduce the top speed.

What are your values for TA and TS (I5187 and I5188)? If these do not cause rates of acceleration greater than your motor limits, lookahead will not change the profile.

Floating-point representations, with fixed mantissa width, inherently lose resolution when the magnitude gets larger. To illustrate with the decimal equivalent (that we call scientific notation): 1.234567 E0 has a resolution of one millionth of a unit, but 1.234567 E4 has a resolution of one hundredth of a unit. Power PMAC uses 64-bit floating-point representations, with a 53-bit (52 + 1 implied) mantissa. The older Turbo PMAC uses 48-bit representations, with a 36-bit mantissa. The additional 17 bits of the Power PMAC representation provide resolution 2^17 (131,072) times greater than the Turbo PMAC for any value. So you can go over 100,000 times further in Power PMAC before you reach the same issues. I don't think anyone has come close to noticing any issues like this in Power PMAC.

You are obviously losing precision in your data transfer. It appears that one of the 16-bit components of the 32-bit floating-point representation is getting dropped somewhere in the transfer process. The first 16 bits contains a sign bit, the 8-bit exponent, and the high 7 bits of the mantissa. This appears to be making it through. (15.625 has a binary representation of 1111.101) The second 16 bits contains the low 16 bits of the mantissa. This does not appear to be making it through. You can see the actual data PMAC is sending in a cycle using the ModbusQuery command (PMAC as client) or the ModbusServerQuery (PMAC as server) command. This may help you pinpoint the stage in the process where the data is dropped. As to Power PMAC's floating-point reporting: Most fractional values expressed in decimal format do NOT have an exact binary representation in floating-point format, so they are stored as the closest binary value. It is possible to then report them rounded back to a short decimal value (although this takes "judgement" and added calculation time), but you can get into some very nasty cases where two variables that report the same value do not evaluate as "equal" in a condition. This is VERY hard to debug. (Been there, done that...)

Our own benchmarks show that the computational time for atan2 is only 10-15% greater than for atan, on both PowerPC and ARM processors. That is why we need to see your configuration.

There are two limits in the circuitry here. If either is past, you could lose counts. The first limit is the "analog" frequency limit of the differential receivers. The suppliers will not guarantee proper operation past 10 MHz signal (pulse) frequency, which corresponds to a 40 MHz quadrature count (edge) rate. This is a "soft" limit -- a given receiver will probably work at 11 or 12 MHz signal frequency because there is some safety margin built in to the specification, but operation cannot be guaranteed. What may work on one card will not work on another, given part-to-part variation. The second limit is the digital sampling limit by the DSPGATE3 ASIC of the output of the line receivers. In one sampling period, there can only be a transition on one of the A and B inputs for the decoding logic to work. If there is ever a sampling period that sees both A and B change, you get an unrecoverable "count error". (A status bit is set for the channel if this happens.) Even with a perfect quadrature input signals, the sampling frequency must be 4 times the maximum signal frequency in order to see all 4 edges in separate sample periods. Because no signals are ever perfect, we recommend a minimum of 5 times higher. So for your system, you are limited by the 10 MHz receiver limit, which corresponds to 1 m/sec. In order for the ASIC to be able to decode the signals at this frequency, you must use either the 50 MHz or 100 MHz encoder sampling frequency.

I'm not sure exactly what you mean by 0.1um per pulse. If you mean 0.1um between the closest A & B edges, which creates a "count" with times-4 decode, then yes, your max speed will be 4m/s. (If you look at the A and B waveforms in this case, each "pulse" on each signal will be 0.4um. This is why you have to be careful with your terminology. Make sure you set Gate3.EncClockDiv to 0 to select 100 MHz digital sampling of the signals.

Motor[x].EcatAmpEnable is a status element reflecting the state machine of the EtherCAT amplifier. It is intended for internal use.

The Turbo PMAC has the "two guess" method for phasing search. It makes two guesses as to the phase angle that are 90 degrees apart and observes the response. Since the generated torque is proportional to the cosine of the error in the guess, it can calculate the "true" angle. The method assumes that any load torques are insignificant compared to the applied torque. It is especially vulnerable to directional load torques such as gravity. By expanding the method in Power PMAC to four guesses all 90 degrees apart, we can compare the responses of the pairs of guesses 180 degrees apart to understand the effect of directional load torques and compensate for them. This has improved the reliability of this search type. However, most people who have compared this method to the "stepper motor" method believe the stepper motor method is still more robust. The tradeoff is that it requires larger motion in the search.

What formulas are you using for the conversion? According to the ones in the "I-Variable Equivalent" app note and the Software Reference Manual, we get results like: Servo.Kp = 18990 * 96 / (2^19 * 1) = 3.477

All motors assigned to position axes in the coordinate system must be in the closed-loop enabled state to be able to run a motion program in that coordinate system. If you are using the automatic brake control functionality, this means that the brakes will be released in this state, as Eric stated. Any motor not explicitly commanded by the motion program is implicitly commanded to hold its position. With the servo loop closed and enabled, it should be able to do this.

Is your coordinate system in segmentation mode (Coord[x].SegMoveTime > 0)? It looks like a setting of SegMoveTime = 10 msec would explain what you are seeing.

To prevent the possibility of a commanded move in the negative direction, you may want to have a PLC program continually set Motor[x].MinPos just slightly less than the present position (Motor[x].ActPos - Motor[x].HomePos). Set Motor[x].MaxPos to a huge positive value. For protection at a different stage, you may want to monitor Motor[x].ActVel, and if it is negative for several consecutive scans, disable the motor.

You are correct that when motor velocity or acceleration limits are exceeded by a programmed move, PMAC responds by stretching out the move time, which means that a move sequence never catches up. I think you have already found the best way of performing this limiting in a way that you can catch up later -- having the program command virtual motors with no effective limits, and having your real motors follow the virtual motors with MasterMaxSpeed and MasterMaxAccel limits, which do allow you to catch up after they perform limiting.

If you are using the current loop feedback gains that you posted in another thread, these gains are at least an order of magnitude higher than is typical. This could easily result in repeated overcorrection causing the high frequency oscillation you see.

When you are trying to control to the nanometer level, there are all sorts of factors that can cause multiple nanometers of transient errors, both mechanical and electrical. A good control loop can minimize the magnitude of the resulting errors, but never eliminate them completely. It is worth the effort to try to identify the sources of these disturbances. With a crude peak-counting "Fourier transform" of your plots, I think I see significant 15 Hz and 120 Hz components to your errors. (If you were in North America using 60 Hz power, I would be recommending you look at power line issues, but I expect you are using 50 Hz power -- correct?) With less confidence, I think I see an ~2000 Hz component to your errors. Mechanically, you want to be sure you do a very good job on the vibration isolation of your stage. When we test nanometer-level control, we often do the job at 5:30am, before the HVAC comes on in the building and before trucks start going by. Electrically, you want to do the best job you can to prevent electromagnetic noise from getting to your feedback sensor. Putting chokes on the cable to the VCM is highly recommended to reduce switching noise. (Many people use linearly modulated amplifiers for nanometer-level control for this reason.) Careful shielding and grounding of your cables is very important as well. If there are distinct spectral components to your errors, as I think I see, and you cannot eliminate the source of them, you can try "notch" (band-reject) filters in the servo loop. For the higher frequency components, a low-pass filter in the servo loop (with a few hundred Hz break point) can help.

I doubt you would see any significant increase in computational overhead using circle moves in a motion program. The algorithms are very efficient.