curtwilson

Try increasing the value of Coord[x].GoBack. This parameter is designed to prevent indefinite loops in the program from causing a situation where the next move can't be computed before it is needed to blend from the current move. But you want to be able to jump back in the program twice as you exit the inner loop.

In the ASIC on the ACC-24E3, the act of setting CaptCtrl to 0 immediately sets the capture flag (the PosCapt element for the channel). At the beginning of the homing search move, the processor automatically reads the captured position register to clear this flag, then starts the move and looks for the flag to be set again. But there is nothing to set the flag. We will need to clarify this in the manual better. It is subtly different from the ASIC in the ACC-24E2, where the flag is level-triggered, not edge-triggered To do what you want, I would suggest setting Motor[x].CaptureMode to 2 to trigger on exceeding the warning following error limit, and setting Motor[x].WarnFeLimit to a tiny number (e.g. 0.001 counts). This will cause the move to finish without any perceptible motion.

I am not having any trouble running moves down to 0.15 msec in this configuration, and we do have people using block rates like this in the field. I am trying to figure out what settings you might have that are limiting your block rates. If you look at the IDE's task manager, what kinds of percentage times does the processor have in phase, servo, and RTI at 3 msec block rates?

You have the ability right now to use your symbolic name for a variable in the ide terminal/watch windows and OTHER C applications with either method of variable declaration: global a or #define a P1 You do not need to assign a pointer variable to do this.

The only difference between the two methods of declaring variable names is who decides which underlying variable is assigned to your symbolic name -- you, or the project manager. In both cases, the matchup is stored in the symbol table inside Power PMAC and so is available to any task that can access the table -- typically through "gpascii -2" (The -2 gives it access to the table.) I still haven't figured out what advantage you get from assigning a pointer variable to a global variable.

I'm not sure I understand why you want to do what you are trying to do, but you can do it easily with the other supported method of variable declaration, i.e.: #define a P1 #define b P2 ptr var->Sys.P[1] The declarations like "global a" are for users who have no need to know which underlying variable is being used.

We have not been able to duplicate this problem here at the factory. In this configuration, the ASIC clock directions and any clock buffers always come up correctly as specified on any re-initialization. Still investigating.

The A+, A-, B+, and B- inputs do go to the XOR encoder-loss circuitry in the ASIC on the analog encoder board, as they do on the digital board. However, there are not pullup resistors to pull the lines high if not driven from the encoder. Instead, a termination resistor pulls the + and - pairs together when not driven. This should force them to the same state and trigger the loss-detection circuit, but we have not done real testing of this. It should be pretty simple to verify.

Raphael: "I don't understand why, but I have a syntax error on the declaration of the pointer... volatile GateIoStruct *MyFirstGateIoIC; " Try it with a capital "O" in "GateIOStruct". It looks like there was a transcription error somewhere.

We use the same differential line receivers on our analog encoder boards as we do on our digital encoder boards, so we can accept digital encoders properly on them. The pullup/down/termination loading is somewhat different, but for an encoder with reasonable drive capability, this should not matter. If it is a single-ended encoder, you will need to tie the "-" inputs to 2.5V yourself, as this is not done internally on the analog board.

Your general sense is pretty good. There really are not specific formulas for determining optimal servo update rates. In general, higher servo update rates can provide higher performance, but you will hit a point of diminishing returns. (Note, however, that if you have low position resolution or low-frequency resonances, higher servo update rates can actually harm performance.) The point of diminishing returns hits the "negligible improvement" point sooner for your "heavier" (i.e. low bandwidth) systems than it does for higher bandwidth systems. Very accurate systems generally require higher bandwidth to correct errors more quickly, and therefore can justify higher servo update rates. One of my rules of thumb is that "zero friction" systems (as with air bearings) require about twice the servo update rate of similarly sized systems with mechanical friction, because it is so easy for the system to coast past the set point on a small servo correction. Ultimately, you need to get a feel for the effect on real systems of interest. Tune a system as tightly as you can at 2 kHz, then repeat the operation at 4 kHz, and 8kHz (etc.) and see how much improvement you get.

