curtwilson

This should be possible, but -- WORD OF WARNING -- it has not been tested at all by us. You will want to use the excitation output to the LVDT and then read the stimulated "sine" and "cosine" feedback signal values directly. You will need to optimize the phase, magnitude and frequency of the excitation signal in a manner similar to that for a resolver. However, you cannot use the Gate3's "SumOfSquares" value to do this -- you will need to look at the raw feedback values in the channels AdcEnc[0] and AdcEnc[1] registers and try to maximize the difference for a given position. In operation, you will want to use ECT entries with EncTable[n].type = 1 to read the AdcEnc[0] and [1] registers. Then you will use an EncTable[n].type = 9 entry to compute the difference between these values. The resulting difference should be usable as a position value.

Accesses to global variables are atomic, so this is not a concern.

Follow the instructions in the Power PMAC Users Manual to set up a motor to command an external pulse-and-direction stepper drive. The only difference is that you will use the PfmFormat variable Chris mentions to convert the output format from P&D to quadrature. This virtual motor will use the sinusoidal encoder value as its master to follow the sinusoidal encoder position processed through the encoder conversion table. Yu will need to set up Motor[x].pMasterEnc, Motor[x].MasterCtrl, and Motor[x].MasterPosSf for the virtual motor.

I think the move command you want is: G02 X0.25 Y0.25 I0.25 J0 This specifies the center for the arc as +0.25 units in X from the starting point and 0.0 units in Y from the starting point. Your move command specifies the center point the same as the ending point. It is not mathematically possible to create an actual arc for that.

The F (vector feedrate) specification for moves is useful for moving in a 2D or 3D Cartesian system (spatially perpendicular axes) so the tool is moving in the plane or space at the same speed regardless of direction. When this specification is used, PMAC automatically calculates the time for a move as (VectorDistance/VectorFeedrate), with VectorDistance computed as sqrt(Dx^2 + Dy^2 + Dz^2) for a 3-axis system. I think this is fundamentally the wrong mode for you to be using here, as you do not seem to be using your X and Y axes as spatially perpendicular axes, wanting a constant vector speed over this 2D plane. Most people who want to create a custom profile as you are doing from a series of small moves with many intermediate points on the move use the TM (move time) specification, typically with a constant TM, TA=TM, and TS=0 to produce a quadratic B-spline fit of their desired profile. I think this will create the profile you desire.

In at least some servo cycles, your servo tasks are not finishing before the next servo interrupt. Sys.ServoBusyCtr increments if the previous cycle's servo tasks are not finished when this cycle's tasks are supposed to start. Sys.ServoErrorCtr increments if the previous cycle's tasks take so long that this cycle's tasks cannot even start. For good performance, you should not be incrementing either of these. Even without a watchdog failure, you can get bad servo performance. You need to look carefully both at how high your servo frequency is, and what tasks you are trying to do in the servo interrupt. You should not be doing any tasks in the servo interrupt that are not highly predictable as to the time they need. If you cannot change the tasks you have executing in the servo interrupt, you may need to lower your servo frequency. You should be monitoring the servo task times, both average and peak, in the IDE's task manager.

Yes, that is why the value in the actual current register is always zero. If you are not in direct-PWM mode, that register is not used. You will have to get the drive documentation to see if there is a way to get that information from the drive. Even if you can, it will be very difficult to synchronize it with the PMAC information.

That is not a direct-PWM power block drive. LSIS does not sell drives of that type. The PMAC will not get any actual current information from the drive, as the current loop is closed within the drive.

What amplifiers/drives are you using? What is the command signal from the Clipper to the amplifier?

The PMAC only has access to actual current information if it is performing "direct PWM" control of the motor, closing a digital current loop with current feedback from a "power block" drive. This is rarely done with the Clipper, unless you have the Clipper Stack integrated drive. Is this your configuration?

I don't see that you would get any benefit from reducing your microstepping resolution by a factor of 10. Whatever the commanded phase angle is each servo cycle, PMAC uses the closest entry in the 2048-entry sine table to calculate the phase currents. This table resolution is high enough that even if the table entry selected does not represent the exact mathematical phase angle desired, the error is small enough compared to the electromagnetic and mechanical imperfections of the motor and its load that this error can be ignored.

