curtwilson

The TCOMP offset is added to the PID output after the Ix69 saturation check. Some people complain about this, but it seems to be what you want.

Erik: Our script for automatically updating the manual files on the forum broke, and did not post the latest revisions for the manuals that came out with the newest firmware. We should have them posted by tomorrow. My apologies for the confusion. A new manual chapter will have 100 pages of documentation on "status" elements -- ones you don't usually write to (and often cannot), but can provide much useful information for the user. 1. There are several aspects to brake control. One is the hardware aspect, which is pretty specific to the brake. Somehow, you have to get from the digital output that you select on the PMAC system to the signal that actually turns the brake on (engaged) and off (disengaged). Usually you will not be able to do this directly, and so will need something like a relay in between. Almost always, you will want an "active off" brake that requires power to disengage, so it will automatically engage on a system failure. Next is the issue of how to control the brake from software. Increasingly people want this as automatic as possible, so we have added a firmware feature to do this in the Power PMAC. Motor[x].pBrakeOut and Motor[x].BrakeOutBit allow you to specify which digital output you want to use for the brake control. Motor[x].BrakeOffDelay specifies the time from enabling the amplifier until the brake is released, giving the servo time to establish full control of the motor. Motor[x].BrakeOnDelay specifies the time before disabling the amplifier after engaging the brake in a "delayed disable" (Motor "dkill" command or CS "ddisable" command) to give the brake time to engage fully. There is a new section in the User's Manual "Safety" chapter that explains this fully. 2 & 3.) For motor torque/current, there is Motor[x].IqCmd (the commanded torque-producing current value from the servo), and if you are closing the current loop in direct-PWM mode, Motor[x].IqMeas for the actual torque-producing current value. 4.) All serious commercial servo amplifiers have an "amplifier enable" digital input. If this is in the "disable" state, the amplifier should not output anything regardless of what the input command level is. Controlling the amplifier enable signal automatically from the PMAC is a standard part of the firmware, and it is very important that you use this. Enabling a PMAC motor (open-loop or closed-loop) automatically sets the specified amplifier-enable output bit to 1, and disabling the motor automatically sets it to 0. I really don't know of anyone who drops the power input to their amps just to disable them. We also set the command output level to zero as best we can as extra protection. The reason we digitally add in the "DacBias" term even when the amplifier is enabled is to permit you to compensate for offsets in our outputs and/or the amplifier inputs to get an effective zero command -- it's really the digital equivalent of an offset pot. Curt

We have never had a polarity contro bit for the limits on any PMAC because we have wanted to force the more failsafe configuration of normally closed limit switches with the standard interface circuitry. We will be very hesitant to change this. The "LimitBits" setup element specifies the location of the resulting bits on Power PMAC's 32-bit data bus. The MACRO register elements are 16 and 24 bits at the high end of this bus.

I can't duplicate this either. Over the last several years, I have done this sequence hundreds of times to check out various aspects of the HW limit functionality, and have never seen it. We have had no other reports of this issue from anyone. The closed-loop zero-velocity state the motor is in at the end of the abort is no different from the closed-loop zero-velocity state the motor is in any time you are holding position. Of course, tuning issues could cause vibrations at rest (but not uniquely in limits). We have never seen motor unit scaling issues affect anything. Curt

