curtwilson

If you are trying to jog a piezomotor (as in your other question), and you want your jogging units to be your user units, just assign the motor to an axis with an axis scale factor that creates the axis units that you want. Then you can use the coordinate system axis jog ribbon, which uses the axis user units. Curt

Dave: 1. Gate1[8].Chan[0].PhaseCapt is the raw count value latched every phase clock cycle, as close to the running counter as the processor can get. This register is at offset $608024 (not $608004) in the I/O space. The chapter on I/O register offsets does show this as offset $024 from the IC base address. A technique you can use to find the address of a register like this without the manual: First, query the (absolute) address of this register -- Gate1[8].Chan[0].PhaseCapt.a Then, query the base address of this space -- Sys.piom Subtract the second value from the first, and you get your offset in I/O space. 2. As a data structure element, it is treated as an unsigned 32-bit value. You can treat it as a signed value by using the pointer definition you have suggested (with the correct address offset, of course), with the "i" instead of "u" format. 3. Yes, you have found the "counter reset" control bit. We have not documented in the manual to date because it is potentially very dangerous when used on a feedback or master encoder. Remember that the AmpEna output bit in the same register must be 0 for the resetting function to work. The name of this single-bit element is "PosClear" (not documented anywhere, so far). This is a "use at your own risk" function; we would prefer you to just use a software offset value for an effective zeroing. Curt

There's not much to it. The best place to start is the training slides chapter on shared memory (which you can access from this forum), then (if necessary) to the software reference manual for specific commands to set up access. You are just using pointers or arrays to get at specific registers in the buffer.

I think the only real change here is that you will be passing information through Power PMAC's "user shared memory buffer" rather than DPRAM. The "USHM" is in Power PMAC's main memory, which only has one physical hardware port, but in software, you can use it in the same manner as you used DPRAM in Turbo PMAC. You host computer will dump the move information into registers in USHM, and the Power PMAC will "handshake" this in other registers in USHM. Logically, it looks to me like the operation will be the same.

Tuomo: It is important to understand the difference between the instantaneous trajectory commanded acceleration value in memory (which we compute to 96 bits!) and the commanded torque value we output and the drive accepts. While the acceleration is an important component of that value, it must respond to many other affects -- cutting loads, friction, gravity loads, vibration, etc. Remmeber that we are recalculating this command thousands of times per second, and your mechanical system likely has a position bandwidth of under 50 Hz, so the servo essentially "dithers" the output for for an effectively higher resolution for tracking acceleration. 14-bit resolution is sufficient for all but the highest-resolution (e.g. sub micrometer) systems. People have done very high-performance systems in analog torque mode this way. With the ACC-51E, you can select with jumpers whether to use the 102-ohm termination resistors or not. The best solution is probably what Jeff suggests above, but you may want to experiment with direct connection techniques. In any configuration, you will want to look at the signals carefully with a scope. The dual-feedback technique itself is the best solution to backlash and quadrant error (ballbar test) problems. As soon as you close the outer position loop with load feedback, there is no point in using our backlash compensation algorithms, which are intended to apply a correction to what the motor sensor is reporting. Minimizing the dynamic errors in crossing a quadrant boundaries is really an issue of optimizing the tuning.

Hello Tuomo, You should be able to meet your goals with some care. Many people have done comparable systems successfully. The UMAC's analog outputs have 18-bit resolution, which is more than enough. They will be at least as fast as the serial digital communications of the Sinumerik. Degradation of the signal from noise is a potential issue, but it is manageable with standard techniques, and typically this will not be the most noise-sensitive signal. You must worry most about the 1Vpp signals from the sinusoidal encoders. The PWM signals on the power cables from the drive to the motor can inject significant noise into these signals if you are not careful. We recommend, as Heidenhain does, double shielding of the encoder cables, with the inner shield tied to signal ground, and the outer shield tied to chassis ground. The motor cable should be well shielded as well. The motor cables and encoder cables should be kept as separated as possible. You may well need to install chokes on the motor cable leads to "soften" the edges of the PWM signals. Proper grounding is essential. Ground loops can destroy signal quality. Our sine encoder inputs are high impedance, and if the Simodrive's are as well, double wiring should be OK, but you have to make sure that both circuits are at basically the same reference voltage. It is easy to experiment with different servo update rates. I would try both 4 and 8 kHz, and see if the performance at 8 kHz is enough to justify the extra processor time. Good luck! Curt