I am unable to duplicate the "assignment" of CS0 to a program without a command pointing the CS to the program. It is easy to do inadvertently because the default addressed coordinate system is CS0 -- I have done this many times. Even if some quirk caused this assignment without your command, it is of no consequence. It does not inhibit you from pointing another CS to this same program.

In Power PMAC, Coord[x].SegMoveTime is a floating-point number that can be set less than 1.0 msec. (This is not true in the older PMAC and Turbo PMAC controllers.) In my desktop test system, I have it set to 0.05 msec (50 microseconds). We have several customers that run 10,000 programmed move blocks per second for extended periods of time. As Brad explained above, having programmed move block times shorter than the segmentation time does not cause failure, but the segmentation process will smooth over the trajectory, so you cannot expect the commanded trajectory to have the detail of such a short programmed move.

mbalentine: From what I can divine, few EtherCAT drive manufacturers are making higher update rates a priority. I do expect a few to push this functionality, if only to differentiate themselves from the others. Some, but not all, EtherCAT drives provide a work-around to extend the +/-1000 (~11-bit) standard resolution to 16 bits. Unfortunately, each work-around is different. Delta Tau provides two different EtherCAT "stacks". The Etherlab stack is very efficient in operation, but not feature-rich and with limited setup tools. The Acontis stack is full-featured and has pretty comprehensive setup tools, but the additional overhead of the extended functionality limits its operational efficiency. You should not expect to operate faster than 4 kHz with the Acontis stack on "hardware PMACs", even for a limited number of axes. The Omron IPC, with its multi-core i7 processor, can do 6 - 8 axes at 8 kHz. With the streamlined Etherlab stack, you can do 8 kHz update on many axes on our "hardware PMACs". This stack is not available on the uPowerPMAC (CK3E) or IPC.

Running an EtherCAT drive in torque mode at 4 kHz, given the transport delays, gives approximately equivalent performance to running a "local" analog-input torque-mode drive at 2 kHz -- good solid performance for most applications, but not for super-precision applications. Few EtherCAT drives can use new torque commands at 8 kHz. Some will accept the commands at 8 kHz, but only use every second command. You need to check with the drive supplier.

Looking at your drawing, the overall tool diameter is the distance along the line you have labeled XZ'. You describe this diameter as 66mm, so the tool radius from the axis of rotation to the outside of the tool is 33mm along this line. The little circles (which I presume are the inserts) shown at the outside ends of this line have what our 3D compensation calls the cut radius. Using the same scaling that gives us 33mm tool radius, I measure on my screen a cut radius of only about 3 or 4mm. Of course, I am assuming your very nice drawing is accurately to scale.

3D cutter radius compensation, as with 2D cutter radius compensation, must be programmed in XYZ Cartesian coordinates. If your mechanism does not have a 1-to-1 match of actuators to tool-tip coordinates, then you must use kinematic conversions. You list a 33mm overall tool radius (66mm diameter) and a 12mm "corner radius". This does not correspond at all well with the drawings of your tool head. The "corner radius" looks much smaller with respect to the overall tool radius.

When you use a PLC program for commands like "dtogread", the values are placed in local D variables for that PLC. If you want to access these values from outside of that PLC program, you must use the full data structure -- e.g. Plc[17].Ldata.D[32]

Usually these applications are done with a simple looping structure in the motion program. Each time through the loop, a new intermediate destination position is computed for each axis and a short move to this intermediate destination is commanded. It would look something like this: abs spline(MyMoveTime) while(Tracking) { Xdest=... Ydest=... Zdest=... X(Xdest) Y(Ydest) Z(Zdest) }