I'm having trouble figuring out what this is for.If I understand correctly, the whole point of this subroutine is to set M199 synchronously with the start of execution of the next move in the part program. I get this just by using M199==1. The reason for the "==" is to delay the actual assignment even if the operation had to be calculated ahead of time. I can't create a problem even if I add the two zero-distance moves. What happens if you replace them with DWELL commands?

In your first configuration, you can bring out pulse and direction either on the "Phase D" pins of the PWM amplifier connector, or on the T/U/V/W pins of the feedback board. To do the second, you must set Acc24E3.Chan[j].OutFlagD to 1 to enable the output buffers. (Note that this flag value is not saved, so you must set it after every power-on/reset. In the second configuration, you can also bring these signals out on the T/U/V/W pins of the feedback board by setting OutFlagD to 1. In all of these cases, the value in Acc24E3.Chan[j].Pfm determines the frequency and direction of the output. Bit 3 (value 8) of Acc24E3.Chan[j].OutputMode must be set to 1 to select PFM, not PWM, for this register.

The thing I am most concerned about in your inverse kinematic routine is your IF branch. You are checking to see if either DeltaX or DeltaY is greater than a threshold distance before you compute the arctangent angle. I am worried both that your threshold may be too large (0.01 seems small, but that is 5 counts in your system, and I could easily see the first 10-msec segment at the start of S-curve acceleration being shorter than that) and that you have no ELSE branch to decide what to do if the threshold is not met. In the first move of a program, the angle command if the threshold is not met is effectively random. On a separate subject, if I were doing this application, I would always process the axis data through the kinematic routines, but with a logic flag that would let me choose between direct programming of the C axis (which you would use in RAPID mode) and arctangent calculation of the C axis (which you would use in LINEAR and CIRCLE modes). I think this would simplify your application greatly.

No, there is not an automatic function to do this. It would be very hard to devise a generalized scheme for this (e.g. when does it start, stop, and clear the calculations). As an analogy, I find the "average gas mileage" reading on my car to be useless, because I have no idea over what time span it operates. Also, very few people request this functionality, so even the overhead to decide whether or not to calculate this on an every-servo-cycle basis would not be worth it.

A couple of notes on this: The syntax description for this command is {axis}={constant}, not {axis}={data}. The {data} specifier indicates the choice of a constant without parentheses, or a mathematical expression inside parentheses. But if the description shows "{constant}", expressions are not supported in the syntax (as with most on-line commands). As Steve says, you can set the position-bias register directly (which is what the command affects). Remember that if you do this, you must execute a "PMATCH" command for the coordinate system before the next programmed move in the coordinate system. (PMATCH is automatically executed on a Run or Step command.) Yes, the Power PMAC is more flexible in this regard.

As I understand your process, you execute a RAPID move to the XY position and C-angle orientation for your starting point and tangent angle on the path. For this move, the C-angle is directly programmed, and not calculated as an arctangent. Then, with the kinematics algorithms for calculating the C-angle to be tangent to the path enabled, you start a motion program to command the XY path. The first thing that happens is that the forward kinematic algorithm is executed to calculate the starting axis positions (X, Y, and C) from the motor positions. Then, as it calculates the first programmed move, it computes the axis positions for the first segment (Isx13 time) for this move, and passes these axis positions to the inverse kinematic algorithm. It is quite common early in the development of a project for the user's forward and inverse kinematic algorithms not to be perfect inverses of each other everywhere in the workspace. If they do not match each other exactly, there will be a sudden jump at the beginning of the first move. The kinematics for tangent control of a rotary axis are especially tricky to start right, because the inverse kinematics derive three motor positions from two axis positions, which cannot be a directly invertible calculation. Our modulo operation on the PMAC has been stable for over 20 years now, without any record of complaint for accuracy, especially not one big enough to cause a noticeable jump. I would be much more concerned as to whether to the commanded end angle of the RAPID move really matches the starting tangent angle of the first path move in all cases. If it does not, you will get the jump.

The P and Q variables in PMAC are 48 bit floating-point values with a 36-bit mantissa and 12-bit exponent. The motor target position (and other position) registers are 48-bit fixed-point values, and with typical scale factors, have about 36 bits of whole-count resolution and 12 bits of fractional resolution. The 36-bit mantissa in the P and Q variables can represent count values up to 64 trillion with no loss of whole-count resolution. Very few kinematic applications have position values that get anywhere near this size. (Typically, the only types of motors that may get to this type of range are spindles or webs that run continuously, and they usually are not involved in kinematic calculations.) The conversion between the floating-point Pn motor position value you work with in your kinematics routine and the fixed-point motor target position register is done automatically by PMAC. Other than using the best possible math in your kinematics routines, there is nothing special to be done for optimal numeric resolution. Any errors from the finite resolution of these variables will be trivial (and very far below other sources of error in your application) in virtually all applications.

Jeff - Your surmise is correct that we are running a 12V fan off of a 10V net supply because that is what is available. There is not good availability of 15V fans, and running a 12V fan at 15V could lead to early failure.

Before you run your program, issue a DEFINE CCBUF 8 command. This will permit the buffering of up to 8 moves so a proper intersection can be found even when there are moves in between with no distance in the plane of compensation. Please read the description of the DEFINE CCBUF command in the program command chapter of the Software Reference Manual for more details.

We cannot robustly reset the encoder counter on homing, because in between the time we would decide to do so and the time the resetting would actually occur, one or more counts could come in, destroying the accuracy of the re-referencing. For this reason, we instead store the exact count captured by the homing search move, so this can be added into the desired motor count value of your event to get the hardware encoder count value. The register where this offset is stored is Y:$0000CE for Motor 1, Y:$00014E for Motor 2, etc., and the suggested M-variable is Mxx73 for Motor xx. Sample equations for using this value are given in the "Synchronizing Turbo PMAC to External Events" chapter of the Users Manual.

I asked yesterday if you had defined a buffer to hold enough moves to get through any moves that are zero-distance in the plane of compensation. The cutter comp (kerf) algorithm must be able to compute the in-plane move after all of these moves before it even starts to execute the in-plane move before these zero-distance moves. Otherwise, it cannot calculate the compensated intersection point properly. Have you used the DEFINE CCBUF command and made sure the buffer structure was saved so it is ready to be used when you need it?

There is only one Isx86 alternate feedrate value per coordinate system, so what you want cannot be done directly. However, for these rotary-axis-only moves, you could go into RAPID mode, where each motor's speed is controlled separately. And if you want, you could specify the use of the jog speed parameter Ixx22 for these moves rather than the default maximum speed parameter Ixx16. Or, if lookahead is active, the speed of LINEAR mode moves for these axes is limited by the underlying Ixx16 motor maximum speed parameters.

There are several things to look at, and Jeff has pointed some out. First, assuming your "vector feedrate axes" are the default set of (X, Y, Z), the commanded speed of your C-axis move is not governed by your F-code value (which is a linear speed), but rather by Isx86 (which can be a rotary speed). Have you checked your setting of Isx86? Second, if lookahead is active, you can have the speed limited by Ixx16 for the motor assigned to the C-axis. The next issue is the the cutter comp (kerf) algorithm must be able to buffer and look through the C-axis move to properly compute the compensated intersection point between the incoming XY move and the outgoing XY move. Have you set up a buffer for this type of move with the DEFINE CCBUF command?

On the MACRO side, there are several advantages: First, the fiber version provides complete noise immunity for the transmission between stations. A lot of people really value this, particularly for very large systems, so they just do not have to worry about shielding, etc. Second, the protocol is very simple, so there is less detail to learn during the implementation. Third, it has been around much longer -- people were putting MACRO systems into play as far back as 1994. On the EtherCAT side, there are more vendors providing components for this network. More types of communication can be done over EtherCAT with many of the devices (the flip side of it being more complex). For both networks, you are trading hardware complexity for software complexity. That is, your wiring will become simpler, but your algorithms will become more complex. You must be sure you can manage the software complexity in development, operation, and diagnostics for the trade-off to be a good one.