Ken: You will need to use the hardware address of this register in the M-variable definition if you want to get at the single bit (which does not have an element name to itself). Of course, you could use the whole element, mask and shift. There are two ways to get the hardware address (actually address offset from the base of I/O space). First, the software reference chapter "I/O Address Offsets" lists these for all of the ASIC registers. Presuming you are using Acc5E[0] (what you list above is an error because you don't have an index for the card), the IC base offset is $800000, and the register offset for Macro[m][n] is given as m*16 + n*4 + $100, which is $10C for your register. This gives an overall offset of $80010C. Your definition can then be: ptr XMinusLimHW->u.io:$80010C.26.1 If you don't want to look it up, you can get it from command line queries. First, do Gate2[0].Macro[0][3].a and it will give you the absolute address. Next, query the starting I/O address with Sys.piom Subtract this reported value from your registers reported value and it should give you the same value as the manual gives.

Ken: I can't duplicate this here. Once I trigger the limit to abort the jog move, the abort deceleration proceeds regardless of what I do to the limit switch afterwards. I created a long deceleration so I have the time to toggle my limit back and forth dozens of times during the decel, and I can't get anything to happen. This behavior is what we planned, and what the code indicates should happen. Are you sure your application code is not commanding something else when it perceives you are out of the limit? Curt

Power PMAC has an automatic "torque limited" homing search mode. If you set Motor[x].CaptureMode to 2, the triggering condition will not be an input trigger, but the condition that the magnitude of the following error exceeds the warning following error limit Motor[x].WarnFeLimit. Many people use this mode for this type of homing. To use this in your case, make sure your HW limit stop function is disabled for the move by setting Motor[x].pLimits to 0. You should make sure your servo-loop integrator will not "charge up" by setting Motor[x].Servo.SwZvInt to 1. You may want to limit your servo output with Motor[x].MaxDac as you noted. It will be best to set Motor[x].HomeOffset to a large enough positive value that you come out of the limit zone in the post-trigger move. If you want to slow down on hitting the limit switch, I would recommend initially commanding a "jog-until-trigger" move using the limit input as your trigger. When the trigger is found (Motor[x].TriggerMove goes to 0), then command the homing search move with lower speed, following error trigger, etc. Many people who do not have a separate home switch use a combination of the limit switch and the encoder index for homing (the first index pulse inside the limit is the trigger). Is this feasible in your case?

For all registers of this type, subtract out the value of Motor[x].HomePos, which contains the value of the motor zero position relative to the power-up/reset position. (In Power PMAC, we cannot block interrupts like we could in Turbo PMAC, so we cannot reliably reset all of these registers for a new reference position in the same servo cycle.) Curt

Already in the firmware is the choice of killing (disabling) or aborting (controlled stop) when you hit an EOT limit (HW or SW) in open-loop mode. If bit 1 (value 2) of Motor[x].FaultMode is set to 1, the motor will be killed. If the bit is set to 0 (the default), the motor will be aborted. Different people want different things here, but remember that a controlled stop will virtually always be quicker and take less distance. In closed-loop mode, generally you want to do a controlled stop on hitting an EOT limit. It is quicker, and easier to recover from (you can just jog it out in the opposite direction). With the software limits (set by Motor[x].MinPos and Motor[x].MaxPos) the motor is always brought to a controlled stop, in both the old and the new firmware. If it is possible ahead of time to see that such an event is coming, the commanded move will be brought to a stop at the limit position (not begin to decelerate as the limit is passed). For example, a "J+" indefinite jog command is automatically converted to a "jog to Motor[x].MaxPos" definite jog if the SW limits are active. The new feature Sina mentioned in the upcoming firmware is really intended for those (rare) cases where the feedback has failed so that the SW limits cannot detect the overtravel (and no other limit such as following error has been tripped). In this case, it is not likely that a controlled stop is feasible, so it is best to disable the motor. In normal operation, you would hit the SW limit (which should be set for a position just inside the HW limit) and come to a controlled stop. In this case, even if you hit the HW limit during the abort deceleration, the motor would stay enabled.

The key point is that there are two ways of assigning user names to variables. One is the variable declaration, which auto-assigns an underlying variable to your name. For an M-variable, this would look like: ptr MyPtrVar->{definition}; For a P-variable, this would look like: global MyGlobalVar1; You can do "manual assignment" with a #define directive, which is really just a text substitution: e.g. #define MyPtrVar1 M1 The auto-assignment method is strongly recommended in virtually all cases. It is easier and more robust. Power PMAC and the IDE keep track of the underlying variables used so you don't have to. The project manager's downloader will automatically catch any duplicate definitions. We recommend that your auto-assigning variable declarations go in the file "global definitions.pmh" in the "Global Includes" folder of the Project Manager.

The Yaskawa Sigma I incremental encoders you have go through some interesting gyrations to get the Hall data to the controller without extra wires. They mux the U, V, and W Hall states onto the third channel, along with the index, based on the 4 possible states of the A & B signals. At power up of the encoder, it artificially walks the A & B signals through a full cycle (and back) without the need for any motion, so the controller will see all the Hall states. We designed the PMAC2 ASIC to be able to accept this format, but there are some tricky issues. The biggest one is that if you power up the encoder and the PMAC at the same time, the encoder walks through its artificial AB cycle before the ASIC is ready to take it. On a few products, we added a relay for the encoder power that would not close until the ASIC was configured. This helped, but was not always reliable. Finally, we got hold of the key Yaskawa engineers in Japan who told us that their own controllers kept cycling power to the encoder until they caught the artificial cycle. So that is what we suggest now, using the "invalid demux" status bit in the IC channel's status word. For the test that determines what Ixx91 should be, you do not need to catch this starting cycle, because you are using motion. The standard procedure should work. I do remember that the edges are not placed where they could be used by themselves for simple six-step commutation, which was a big surprise to me when I found this out many years ago. Instead, they are halfway in between those points. I believe Sina is correct that every motor should be the same, but I do not know what Ixx91 should be for these motors.

Casey: From the manual, it looks like you should be able to connect the A and B inputs to 14E inputs without any problem. (I wouldn't bother with the A/ and B/ lines.) The issue for you now is that you have to perform the "quadrature decode" in software (the ACC-24 boards have hardware circuits in their ASIC to do this). I would write a PLCC 0 or an "Open Servo" for a spare "motor" to do this. Fundamentally, you will need 4 variables, which I will call NewA, NewB (from the present cycle), OldA, and OldB (from the last cycle). If NewA is different from OldA, you will count up or down depending on the state of B; If NewB is different from OldB, you will count up or down depending on the state of A. Good luck!

Simon: Look at the setting of Ixx83 for the motor. It contains the address of the register used to read the rotor angle for the commutation. If it contains the address of a real encoder register (e.g. $078xxx for Turbo, $Cxxx for non-Turbo), it is doing closed-loop commutation, not microstepping. Curt

SimonD: A couple of clarifications are needed here. Microstepping is by definition an open-loop technique that does not use encoder feedback for the phase commutation or position feedback. If Turbo PMAC is doing the full control of a microstepped motor, it is doing what we call "direct microstepping". In this mode it splits the full-step cycle into a fixed 2048 microsteps (512 microsteps per step). Nowhere in the direct microstepping algorithm is a pulse train generated. At higher speeds, many microsteps will be skipped between consecutive phase computation cycles. (Note that if you use a traditional external microstepping drive that accepts pulse-and-direction input, you will use PMAC completely differently to output one pulse per microstep of the drive.) If you use encoder feedback for the commutation, you are performing "brushless motor commutation", even if the motor is marketed as a "stepper motor". For you, it is just a high-pole-count brushless servo motor. In closed-loop brushless motor commutation, there is no commanded step size, and no possibility of a mismatch between output step and feedback count. I do not recommend open-loop commutation (microstepping) and closed-loop servo, as you can get into the hunting issue you worry about. If you have paid for the encoder, use it for everything you can! You will get better performance and higher efficiency. Curt Wilson

The 2010 firmware releases are more flexible (but less protective) in this regard. Previously you could not wipe out any subprogram (which is what reloading does first) if anything was running (motion program or plc program) that had the potential to call the subprogram. The new firmware does permit you to do this, putting the responsibility on you not to do anything foolish. Another requirement to provide this flexibility is that the reloaded program will be loaded at the "end" of the used memory, with a "hole" at the previous location. If you do this often enough without resetting the card, you do have the potential to hit the end of memory.

You have several methods, which fall into the categories of "absolute" and "relative" specification of the motor. If you want "absolute" specification of the motor (say, Motor 7 regardless of which motor is executing the algorithm), the best way is probably just to access it the same way as you would in the script language, e.g.: Motor[7].ActPos If you want "relative" specification of the motor (say, the next higher numbered motor than the one executing the algorithm), you can use either something like: Mptr[1].ActPos or Mptr2 = Mptr + 1; Mptr2->ActPos... Curt

I'm not quite sure exactly what effect you are trying to compensate for, but I think your best first shot would be to build a "custom sine table". PMAC commutation uses a 2048-element sine lookup table in RAM, both for speed of calculation and possibility of modification. Saved setup variable Ixx55 lets you point to your own custom table instead of the built-in table. The brief instructions under Ixx55 in the Software Reference give enough information to tell you how to use such a table. Of course, you must decide how you want to customize the table. The values in the table are multiplied by your control effort value, so your "tweaks" here are scaled, unlike the TCOMP table values.

On the ACC-24E2A, the encoder loss bits are found in the Lattice chip, not the ASIC, as in the ACC-24E3. Here are the base address offsets of the Lattice chips for each ACC-24E2x, given by the Gate1 index "i": 4: $D06040 6: $D06140 8: $D0E040 10: $D0E140 12: $D16040 14: $D16140 16: $D1E040 18: $D1E140 The 4 registers in the Lattice are at Base, Base+4, Base+8, and Base+$C, and the encoder loss bit is bit 13 on the 32-bit bus. So for the encoder-loss bit on the last channel of the first ACC-24E2A in a typical system (i=4), you could define: M400->u.io:$d0406C.13.1[hr] The table was half-wrong above. Correction and completion of the table of IC index numbers and ID chip base address offsets: 4: $D06040 5: $D06140 6: $D06050 7: $D06150 8: $D0E040 9: $D0E140 10: $D0E050 11: $D0E150 12: $D16040 13: $D16140 14: $D16050 15: $D16150 16: $D1E040 17: $D1E140 18: $D1E050 19: $D1E150

You do not need to read the full 25 bits of single-turn information (which itself is only a fraction of the full position information) every servo cycle. You only need to read enough bits, starting from the LSB, that you know which way you have traveled since the last servo cycle. This means you cannot go "halfway around" the range of positions you do read in a single servo cycle, because we assume you traveled the shorter distance between the two values. (If you formally studied digital sampling theory in school, you will recognize this as the same phenomenon as in the Nyquist Sampling Theorem.) With the low 24 bits covering half a motor revolution, you could go up to 1/4 of a revolution in a servo cycle. With a 2 kHz servo, you could go up to 30,000rpm. With a 5 kHz servo, you could go up to 75,000rpm.

The commutation source in Turbo PMAC is limited to a 24-bit cycle (16M LSBs) by Ixx71. Your encoder has 25 bits per mechanical revolution (32M LSBs). However, if you have a 4-pole motor, which is likely, your commutation cycle is still within the 24-bit range. You will be able to set Ixx71 to the maximum value of 16,777,215, and Ixx70 to 1, to specify your cycle size. (Note: Technically, the commutation cycle would be 16,777,216 LSBs in this case. If your motor could travel hundreds of thousands of revolutions, this might be a problem, as it would get 2 LSBs off per mechanical revolution. But I doubt this will be a problem in a Stewart platform. Even after 1024 mechanical revolutions, the torque reduction from the accumulated error is one part in a million.) From a theoretical viewpoint, the ideal thing would be to set Ixx83 to read the "SerialDataA" register on the ACC-84E directly every phase cycle (after setting up the 84E to read the encoder every phase cycle, not just every servo cycle). Set Ixx01 to 3 to specify a Y-register read. This minimizes the delay in getting the encoder position. If you process the data value in the conversion table "unshifted" (recommended for this high resolution), you could also read the 24-bit result in the conversion table. It is slightly delayed for use in the next phase cycle(s), but in actual use, we have not seen this be a problem. If your commutation cycle is really bigger than 16M LSBs of your encoder, then you must use an encoder conversion table entry to "strip off" one or more of the low bits (by telling it to start at bit 1 or higher of the source register). If you want to keep full resolution in the servo loop, this will have to be a separate entry from what you use for servo feedback.

The PMAC(1) ASICs have edge-triggered capture. We had several complaints that if you were already in the triggered state when you started a homing search or similar move, you would go on "forever" (at least into the limits). So in the PMAC2 ASICs, we used a level-triggered capture. In this case, if you are in the trigger state when you start such a move, it will trigger immediately. Of course, there are trade-offs and so advantages and disadvantages to both approaches. Curt Wilson VP Engineering

The typical "backlash compensation" function in controllers (including the PMAC) is intended to improve the accuracy and repeatability of the load position when only a motor sensor is present. It does this by adding in or taking out an offset to the commanded position based on the direction of travel. This is not your case here, as you have a load sensor that will accurately represent the load position in both directions of travel. Your problem is that during reversals, the motor is unloaded during reversals while the backlash is being taken up. (From your post, it seems that you think it is more heavily loaded.) Unfortunately, dealing with this case is more art than science -- there do not seem to be fixed solution strategies out there. As Sina said, much depends on how you are actually controlling your stepper motor. Without feedback on the motor, you really have no idea what it is doing during reversals. How are you controlling the motor? Curt Wilson VP Engineering Delta Tau Data Systems