Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: OldePhart on January 11, 2020, 09:18:22 PM
-
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,
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
-
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,
-
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.
-
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.
-
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.
-
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,
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
-
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.
-
Hi,
I would make the case that this is close enough... but I know I'm wrong.
don't get me wrong, I cut corners to save budget and it is legally permissible given that I am an amateur, but the shortcuts
I take would not be permissible in a commercial machine.
I am surprised that Clearpath don't have a braked model. Then I suppose there are too few wires going to the servo to enact it.
I find that Clearpath are expensive for what you get. A 400W Delta or DMM servo and 230VAC drive costs less than a Clearpath
of 200W. Of course with a separate drive you can have many more wires for control features like a brake.
I have a braked 750W Delta B2 series servo and drive, it has in addition to step/direction inputs has 8 programmable
digital inputs, six programmable digital outputs and two programmable analogue outputs. It cost about $100USD more than
a non-braked servo, $650USD including three day DHL shipping to New Zealand. Clearpath cant get within a country mile
of that, first I don't think they make a 750W servo, certainly not one with a brake.
Clearpath CPM-SDSK-3416P is 365W for $424
Clearpath CPM-SDHP-3446D is 410W for $695
Clearpath CPM-SDHP-N0561P is 986W for $928
Delta 400W B2 series (160,000 cpr encoder) and drive $385
Delta 750W B2 series and drive $439
Delta 750W B2 series braked and drive $565
-
.... how do you handle the "enable"? ....
I don't really "remember" how I handle "enable"!! One thing I do remember, I consider the machine NOT REFERENCED once I hit eStop....period, and my Z does NOT drop.
I have two sets of contacts on my eStop. One signals Mach4, one shuts off ALL power to the drives. So when I eStop, I assume I need to re-home.
-
Hi,
don't get me wrong, I cut corners to save budget and it is legally permissible given that I am an amateur, but the shortcuts
I take would not be permissible in a commercial machine.
I am surprised that Clearpath don't have a braked model. Then I suppose there are too few wires going to the servo to enact it.
I'm with you. I am an amateur at this CNC world, I'm in industrial automation... PLC's, SCADA, Instrumentation etc on the factory floor, so I know when I shouldn't take shortcuts in that world. But I'm just building a woodworking CNC just to keep my mind busy (and make my fortune on Etsy :) ) when I retire. If that brake addon wasn't so expensive I would have already done it. I just didn't think Z drop would be as much of a problem as it really is. I have asked technic if a brake is an option and they simply said no, it's not their thing. Pity, it's the one thing missing.
I only spent about $250US on my 800 Oz/In motors, the c face brake for a nema 34 is $500 ! That's prohibitively expensive... for my needs. I do have an air assist counterbalance worked out. But while I am locating the spurious activations of signals, I'm leaving the motors enabled for now. Motion (steps) and VFD shutdown on estop. That's good enough for me.
-
[... when I eStop, I assume I need to re-home.
I agree, but my stops are not from estop, they are from something random I need to locate and the z dropping is more dangerous than anything else, so for now this enable is hooked to a seperate button.
I have just seen the power of these motors when I screw up. I missed raising the Z during a rapid and watched it cut a 1/2 inch groove, 3/4 inch deep across a spoilboard for 18 inches in 1 second before I could reach the estop. Didn't even slow down.