John: The forward kinematic routine is really useful only when at least some motors in the coordinate system are defined as inverse kinematic axes (#x->I). Otherwise, Power PMAC can just mathematically invert the axis-definition equations. With inverse kinematic equations, Power PMAC has no automatic way of knowing which axes are being used. This is what the "KinAxisUsed" (D0) variable is for.

John: If there is a forward kinematic routine for a coordinate system, Power PMAC will automatically use it for the position matching (pmatch) functionality that computes the starting axis position(s) from the motor positions. This is true even if the motors are assigned to axes with axis definition statements instead of being declared as inverse kinematic axes. By setting the "KinAxisUsed" variable (D0) to 0, you are telling Power PMAC not to pick up any axis positions from the routine. In doing this, you are effectively completely disabling the "pmatch" function, so the motion program has absolutely no idea what the starting axis position for the move is, rendering its motion calculations nonsensical.

John: D0 (for which the variable name macro is "KinAxisUsed") tells Power PMAC which axis positions you have computed in your forward kinematic routine. It will pick up the axis value(s) you have computed from the appropriate variable(s) and use them as the axis starting position(s) for the first move. By setting D0 to 0, you are telling Power PMAC not to pick up any positions, thus rendering your routine completely useless, so its intended "position matching" function is not performed, and the first move will used the wrong starting position. This looks like the source of your problem. You need to set the appropriate bits of D0 to 1 for each axis in the coordinate system. For instance, if you have calculated X, Y, and Z positions, you should set bits 6, 7, and 8 to 1 for a value of $1C0.

Is your forward kinematic routine a proper mathematical inverse of your axis definition? If you eliminate the forward kinematic routine ("&1 open forward close") so that Power PMAC automatically inverts the axis definition equation to do the pmatch function, does the problem go away?

We have not been able to duplicate this here. Some questions: What move mode are you in? Rapid? Linear? Does this occur with no lookahead buffer defined? Do you have a forward kinematic routine for the coordinate system? Does the problem go away if you command "pmatch" before the move? (e.g. &1 cpx pmatch inc X100000)

Version 1.2 of the Power PMAC firmware, released in Jan 2011, has 2 new status elements that make it easier for the user to determine the status of motion program operation. Coord[x].ProgRunning is 1 if the motion program and/or moves resulting from the program are presently executing. It is 1 even in "feed hold" (H) mode, because execution is still active, but it thinks that no time is elapsing. Coord[x].ProgActive is 1 if the motion program is running, or suspended in a way that execution can resume from that point (as with an S or Q command). These elements are "function" elements, computed only on request from several status bits, and so are not directly accessible from C programs.

There typically is no one single event that causes a watchdog trip. It is often an accumulation of too many (individually benign) tasks at a certain priority level, or a bad setting of a parameter. (For example, the best way to force a watchdog timer trip for test purposes is to set Sys.RtIntPeriod to a very large value.)

Presuming it is a "soft" watchdog trip, status element Sys.WDTFault is set to 1 if the background operations failed to execute in time. It is set to 2 if the foreground (interrupt) elements failed to execute in time. Saved setup elements Sys.WDTReset and Sys.BgWDTReset allow you to specify what "in time" is. A "hard" watchdog trip shuts down the processor completely, so does not permit the monitoring of a status element value.

Tuomo: Yes, the UMAC CPU card with the PC/104 interface and DPRAM is the best configuration for fast communications. I think with the large internal memory of the 160 MHz processor, you will have enough to do a good NC application. You will not gain that much memory by going to the larger external memory (because there is not the mapping to support all of the large internal memory and large external memory). The additional memory is about an $800 additional cost. A 1.8GHz PC processor should easily be fast enough to stream the 1000 blocks per second that you want. While PC/104-Plus is "supposed to be" backward-compatible with the original PC/104, our experience is that this is not always true.

John: Technically, Motor[x].ServoCtrl is "control", not "status", which is why it is not in a status word. The bits in the status word are write-protected, which ServoCtrl of course cannot be.

Do you have any significant following error when you do the HOMEZ command? If you have the integral gain value you say, it should pull the motor in to virtually zero error at rest. Is your Ixx63 integrator limit value set to near the default? Do you have any other position offsets, such as compensation tables?

Have you found where in your PLC programs you are resetting Ix22 to its old value?

Jeff is correct that Ethernet and USB will not get you to 1000 blocks/sec. However, PC/104 (the stack version of the ISA bus) has been used successfully at well over 1000 blocks/sec. It is almost as fast as the PCI bus interface. As Jeff suggests, you must make sure there is no other bottleneck that slows you down. The Power PMAC CPU for the UMAC, with its 1Gbps Ethernet interface streaming directly into the processor, has been used for multiple thousands of blocks per second.

It sounds like your servo loop is not operating very well. A "homez" command sets the present commanded position to zero. The actual position, which is what is reported, will be equal to the negative of the following error. In a homing search move, the actual position captured on the trigger becomes the motor zero position, and the commanded position for the end of the post-trigger move. The actual position at the end of the post-trigger move will be equal to the negative of the following error. Make sure your encoder is reporting position reliably. Also, check your servo tuning, particularly the integral gain term Ixx33.

I have no trouble setting this from a background program. Can you isolate it to a very short program and try it? I did: open plc 7 CompTable[0].Target[0]=Motor[6].CompPos.a disable plc 7 close enable plc 7 and the setting took effect as expected.

The output voltages are not proportional to the supply voltages. The op-amps in the output stage take the 5V digital PWM signals, filter them and amplify them with a fixed gain to obtain the +/-10V output. (Our "true DAC" output stages work the same way, amplifying the DAC voltage output with fixed gain regardless of the [legal-range] supply voltage.) These are not H-bridge topologies like amplifiers. This circuitry is simply a very cost-effective way of getting an analog output voltage proportional to a command number.

Erik: Atul is putting together information on the "geterrors" functionality. On the soft limit behavior, people want these limits to do a bunch of different things. If a "definite" move, programmed or jog, has a destination past the soft limit, we assume that it was a mistaken command and refuse to do it. In the case of an indefinite jog, it only has the potential for going past the soft limit, and usually will be stopped before this. In our older controllers, we would start to decelerate these moves as they passed the soft limits. In Power PMAC, if the soft limits are enabled, we automatically convert these to definite jog to the limit so we do not go past the limit even if the move is not stopped with another jog command before that. This calculation is done at the beginning of the jog move.

Erik: It is on our development list to provide the capability to specify a mask as to which bits are reported by the geterrors routine. After discussion here, we will probably remove SoftPlusLimit and SoftMinusLimit (as well as the corresponding PlusLimit and MinusLimit bits for the hardware limits) from the default mask, as these are not really reporting error events (but they still convey useful information). SoftLimit (and corresponding LimitStop for the HW limits) will remain in the default mask. Curt

Erik: Thanks for reporting the discrepancy in the manual. We will have to revise the description of the SoftLimit status bit to indicate that it gets set when it decides it will have to stop on a software limit, as in your case. It will stay set as long as it is in the "mode" of being stopped on the limit (e.g. until you start to jog out). This is the bit you should be looking at for the operational state of the system. The SoftPlusLimit and SoftMinusLimit bits are transparent, telling you whether the motor position presently exceeds that software limit. This is intentional. Curt