Disabling one hardware limit switch

[KEJR]

Hello, I'll start by explaining my application: I would like to do a hard stop torque limited homing operation with a ballscrew with end of travel (EOT) limit switches. Currently my limits are performing properly and stop the motor with a controlled stop. What I would like to do is to have a homing motion program that disables the negative limit and commands a motion in the negative direction until the limit switch is detected. Upon hitting the limit switch the prog will change feerate, limit torque, and open up following error (so we don't trip out). Then of course I will wait for torque to equal the current command limit and record that position for setting the home value later. Then slightly move off of the hard stop, re-enable limits and be on my way. 1) So how do I disable my negative limit? Do I just disable both limits by setting motor[].pLimit to zero? 2) Do I limit the torque by setting Motor[].MaxDac or is there a different way? I may end up doing this from a C program using jogging functions instead of a motion prog, but it really should work the same way. Thanks, KEJR

[KEJR]

A follow on question would be how do I detect the limit switch is active? Do the limits need to be active for this to work?

[Sina.Sattari]

Hi, Since the limits are addressed by the same parameter and they are expected to be 2 consecutive bits in status word, the only way of disabling them is to set Motor[x].pLimit to zero. About detecting the hard stop, Power PMAC has a built-in feature which works similar to your explanation and that is homing based upon warning following error. Warning following error can be set smaller than Motor[x].FatalFeLimit by setting Motor[x].WarnFeLimit. If you set bit 1 (value 2) of Motor[x].CaptureMode and issue a home search command "home" it will move until following error exceeds Motor[x].WarnFeLimit and moves to Motor[x].HomeOffset distance from there. For more information, read about Motor[x].WarnFeLimit and Motor[x].CaptureMode in "Power PMAC Saved Data Structure Elements" Manual. [url=ftp://support.deltatau.com/DT-USA/Power PMAC Documentation/PDFs/Software Reference/Power PMAC Saved Data Structure Elements 2010-09.pdf]Link[/url] If you want to detect the limit switches while the limits are disabled, you have to look at the gate structure on the accessory directly which can be done using structures. For example: ACC24E2A[4].Chan[0].MinusLimit or ACC24E2[4].Chan[0].PlusLimit Regards,

[curtwilson]

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?

[KEJR]

I ended up writing a C program function for this. I am setting motor[].pLimits to zero and using jog commands with data structure access for things like MAxDac and following error. I'll keep the canned routine in mind for future applications. I didn't want to do the home switch to index pulse (or end travel switch) thing just because if someone takes the motor off for service or replacement I don't have to recalibrate with the hard stop home. These machines are pretty clean so debris on the hard stop isn't as big a deal as say a machining center, etc. Thank you very much. It is good to know that the pLimits method is acceptable and not going to have adverse effects on something else. KEJR

[KEJR]

how does one go about mapping a ptr var to the minus limit bit in the macro register? I tried to do: ptr XMinusLimHW->Acc5e.Macro[0][3].a.26.1 but the editor or the command window won't take that syntax. I also tried the raw address reported by that register when I typed it in the terminal screen but it doesn't like that either. I want to shut off limits but still read the hardware limit register. I can still read the value of the full register, but was hoping that I could use the convenience of the pointer variable bit addressing. Let me know if there is a way to do this or if I have to mask the bit myself. Thanks, KEJR

[curtwilson]

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.

[KEJR]

*** Problem Solved *** I put this in another similar post I had, but the solution was to map an M-var to the raw IO bits sent back over Macro that belong to my EOT limit in need of monitoring. I then disable the special function for that input pin in the drive register using a MacroSlave command (Handy little command). This effectively cancels the PPMAC limit as well since the drive doesn't send out the limit status when a hardware limit is not defined on any of its inputs. So then I jog to the hardware limit, stop, knock down my MaxCmd, open up following error and following warn to considerably larger number. Then I issue my slow homing command to the hard stop using the builtin homing facilities and the Following Warning capture as described previously. This works well. I'm having one issue with the MacroSlave command working at bootup, but that is for another post as the topic is different. Thanks, KEJR