Hello Guest it is March 28, 2024, 10:27:30 PM

Author Topic: CP motor, PMDX126, ESS...Limit Switch ++ tripped when touchplate gets grounded  (Read 2067 times)

0 Members and 1 Guest are viewing this topic.

Running Clearpath motors which have a fault signal they can output. I put that input int the ESS at "Motor 0 ++ Limit" because I couldn't think of a better place. And it works. When they stall that signal makes it into the ESS fine.


But with that signal enabled in ESS, touching the touchplate active side input to the grounded spindle housing will trigger all 4 motor Limit switch ++ inputs. Or possibly, something else occurs that faults all 4 CP steppers together, but I can't see how that would be possible because of the following: 


If I disable the motor fault signals in the ESS the touch plate will not cause any problem or log entry. The touchplate itself works properly in both cases.


Where else can I put the motor fault signals and why would the touchplate cause this behavior? I assume the limit ++ would behave like an E-Stop so putting the motor fault signal there made sense. Am I wrong?


Appreciate your thoughts on this.
Hi,

Quote
Where else can I put the motor fault signals and why would the touchplate cause this behavior? I assume the limit ++ would behave like an E-Stop so putting the motor fault signal there made sense. Am I wrong?

You ask several questions, the most telling is why a probe event triggers a limit? May I suggest we break the problem down a bit:
1) Where and how can you deal with servo faults?.
2) What action do you expect of the machine if a servo does fault, an Estop or some other action less drastic like Feedhold?
3) Why does a probe event trigger a servo fault?....or is it a servo fault or is it conducted noise onto the fault wire?

Mach4 has swags of inputs in addition to ++Limits. For instance ISIG_INPUT1 through ISIG_INPUT64.

May I suggest that you use these signal inputs, one for each servo fault output.

For example:
Assign a spare input pin on your PMDX126 to signal ISIG_INPUT20 and then connect that pin to the X axis servo fault output.

Now make a new entry it the SigLib{} table in the screen load script of the form:

[ISIG_INPUT20]=function(state)
local inst=mc.mcGetInstance()
  if state==1 then
      mc.mcCntlSetLastError(inst,'X axis servo alarm')
      mc.mcCntlEStop(inst)
  else
      mc.mcCntlSetLastError(inst,'X axis alarm reset')
  end
end,

So now if the x axis servo faults you will know which servo has faulted. Note that I have chosen Estop as the required action
but you could equally choose some other action like:
mc.mcCntlFeedHold(inst).

You would require three inputs, one for each axis. You may need to get another breakout board, a cheap and cheerful
bidirectional C10 at $23.00 for instance. If you set pins 2-9 as inputs and used port three of the ESS with pins 2-9
set similarly as inputs you will have plenty of spare inputs if the PMDX126 does not have enough spare.

This would address the first two issues, namely how to deal with the servo fault outputs and the action to take when a servo faults.
The last question is now likely to resolve itself.

I suspect the Z axis is faulting because when the probe event occurs Mach, or rather the ESS directs that the Z axis stop immediately,
and I am guessing that it is causing an over current event within the servo. The same sort of thing happens when you Estop,
the deceleration is VERY abrupt and can cause a current spike which will trigger your alarm. If this is the case then the arrangements
I have suggested will isolate whether indeed the Estop is caused by conducted noise OR a genuine servo fault.

If it is a servo fault then you need to program the servo for some respectable max deceleration such that the over current event
is NOT triggered.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'

Offline thosj

*
  •  532 532
    • View Profile
Craig is right, as is usual:)

Here's my code for my 4 Clearpath SDSK motor HLFB error signals. As you can see, I use a PMDX-108 for the extra input, a more expensive alternative to the C10!! I don't think you want the servor error inputs on Limit inputs! Once you get them going on "normal" inputs, you can tell which one is giving you the error and trouble shoot from there. All that said, you'll have to work at faulting these motors, they're very nice motors and their tuning software should have "figured out" your mechanics. You'll maybe need to get acceleration figured out in Mach4 so suit. I could "push" these harder than my old servos so I got cocky and found the high limit, so had to back off a bit!! The HLFB inputs will help you adjust accel, just write a gcode snippet to G0 back and forth in an axis a bunch of times, start working on accel to test!! Good luck:)

My code, commented so I remember this years later!

--PMDX-108 Port 2 Pin 6 Mach4 Input 10
--HLFB_X ERROR
[mc.ISIG_INPUT10]= function(state)
    if (state==1) then
          mc.mcCntlCycleStop(inst)
          mc.mcCntlSetLastError(inst, "HLFB_X Servo Error")
    end
end,

--PMDX-108 Port 2 Pin 7 Mach4 Input 11
--HLFB_Y ERROR
[mc.ISIG_INPUT11]= function(state)
    if (state==1) then
          mc.mcCntlCycleStop(inst)
          mc.mcCntlSetLastError(inst, "HLFB_Y Servo Error")
    end
end,

--PMDX-108 Port 2 Pin 8 Mach4 Input 12
--HLFB_A ERROR
[mc.ISIG_INPUT12]= function(state)
    if (state==1) then
          mc.mcCntlCycleStop(inst)
          mc.mcCntlSetLastError(inst, "HLFB_A Servo Error")
    end
