curtwilson

What is your setting for Sys.MaxMotors? The IDE status window will not let you go past (Sys.MaxMotors - 1).

What is your setting for Sys.MaxMotors? The IDE status window will not let you go past (Sys.MaxMotors - 1).

Because anti-noise filtering in the auto-correcting interpolator is performed by extreme oversampling and digital averaging, the analog filtering on the front end is a lot lighter. This means that the input bandwidth is a lot higher - high enough that we do not have a sinusoidal encoder that can exceed its capabilities.

Because anti-noise filtering in the auto-correcting interpolator is performed by extreme oversampling and digital averaging, the analog filtering on the front end is a lot lighter. This means that the input bandwidth is a lot higher - high enough that we do not have a sinusoidal encoder that can exceed its capabilities.

The Power Brick AC has the traditional two-level PWM amplifiers. The tri-level amplifiers require twice the number of power transistors, which makes fitting them into the brick package very challenging.

The Power Brick AC has the traditional two-level PWM amplifiers. The tri-level amplifiers require twice the number of power transistors, which makes fitting them into the brick package very challenging.

The motor and coordinate system fault status bits are designed to be latched until the motor is re-enabled (in case of a "kill" fault) or commanded to move again (in case of an "abort" fault). We do not have a "fault clear" function for these software status bits. If the motor was killed in a fault, as from an amplifier fault condition, you could issue a command line like "#1 out0 k" (or from a PLC program: "cout1:0 kill1"). This momentary enabling is enough to clear the status bit(s) -- provided that the amp fault input is no longer set -- but not enough to do anything physical to the motor. If the motor was aborted to a closed loop stop, a "j:0" zero-distance jog command could clear the fault bit -- again, provided that the condition that created the fault is no longer present.

The motor and coordinate system fault status bits are designed to be latched until the motor is re-enabled (in case of a "kill" fault) or commanded to move again (in case of an "abort" fault). We do not have a "fault clear" function for these software status bits. If the motor was killed in a fault, as from an amplifier fault condition, you could issue a command line like "#1 out0 k" (or from a PLC program: "cout1:0 kill1"). This momentary enabling is enough to clear the status bit(s) -- provided that the amp fault input is no longer set -- but not enough to do anything physical to the motor. If the motor was aborted to a closed loop stop, a "j:0" zero-distance jog command could clear the fault bit -- again, provided that the condition that created the fault is no longer present.

I would have suggested the same approach as Jeff did, which technically keeps the loop closed, but effectively disables it. Note that you cannot use our automatic brake control function for this, as that function operates only on true disabling and enabling of the motor. Our own "in-phase" PWM amplifiers yield no current ripple in the motor at zero command, and I believe that most 3-phase brushless motor amps are in-phase like this. (Many cheap brush motor and stepper motor drives use the simpler "anti-phase" PWM, which has a lot of current ripple at zero command.)

I would have suggested the same approach as Jeff did, which technically keeps the loop closed, but effectively disables it. Note that you cannot use our automatic brake control function for this, as that function operates only on true disabling and enabling of the motor. Our own "in-phase" PWM amplifiers yield no current ripple in the motor at zero command, and I believe that most 3-phase brushless motor amps are in-phase like this. (Many cheap brush motor and stepper motor drives use the simpler "anti-phase" PWM, which has a lot of current ripple at zero command.)

Can you tell if there is a deterministic relationship between the action of one axis and the disturbance of the other? If so, the best strategy is to characterize this relationship and create your own cross-coupled feedforward algorithm (usually in a PLCC 0) to put a counteracting torque offset in the other motor before there is a chance for the error to build up. But the first step is to attempt to characterize the relationships. Are the errors proportional to the other motor's acceleration? Velocity? Both? I would look in time domain first, but both time and frequency plots can be valuable. P.S. You do have some pretty big spikes at the AC line frequency and harmonics. I can't tell if these are causing real problems for you, but you may want to investigate this further.

Can you tell if there is a deterministic relationship between the action of one axis and the disturbance of the other? If so, the best strategy is to characterize this relationship and create your own cross-coupled feedforward algorithm (usually in a PLCC 0) to put a counteracting torque offset in the other motor before there is a chance for the error to build up. But the first step is to attempt to characterize the relationships. Are the errors proportional to the other motor's acceleration? Velocity? Both? I would look in time domain first, but both time and frequency plots can be valuable. P.S. You do have some pretty big spikes at the AC line frequency and harmonics. I can't tell if these are causing real problems for you, but you may want to investigate this further.

Looking at your test program, the key variable for determining the power dissipated is not in the program -- the acceleration parameter(s). To test what level of continuous current your motor can tolerate, I would do repeated moves that are always accelerating and decelerating at a constant rate: TA=TM, TS=0, and only a momentary stop between moves (DWELL 0).

Looking at your test program, the key variable for determining the power dissipated is not in the program -- the acceleration parameter(s). To test what level of continuous current your motor can tolerate, I would do repeated moves that are always accelerating and decelerating at a constant rate: TA=TM, TS=0, and only a momentary stop between moves (DWELL 0).

If it hits a limit during the phasing search move, the search will fail automatically, because it cannot be sure that the motion of the search is a valid result of the excitation.

