curtwilson

A few details: When there is no "Gate" to produce a servo clock input to the processor and Sys.CpuTimerIntr=1 (which is the default for no Gates), Sys.ServoPeriod actually determines the servo update period, rather than just telling the interpolation algorithms the period established by the source ASIC. In any Power PMAC, the phase period is the same as the servo period when Sys.CpuTimerIntr = 1. In the uPowerPMAC (CK3E), the phase routine is a simple shell to pass through to the servo routines -- no "real" code executes in it, not even to increment Sys.PhaseCount. In any Power PMAC, the only function of Sys.PhaseOverServoPeriod is for motors whose servo loop is closed in the phase interrupt, to tell the "sub-interpolation" algorithm in the phase routine what fraction of the servo period to use in the sub-interpolation of a single phase cycle. It does not have any effect on the physical time for either the phase or servo period in any Power PMAC In the uPowerPMAC, it cannot have any use. In your uPowerPMAC (CK3E), if the value of Sys.ServoPeriod is 0.442 (at power-on/reset), the servo update period will be 442 usec (2.26kHz frequency), regardless of the setting of Sys.PhaseOverServoPeriod. But remember that the period/frequency used when the CPU is generating its own interrupt is determined only at power-on/reset, so if you change the setting of Sys.ServoPeriod, the new value will only take effect after a save and reset. Internally, we called this product the uEtherlite while it was under development. Marketing decided to sell it under the uPowerPMAC name.

Note that to access a bit associated with an individual pin, you can use the format acc65e[x].datareg[y].z where z = 0 to 7 for the 8 bits in the register. For example, to access pin 12 of the input connector, you would use: acc65E[0].datareg[1].3 In your PPMAC project you can assign this a meaningful variable name. e.g.: ptr InterlockSwitch->acc65e[0].datareg[1].3

Latch position (M103) is a hardware position register in the ASIC that is relative to power-on position. It is in units of full counts. Actual position (M162) a software position register in RAM that is relative to the latest motor zero position (power-on, home, or homez). It is in units of 1/(I108*32) counts. HMZ does not not clear the latch position. It sets the present motor command position to zero, with the motor actual position differing from zero only by the present following error (which is zero by definition if the loop is open).

You have an ACC-24E2x axis card, not an ACC-24E3 axis card, so you do NOT have a "Gate3" ASIC. The ASIC in your card can only provide a maximum 50% on-time duty cycle with its PFM circuit, so that is not an option. It is possible to use a PWM output from one of your ASIC channels, but if you set your PWM frequency to 1 kHz, your maximum phase and servo update frequencies will be 2 kHz, which is probably too slow. So I think your best option is the "fast software" option. To get your 5% resolution, you need to run your software at 20 kHz. This is done by the proper settings of Gate1.PwmPeriod and Gate1.PhaseClockDiv to obtain a 20 kHz phase update frequency (50 usec period). Your servo update frequency is divided down from this using Gate1.ServoClockDiv. Once you have this set up, you should write a "custom phase" algorithm in C for Motor 0 to control the output (assuming you have no "real" Motor 0). It should only need to be about 5 or 6 lines long (assuming some other routine determines the desired duty cycle). Set Motor[0].PhaseCtrl to 1 to activate this.

The selection of feedrate axes only affects the time for the move, not the path. Nobody that is doing 5-axis control with PMAC has more than the 3 Cartesian axes as the feedrate axes. It simply makes no geometric sense to include the rotary axes. If you do, you are causing PMAC to add millimeters and degrees, which is nonsensical.

If you set Motor[x].Servo.MaxPosErr to 0.0, you effectively disable the position loop while keeping the velocity loop active. I think this will provide the performance you are looking for. With this strategy, you will probably want to keep the velocity feedforward term Motor[x].Servo.Kvff non-zero -- this will provide the main driving force for the motor. You are still technically commanding positions in this mode, but allowing errors to build up in the position loop. PPMAC is still monitoring position following error for possible error trips in this mode, so you will probably want to disable this by setting Motor[x].FatalFeLimit to 0.0. You will have to be careful in switching back from "velocity mode" to "position mode", as a very large position error can build up in velocity mode. You may want to use the "jog^0" command before you set MaxPosErr to a non-zero value -- this causes PPMAC to swallow up the following error by slewing the command position to the present actual position.

To do this in software, you would have to run your code at 20 kHz to have 5% resolution at 1 kHz. If you don't want to run your servo interrupt that fast, you might want to run your phase clock at 20 kHz (servo clock slower) and use a custom phase algorithm, probably for Motor 0. This algorithm would be very simple, and could take a commanded duty cycle from a lower-frequency routine. If you have a Gate3 chip, you could use the PFM output to do this. You would fix the channel's Pfm (frequency) command to get a 1 kHz output, then you would vary the channel's PfmWidth to vary the duty cycle. At the default Pfm clock frequency, you would vary PfmWidth from 0 to 3125 for 0% to 100%.