end,

--PMDX-108 Port 2 Pin 9 Mach4 Input 13
--HLFB_Z ERROR
[mc.ISIG_INPUT13]= function(state)
    if (state==1) then
          mc.mcCntlCycleStop(inst)
          mc.mcCntlSetLastError(inst, "HLFB_Z Servo Error")
    end
end,
« Last Edit: January 12, 2020, 08:40:15 AM by thosj »
--
Tom
thank you both for the reply. I like what you are doing and I will implement today. I didn't know how to access a generic input... now I do. (cheap and cheerful... never heard that phrase before :) )

I need to add that while this will isolate the input pin signals for each servo and will be very useful, nothing has to be moving for this to happen so sudden deceleration is not taking place. I can cause this just sitting there idle. Hence I don't think the servo is the source of the condition, nor do I think it's VFD noise as it is not running either.
However...


If Limit++ acts like the estop, then that would turn off the Enable output to the servo and result in the fault coming on triggering the Limit++ . It's a vicious circle.


Thinking this further, the fault inputs nor the touch probe inputs are ground referenced, they all share a common floating return. Maybe they need to be tied to chassis ground....  The PMDX outputs are intended to float, not sure the inputs are.




Offline thosj

*
  •  532 532
    • View Profile
I didn't mention, but maybe should have. You have to setup Inputs in Mach4, you have to setup Port x and Pin x for your inputs, and the code goes in the screen start script from the screen editor. And, of course, you have to actually WIRE them to the input terminals of whatever you choose to use for said inputs, C10, PMDX-108Input, or whatever.
--
Tom
The input signals on the PMDX-126 are referenced to the GND terminals present on J11, J12, and J13 along the right side of the board. If you expect to use electrical contact with a tool to do touch off, we recommend using a wire from one of these grounds to a clip temporarily gripping the cutting tool. Connecting this ground to the machine frame may work in most cases, but the clip is more reliable.

The outputs on J1 through J7 are referenced to the PCgnd terminals on those connectors. We generally do not recommend connecting PCgnd to frame ground because doing so may establish ground loop paths that will cause problems. This is especially true if you are using an actual parallel port on your computer.

While the PMDX-126 uses pin 10 of the first port to report E-Stop, Mach itself can be configured to look at any signal input as E-Stop. You might double check your configuration.
Steve Stallings
www.PMDX.com
Hi Steve,
I am still fighting spurious activation of inputs and I'm looking for cause. I do understand that the touch off tool can not rely on a good ground path through the spindle bearings to the signal common return and needs a clip directly from the bit to the "common" (can't really call it a ground) pin.  I am doing that. But...
When I measure from that ground clip to the spindle (or any other) frame I have 50VAC because the input return path is floating and allows induced voltage. I'm guessing that the sudden grounding of that pin might be enough "signal" to set off random things i.e. "spurious activation" on the PMDX board.
Not too long ago we discussed grounding both the input and output sides and you recommended against grounding the output side but were unable to commit on the input side. Do you have any concerns about grounding the input side so all return signals and power supplies share a common 0V point shared with chassis ground?
I didn't mention, but maybe should have. You have to setup Inputs in Mach4, you have to setup Port x and Pin x for your inputs, and the code goes in the screen start script from the screen editor. And, of course, you have to actually WIRE them to the input terminals of whatever you choose to use for said inputs, C10, PMDX-108Input, or whatever.
Thanks Thosj, I was aware of the "how" once I saw the script. I saw those extra input settings in the config, and planned to pursue them "someday" as I didn't think I would need them right away. Alas, wrong again :)
I have made the changes and it does what we expect, now I'm chasing the signal fidelity.


ON a related subject . . .  since you use CP servos also, how do you handle the "enable"? I am thinking that I would like to keep them enabled once mach starts or after some MACH initialization process, no real reason to disable them, yet I don't want to just tie the signal high. E-Stop should stop all movement.  When I disable them the Z axis drops and I lose my reference and its inconvenient . Your Thoughts?
Hi,

Quote
E-Stop should stop all movement.  When I disable them the Z axis drops and I lose my reference and its inconvenient . Your Thoughts?

If the machine is moving then loss of reference happens with an Estop event also, if you don't want to lose reference DON'T Estop, ever if
you can help it. Cycle Stop or Feedhold are preferred.

You should have brake on the Z axis. In industrial practice a machine that uncontrollably drops its Z axis on Estop, depower or ANY other
circumstance would be illegal in a work environment for the operators safety. You should apply the same standard.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Hi,
If the machine is moving then loss of reference happens with an Estop event also, if you don't want to lose reference DON'T Estop, ever if
you can help it. Cycle Stop or Feedhold are preferred.
You should have brake on the Z axis. In industrial practice a machine that uncontrollably drops its Z axis on Estop, depower or ANY other
circumstance would be illegal in a work environment for the operators safety. You should apply the same standard.
Craig
Yea, I don't disagree. I would make the case that this is close enough... but I know I'm wrong.  I'll look into a nema34 brake that doesn't break my wallet.