If it hits a limit during the phasing search move, the search will fail automatically, because it cannot be sure that the motion of the search is a valid result of the excitation.

The intent of the I2T feature is to guard against overheating your hardware by generating heat faster than it can be dissipated. PMAC's I2T feature is mainly intended to protect the motor, as most drives have their own internal protection of this type. Implicitly, it uses a simple and generic thermal model. The I2tSet parameter represents a current level that you can run at continuously without overheating. That is, running at this current level continuously, the motor should reach a reasonable steady-state temperature. If you have a "bad" (overly conservative) setting, it is more likely to be this I2tSet parameter than the I2tTrip limit you are considering. If you just increase I2tTrip, repeating your sequence indefinitely will eventually cause the running I2tSum value to increase enough that you get a trip. To nail this down properly, you will need to see how the motor temperature changes under different conditions. Ideally, this would be with thermocouple measurement, but possible an IR thermometer could be used as well.

The intent of the I2T feature is to guard against overheating your hardware by generating heat faster than it can be dissipated. PMAC's I2T feature is mainly intended to protect the motor, as most drives have their own internal protection of this type. Implicitly, it uses a simple and generic thermal model. The I2tSet parameter represents a current level that you can run at continuously without overheating. That is, running at this current level continuously, the motor should reach a reasonable steady-state temperature. If you have a "bad" (overly conservative) setting, it is more likely to be this I2tSet parameter than the I2tTrip limit you are considering. If you just increase I2tTrip, repeating your sequence indefinitely will eventually cause the running I2tSum value to increase enough that you get a trip. To nail this down properly, you will need to see how the motor temperature changes under different conditions. Ideally, this would be with thermocouple measurement, but possible an IR thermometer could be used as well.

Is this a phasing read of an absolute sensor, or a phasing search move? If you are doing a phasing search move, you will probably want to make sure you are physically moved off the limit before you attempt the actual phasing search. Otherwise you cannot be sure the search would be successful. You would move off by commanding an open-loop zero output (cout:0) then using IaBias and IbBias to "step" the motor out of the limit.

Is this a phasing read of an absolute sensor, or a phasing search move? If you are doing a phasing search move, you will probably want to make sure you are physically moved off the limit before you attempt the actual phasing search. Otherwise you cannot be sure the search would be successful. You would move off by commanding an open-loop zero output (cout:0) then using IaBias and IbBias to "step" the motor out of the limit.

You can monitor the status element Motor[x].I2tSum, which contains the instantaneous value of the time-integrated value above the continuous limit. When this exceeds I2tTrip, you get the fault. I suspect you will find that it is slowly increasing over the minutes. This limit may well be doing exactly what it is supposed to do -- it is common for these faults to appear after significant time.

You can monitor the status element Motor[x].I2tSum, which contains the instantaneous value of the time-integrated value above the continuous limit. When this exceeds I2tTrip, you get the fault. I suspect you will find that it is slowly increasing over the minutes. This limit may well be doing exactly what it is supposed to do -- it is common for these faults to appear after significant time.

The soft overtravel limits work in several different ways at different points in the process, and it is important to understand these different modes. At move calculation time, a move's final destination can be checked against the soft limits, and if past a limit, the destination changed to equal the limit. This is not necessarily an error, but if this happens, the motor status bit SoftLimit is set (at the start of the move) and the SoftLimitDir status bit indicates which limit caused the destination to be changed. There are also checks done at move execution time. If the instantaneous commanded position goes past a soft limit, motion will be aborted and the appropriate error bit (SoftPlusLimit or SoftMinusLimit) will be set. The limits at execution time are (MaxPos + SoftLimitOffset) and (MinPos - SoftLimitOffset). If SoftLimitOffset is at its default value of 0, a move altered at calculation time to stop at the soft limit will not trip on the error and set the bit when it gets there, because some do not want this to be an error. If you set SoftLimitOffset to a small negative value, it will trip on the error and set the bit when it reaches the end. If you want this behavior, set SoftLimitOffset to a small negative value, such as -1 (feedback count).

The soft overtravel limits work in several different ways at different points in the process, and it is important to understand these different modes. At move calculation time, a move's final destination can be checked against the soft limits, and if past a limit, the destination changed to equal the limit. This is not necessarily an error, but if this happens, the motor status bit SoftLimit is set (at the start of the move) and the SoftLimitDir status bit indicates which limit caused the destination to be changed. There are also checks done at move execution time. If the instantaneous commanded position goes past a soft limit, motion will be aborted and the appropriate error bit (SoftPlusLimit or SoftMinusLimit) will be set. The limits at execution time are (MaxPos + SoftLimitOffset) and (MinPos - SoftLimitOffset). If SoftLimitOffset is at its default value of 0, a move altered at calculation time to stop at the soft limit will not trip on the error and set the bit when it gets there, because some do not want this to be an error. If you set SoftLimitOffset to a small negative value, it will trip on the error and set the bit when it reaches the end. If you want this behavior, set SoftLimitOffset to a small negative value, such as -1 (feedback count).

Hmmm... I tested it on my system before I responded, and it worked as I reported. I do have newer firmware. In the V1.6 release, there were some refinements in the interaction between time base values and abort decelerations, including the new parameter Coord[x].AbortTimeBase. It looks like this issue was handled as well in the release. You would need to update your firmware to fix this.