The units are a little abstract, but let's go through the process. We'll call Mxx75 "Iq" and Mxx76 "Id". The vector magnitude of the current in these "field coordinates" is the vector sum of these: Idq = sqrt(Iq^2 +Id^2) In a three-phase motor, this corresponds to a peak ADC current reading on a phase that is 1.15 (1/cos(30)) times larger. (For a 2-phase motor, no conversion is necessary.) For your particular amplifier, you must find out what the maximum phase current reading (which corresponds to a number of 32,768) is. Let's say your Idq is 10,000, so your peak ADC phase current reading is 11,500. On a Turbo Brick AC 5A/10A drive, the maximum phase current reading is 16.26A. So your peak phase amperage is I(peakphase) = 16.26A * (11,500 / 32,768) = 5.70A Now, generally people want to express current in a 3-phase motor as RMS, not peak, and as full motor current, not single phase current. To convert from peak to RMS, multiply by 1/sqrt(2) (0.707). To express as full motor current, multiply by 3/2 (1.5). So in our example, we get: I = 5.70A * 0.707 * 1.5 = 6.05A

When you set multiple axes as "feedrate axes" you are treating them as if they were geometrically perpendicular axes, all with the same units. This makes sense for X, Y, and Z linear axes. I don't think it makes sense when you include a rotary ( C ) axis. When you command multiple axes on the same line (e.g. X10 Z20 C30), they will all move synchronously, starting and stopping together. But what controls the speed? First, PPMAC computes the vector distance of the federate axes. In your example, if the move is incremental: VecDist = sqrt (DeltaX^2 + DeltaY^2 + DeltaC^2) = sqrt (10^2 + 20^2 + 30^2) = sqrt(1400) = 37.4 Note that it just uses your numbers -- it does not care what your units are, so it is your responsibility to use consistent units. Then it divides this distance by your specified federate. If you F5 (with time units of seconds), it would compute a move time of 7.5 seconds. Now it divides each axis distance by this time to get the axis speed. For your C axis, this is 30 / 7.5 = 4 units per second. It can compare this value to the motor's maximum speed limit. If you had a max speed of 2 units per second for the motor assigned to the C-axis, it would double the time for the move to 15 seconds so the C-axis motor did not go faster than 2. Note that the speeds of the other axes would be cut in half as well to maintain synchronization. Once this is set, it can use this speed and the TA/TS times to compute an acceleration value and compare this to the maximum acceleration value (from InvAmax) for the motor.

There is nothing to resolve. For a synchronous motor commutated by Turbo PMAC, unless or until the motor has been phased successfully, we do not permit closed loop operation. Without proper phasing, it is possible to get a dangerous runaway condition. This status is shown by a true "phasing error" status bit, which is automatically set for such a motor at power-on/reset. This has been so for Turbo PMAC ever since its introduction almost 20 years ago.

In your forward kinematic subroutine, use the conditional if (Ldata.Status & $40) This will be true if called from a motion program to execute the pmatch function. It will be false if called from an axis query command. Please see the examples in the User's Manual on Coordinate Systems for examples of how this is used.

The issue is in the pre-processor that is converting this to "raw" PPMAC code. It regards the first "return" statement as the end of this particular subroutine, and expects another "sub:" following it. PPMAC can take this structure in its raw code. The pre-processor will accept this syntax in a separate subprogram, because it understands that the subprogram extends until the "close" command. So this is another workaround. We are examining how to improve the pre-processor to allow this.

The segmentation time Isx13 should be set small enough that fine features in the trajectory are not smoothed over, but large enough that the processor can keep up with the computations. I suggest starting with a relatively large value, like 20 or 25 msec, then gradually reducing it until you get the feature definition in the trajectory you need. If you can't reduce the time enough to do this before something goes wrong (like run-time errors), contact our tech support for assistance.

Yes, the handwheel inputs can be used as masters for an electronic cam. Most people do this through our "external time base" feature (whose main limitation is that it is uni-directional -- the master must be counting up). If you "external frequency" is a single signal rather than quadrature, it should be wired in the the A input of the handwheel channel, and the decode set for pulse and direction: I6810 or I6820 set to 0 or 4, whichever causes the position to count up. You will need to add two new entries to the encoder conversion table (ECT). The first one will process the handwheel encoder input just as the feedback encoder inputs are processed. So the new entry is Method 0 with a source address of $78410 for the first handwheel, or $78418 for the second handwheel. The result of this entry is a "position" value for the input. The second entry is the "time base" entry, which uses the result of the first added entry to compute a frequency. For example, if the 1st 12 lines of the ECT are used (I8000 - I8011), you would add to use the first handwheel channel: I8012=$078410 ; 1/T extension of Handwheel 1 I8013=$40350D ; Time base frequency calculation using processed HW1 at $350D I8014= {time base scale factor} The frequency value will be in register X:$350F. This can be used as a time base master for a coordinate system by setting Isx93 for the coordinate system to $350F. The speed of execution of motion in the coordinate system will be proportional to the input frequency each servo cycle.