Your question really comes down to: Where is it best to close the velocity loop? A velocity loop must be closed for stable operation. If the controller is in torque mode, the velocity loop must be closed in the control (using the velocity feedback gains). If the controller is in velocity mode, the velocity loop must be closed in the drive. The velocity loop, like the position loop, must be tuned with the load attached, because its performance is affected by factors such as load inertia, coupling compliance, and friction. If you close the loop in the drive, you must deal with both the actual performance of the loop and the setup tools to tune the loop for the drive. In my experience, these tools range from excellent to awful. In applications that close the position loop, almost everyone puts the controller in torque mode, because few people want to first tune the drive's velocity loop, then the controller's position loop in completely separate steps. Very seldom is there a countervailing advantage that makes this worth it. For axes where you care about velocity control, but not position control, there are a few things to consider. When I discuss this issue with users, I ask them what response they want after a heavier load torque temporarily slows the axis below commanded velocity. If you want the axis to catch up in position, which requires temporarily going faster than commanded, then you want full position control. If you only want the axis to catch up in velocity, then you want velocity control. I think in your spindle motor case, you want the second case. In this case, what we advise is to initially tune the motor as if it were a full position control axis, but without integral gain. Use velocity feedforward to minimize the following error. To convert the motor to velocity control, set Motor[x].MaxPosErr to 0 to disable the position loop. The velocity feedforward term will provide the main command to move the motor now. Also set Motor[x].FatalFeLimit to 0 to disable trips on fatal following error. Note that these settings are appropriate whether you are commanding the drive in torque or velocity mode. So the answer to your question: "Are there any reasons NOT to be in Torque mode when running the axis at a constant velocity?" is no -- or at least no NEW reasons for this compared to full position control.

"Why did you choose u.user:4096 as your starting point?" No particular reason. I just did not want to imply that you had to start at offset 0, and many people use lower locations for other purposes. Registers in the user buffer can have M-variable pointers assigned easily to individual bits. This provided the closest working alternative to what you provided.

PMAC P-variables are floating-point variables, so the locations of individual bit values "float" (are not fixed), and you cannot assign pointer variables to individual bits. First, you will want to define fixed-point M-variables to user buffer registers. For example: M4100->u.user:4096; // Sys.udata[1024] M4101->u.user:4100; // Sys.udata[1025] M4102->u.user:4104; // Sys.udata[1026] M4103->u.user:4108; // Sys.udata[1027] Then you can use: cmd"ModbusRegisterRead 0,0,4,M4100" Now, you can define other M-variables to individual bits of these fixed-point registers. ptr Input01->u.user:4096.0.1; // Bit 0 of Sys.udata[1024] ptr Input02->u.user:4096.1.1; // Bit 1 of Sys.udata[1024] ptr Input03->u.user:4096.2.1; // Bit 2 of Sys.udata[1024] ptr Input04->u.user:4096.3.1; // Bit 3 of Sys.udata[1024] Note that the starting bit number comes before the bit width in these definitions.

I think your biggest issue is that you only have feedback on your linear load, so it is a very indirect measurement of what your motor is doing. You have brought all the imperfections of the coupling and rotary/linear conversion "inside" your feedback loop, which likely makes it very poorly behaved. If there is any backlash in the mechanism, you get "lost motion" of the motor that your linear scale does not detect. This type of system is very difficult to tune well (and would be even with a servo motor if you only had load feedback). Some people with this type of system get better results closing the loop on the simulated feedback, and using the linear scale just for corrections

Yes, ideally the manual should say: "Increase the magnitudes of these values by increments of 100..." The idea behind this method is to force the motor to the zero point in its commutation cycle by temporarily running it like a stepper motor with equal and opposite values in the two phases. (This is very much like the "stepper motor" phasing search move that most people with only incremental encoders use every time they power up.) When it settles here, the sensor value can be read and used to compute the Ixx75 offset parameter. This procedure only needs to be done once, on assembly of the machine. In normal operation, with Ixx81 and Ixx91 set to read the absolute sensor on power-up, the sensor value will automatically be offset by the value you have in Ixx75 to get the commutation angle. This process is done with out any motion or subsequent correction. In other types of systems, users want to do a correction after the initial phasing. Hall commutation sensors only tell you where you are within 1/6 of a cycle (60deg). Other users don't trust the "stepper motor" or "guess" methods of phasing search moves to be accurate enough for optimal operation, so they do corrections.

The HMZ command causes no hardware functions. It simply changes the value of the motor commanded software position register (suggested Mxx61) to zero, and the value of the motor actual software position register (suggested Mxx62) to (CommandPos - FollowingError). As Greg said, it does nothing to the hardware encoder position registers (like Mxx01) in the ASIC.