The ErrorStatus value you report shows that you have an illegal "leadout" move (or don't have one at all) to end your cutter radius compensation sequence. Please contact our tech support group directly to learn how to do this properly.

No, that's not what I was trying to communicate. When you program the path in Cartesian coordinates (e.g. X & Y), and use cutter radius compensation, PMAC will automatically offset the Cartesian path properly by the radius and direction you specify. Points on the already-offset path are then input to the inverse kinematic subroutine. The IK subroutine does NOT need to perform any offsetting, as this has already been done. It works the same way whether or not any offsets have been applied in Cartesian space.

To be clear -- to use cutter radius compensation, you must be programming in Cartesian coordinates. If your mechanism is polar, you must use our kinematic subroutines to convert the offset Cartesian tool-tip trajectory to the polar actuators. This occurs at a later step in the processing.

"Is there a tolerance value that determines when a complete circle is executed and when a small arc is executed? " Yes! Saved setup element Coord[x].MinArcLen -- scaled in radians -- is provided for just this reason. (In Turbo PMACs, this is Isx97.) You will want to increase this value from its default. You will need to consider what the shortest arc length you think anyone will want to program in your system. If you set it too big, there will be complaints that the machine did a "loop-the-loop".

Clopedandle: If you set both TA and TS to 0, there is no acceleration profile to compare to the limits, so InvAmax, InvDmax, and InvJmax are not effective. So the OP's setting of TA=1 was likely not arbitrary.

In the first chapter of the Software Reference Manual (recent versions), there is a long table "Reported Errors for Illegal Commands" which shows the error numbers (as positive values) and error strings for the various error types. When the commands are issued externally, the number and string are returned over the communications port. When the commands are issued internally, the error number (as a negative value) is put in Ldata.CmdStatus.

The most common real feedback is incremental encoders processed with timer-based "1/T" sub-count interpolation, which generally produces fractional values in the actual position. The most common virtual feedback is from pulse frequency outputs wrapped back into a counter, with NO sub-count interpolation (because that tends to cause continual dithering at rest).

If a floating-point value holds an exact integer value, Power PMAC will report it without any places past the decimal point. When you have a feedback device and processing that does not produce any sub-count or sub-LSB estimation, actual position values will always be integers. Similarly, actual velocity values in this case will simply be the difference of two integers, so integers themselves. Desired positions are always computed with floating-point math, so are much more likely to have fractional components in any given servo cycle. Of course, the position error (DesPos - ActPos) will have a fractional component if either source does.

From what I am able to deduce, "Slerp" (spherical linear interpolation) is equivalent in form to our circular interpolation algorithms. But you want to use this Slerp not on the X, Y, and Z axes, but on the quaternion that I believe you are using for orientation commands. Most people use the traditional A, B, and C axis names for their orientation commands. However, if you use the XX, YY, and ZZ axes, and put this secondary axis into "circular interpolation" mode (circle3 or circle4), you may be able to get the effect you desire. This can be done with the X, Y, and Z axis set in either linear or circle mode.

General purpose I/O on the Power Clipper is 5V CMOS, both for inputs and outputs -- bidirectional buffers are used. The intent for outputs is that people add whatever type of drivers they choose. The Clipper breakout board provides optically isolated outputs rated to 24V, sinking or sourcing by user wiring.

In the SW Reference Manual, under the description for the output register Gate3.Chan[j].Pfm, it gives the formula for the output frequency as: Fout = (Gate3.Chan[j].Pfm / 4,294,483,648) * Fpfmclk This treats the Pfm element as a full 32-bit register. The servo algorithm only considers the high 16 bits to be integer values, so the effective formula becomes: Fout = (ServoCmd / 65,536) * Fpfmclk With your PfmClock frequency of 3.125 MHz (3125 kHz), a servo command of 10,000 would produce: Fout = (10,000 / 65,536) * 3125 = 476.9 kHz This is exactly what my system produces in this setting. Note that a pulse width of 1.6 usec cannot support a frequency of 800 kHz, as it would always saturate by 667 kHz. I would set the PfmWidth to 2 for a 0.64 usec pulse width, which would be about 50% duty cycle at 800 kHz.