Re: [Emc-users] Dealing with Servo Faults

[John Dammeyer]

I'm finally at the point where I'm ready to bundle up the CNC cabinet with the 
new Knee Servo driver connection and a few of the other changes.  Status LEDs 
on the front cover.

Anyway my research has turned up some interesting conclusions.
1. An open loop stepper motor system with a relay to switch on/off the spindle 
works fine with just an ESTOP input.  There is no such thing as a 'Fault' 
state; just an ESTOP state.

2. A closed loop system where the loop is closed outside of the CNC software 
(MACH or EMC) works like a stepper system but requires something different from 
an ESTOP state if motor drivers are best left powered up but disabled with an 
enable.

3. A closed loop system through EMC (not possible in MACH) also possibly 
doesn't have a fault input and the HAL/INI file entries take care of dealing 
with faults that might occur externally while also handling the absolute ESTOP.

What I've discovered is that the PMDX-126 I used is really mostly targeted at 
the first type systems and of course predominantly MACH since it even has 
mounting holes lined up with the two ribbon cables from the SmoothStepper.

I've designed my system to use the parallel port from the dual boot PC and test 
each change I make on both LinuxCNC and MACH3 on WIN-XP.  I really do wish that 
MESA would target the Windows+MACH market and make a version of their 7i92H 
that competed with the SmoothStepper but would also run with LinuxCNC.  Likely 
they would kill in that market for users knowing they could, if they wanted 
flip a switch without hardware changes into LinuxCNC.

Anyway, a fault signal into the PMDX creates the same effect as the NC ESTOP 
switch circuit opening.  There is no separate way to send the FAULT into the PC 
to be handled differently.  That means either a fault or an ESTOP will shut 
down power to my drives.

So I've been looking at the HAL file and trying to figure out how to decouple a 
driver fault from ESTOP.  It means I wouldn't run the driver faults into the 
PMDX Fault input.  It would have to be an separate input.  And I want that 
fault to only disable the ENABLE output I have allocated to the DB25-1 pin.  
And take the machine offline.  The Machine Enable button on the top goes OFF.

This feature would probably break MACH3 although it might be possible to add 
something that monitors that and in effect clicks their ONLINE button which 
disables the motion keyboard and switches off the ENABLE.

On my LinuxCNC system the "Toggle Machine Power (F2)" button does what I want.  
The ENABLE goes off.  The MIST relay goes off as do any other outputs but the 
ChargePump remains on.

If I assign an input to the FAULT signal from my hardware to what do I couple 
it so that the transition causes the "Toggle Machine Power (F2)" effect.  And 
since the ENABLE going off would clear the FAULT on the servos (if clearable) I 
wouldn't want it to immediately switch Machine power On again.  

In other words it has to be the transition of the fault.  After that I have to 
manually click on the display.  Maybe in the future I'd like an input that does 
what the F2 key does but for now I'd like to keep it simple.

An ESTOP would still do what an ESTOP does which I suspect will remain as:
net estop-external-in=>  iocontrol.0.emc-enable-in
where
# MESA 7i92H P2 connections DB25-10
net estop-external-in <= hm2_7i92.0.gpio.013.in_not

I have extra inputs on the second parallel port or I could combine more of the 
limit/home switches to free up an input.

Say I did have hm2_7i92.0.gpio.020.in available as an input.
net fault-external-in <= hm2_7i92.0.gpio.020.in

A logical AND of estop-external-in and fault-external-in could then map onto 
iocontrol.0.emc-enable-in

In fact if I wanted to really kludge it I could AND it with one of the limit 
switch inputs although the error message would be incorrect the behavior is 
what I want.  If I logically AND the "max-x-y-min-z" with the fault signal 
which itself is a combination of all drive faults then I'd get the "Toggle 
Machine Power (F2)" operation but just incorrect messages along the side of the 
machine.

Suggestions?  Combining the fault with the limit switch would also make this 
work with MACH3 as long as I check the box (Charge Pump Enabled during ESTOP) 
leaving motor power on but ENABLE off.  And the mushroom ESTOP still shuts off 
the motor power since it's part of a critical NC switch circuit.  

In both cases I have to stop using the FAULT input on the PMDX-126 BoB.
John Dammeyer



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Friday 12 February 2021 11:17:36 Jon Elson wrote:

> On 02/11/2021 09:41 PM, Gene Heskett wrote:
> > Well, it takes FF1 = 20.5 to get a cruise at about null,
> > And I did have FF2 = .5, but .35 cancels the stop spike.
> >
> > So my question is why are these so far out of the normal range where
> > for a stepgen FF1=1.0 and FF2 = .001 is about right. Something else
> > must be seriously out of whack.  But what?
>
> Well, I have no idea, I just know what WORKS, by trial and
> error (and a little knowledge of the
> control theory behind it.)
>
> >   pid_A.output is almost straight to
> > the pwmgen.A.value, with that pwmgen in mode 2. An idb in the middle
> > of the link seems to be without measurable effect, but maybe I've
> > not tried a high enough idb.amount. That is currantly at 10, a value
> > I would think would make it overshoot and oscillate but does not.
>
> I have no idea what hardware you have cobbled up, so I
> really don't know what is going on.

The only thing I'll fault this motor for is that its an oilite bushing 
and brushed, both of which add friction/stiction in unk quantities. Its 
also two worms in series, one in this motor and the one in the bs-1. 

The pid almost copes but the approach to null is never quite done UNLESS 
the PID winds up. In which case it does overshoot and goes into reverse, 
often crowbarring the psu, which will then shutdown till it cools again.  
Takes 2 to 3 minutes for it to cool enough to restart. 100 watt motor, 
only a 400 watt 24v supply.  My next tune session will reduce the pid's 
max_output until I see it actually slowing, which should stop the 
windup.

I thought 900 would be too low, but it still starts to wind up at about 
1800 degrees a minute, so there is not a known relationship there 
either.

Thanks, Jon

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On 02/11/2021 09:41 PM, Gene Heskett wrote:


Well, it takes FF1 = 20.5 to get a cruise at about null,
And I did have FF2 = .5, but .35 cancels the stop spike.

So my question is why are these so far out of the normal range where for
a stepgen FF1=1.0 and FF2 = .001 is about right. Something else must be
seriously out of whack.  But what?
Well, I have no idea, I just know what WORKS, by trial and 
error (and a little knowledge of the

control theory behind it.)

  pid_A.output is almost straight to
the pwmgen.A.value, with that pwmgen in mode 2. An idb in the middle of
the link seems to be without measurable effect, but maybe I've not tried
a high enough idb.amount. That is currantly at 10, a value I would think
would make it overshoot and oscillate but does not.

I have no idea what hardware you have cobbled up, so I 
really don't know what is going on.


Jon



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Todd Zuercher]

Because steps/machine unit and volts/unit are not the same scale.

Todd Zuercher
P. Graham Dunn Inc.
630 Henry Street 
Dalton, Ohio 44618
Phone:  (330)828-2105ext. 2031

-Original Message-
From: Gene Heskett  
Sent: Thursday, February 11, 2021 10:42 PM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Dealing with Servo Faults

[EXTERNAL EMAIL] Be sure links are safe.

On Thursday 11 February 2021 18:31:31 Jon Elson wrote:

> On 02/11/2021 04:37 PM, Gene Heskett wrote:
> > So, looking at pid.error with a 100mv/div scale, 1 div would be .1 
> > degree?
>
> If you look closely at the Halscope screen, you will see that it does 
> NOT show a "v".
> So, you would get a 100m/div scale, 100 milli-somethings.
> If the INPUT_SCALE or SCALE in
> the ini file is set right so that the DRO on the Axis screen reads in 
> degrees, then one division would be .1 degree, at the 100m Halscope 
> scale.
>
> >   I think my gain is quite a bit higher than that, but I just ran it 
> > from here and that is what the pid.error channel is showing for 
> > gain, 100m. Only the leading edge of a g0 mdi move shows more than
> > .1 degree of error, and slowing the max_accel would probably lower 
> > that, currantly at 1000.. cruizing noise is perhaps +- .20 division 
> > worst case.
>
> A little bit of FF2 can help with spikes at the beginning and end of a 
> move.  But, VERY small amounts are required, in the 0.001 range.
>
Well, it takes FF1 = 20.5 to get a cruise at about null, And I did have FF2 = 
.5, but .35 cancels the stop spike.

So my question is why are these so far out of the normal range where for a 
stepgen FF1=1.0 and FF2 = .001 is about right. Something else must be seriously 
out of whack.  But what? pid_A.output is almost straight to the pwmgen.A.value, 
with that pwmgen in mode 2. An idb in the middle of the link seems to be 
without measurable effect, but maybe I've not tried a high enough idb.amount. 
That is currantly at 10, a value I would think would make it overshoot and 
oscillate but does not.

Thanks Jon
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Thursday 11 February 2021 18:31:31 Jon Elson wrote:

> On 02/11/2021 04:37 PM, Gene Heskett wrote:
> > So, looking at pid.error with a 100mv/div scale, 1 div would be .1
> > degree?
>
> If you look closely at the Halscope screen, you will see
> that it does NOT show a "v".
> So, you would get a 100m/div scale, 100 milli-somethings.
> If the INPUT_SCALE or SCALE in
> the ini file is set right so that the DRO on the Axis screen
> reads in degrees, then
> one division would be .1 degree, at the 100m Halscope scale.
>
> >   I think my gain is quite a bit higher than that, but I just ran
> > it from here and that is what the pid.error channel is showing for
> > gain, 100m. Only the leading edge of a g0 mdi move shows more than
> > .1 degree of error, and slowing the max_accel would probably lower
> > that, currantly at 1000.. cruizing noise is perhaps +- .20 division
> > worst case.
>
> A little bit of FF2 can help with spikes at the beginning
> and end of a move.  But, VERY small amounts are required, in
> the 0.001 range.
>
Well, it takes FF1 = 20.5 to get a cruise at about null,
And I did have FF2 = .5, but .35 cancels the stop spike.

So my question is why are these so far out of the normal range where for 
a stepgen FF1=1.0 and FF2 = .001 is about right. Something else must be 
seriously out of whack.  But what? pid_A.output is almost straight to 
the pwmgen.A.value, with that pwmgen in mode 2. An idb in the middle of 
the link seems to be without measurable effect, but maybe I've not tried 
a high enough idb.amount. That is currantly at 10, a value I would think 
would make it overshoot and oscillate but does not.

Thanks Jon
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Sam Sokolik]

ok.. This is my take...  This is why I like
linuxcnc>-a/d>- analog drive>-servo>-encoder>-linuxcnc...

The enables are controlled by motion.  The power is controlled by estop.

The PID within linuxcnc has a lot of power - saturation, following error
and so on.  It can detect most all faults a closed loop system will have.

If following error or saturation or whatever is exceeded - the machine goes
into power off...   You don't lose position because linuxcnc is still
counting encoders.   even with an estop removing power from the drives.
 The encoders are still counting with linuxcnc.

We have 3 machines running this way.  I think it is the best way.  (but it
is late and I might be a little intoxicated...)

sam

On Thu, Feb 11, 2021 at 5:33 PM Jon Elson  wrote:

> On 02/11/2021 04:37 PM, Gene Heskett wrote:
> >
> > So, looking at pid.error with a 100mv/div scale, 1 div would be .1
> > degree?
> If you look closely at the Halscope screen, you will see
> that it does NOT show a "v".
> So, you would get a 100m/div scale, 100 milli-somethings.
> If the INPUT_SCALE or SCALE in
> the ini file is set right so that the DRO on the Axis screen
> reads in degrees, then
> one division would be .1 degree, at the 100m Halscope scale.
> >   I think my gain is quite a bit higher than that, but I just ran
> > it from here and that is what the pid.error channel is showing for gain,
> > 100m. Only the leading edge of a g0 mdi move shows more than .1 degree
> > of error, and slowing the max_accel would probably lower that, currantly
> > at 1000.. cruizing noise is perhaps +- .20 division worst case.
> A little bit of FF2 can help with spikes at the beginning
> and end of a move.  But, VERY small amounts are required, in
> the 0.001 range.
>
>
> Jon
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On 02/11/2021 04:37 PM, Gene Heskett wrote:


So, looking at pid.error with a 100mv/div scale, 1 div would be .1
degree?
If you look closely at the Halscope screen, you will see 
that it does NOT show a "v".
So, you would get a 100m/div scale, 100 milli-somethings.  
If the INPUT_SCALE or SCALE in
the ini file is set right so that the DRO on the Axis screen 
reads in degrees, then

one division would be .1 degree, at the 100m Halscope scale.

  I think my gain is quite a bit higher than that, but I just ran
it from here and that is what the pid.error channel is showing for gain,
100m. Only the leading edge of a g0 mdi move shows more than .1 degree
of error, and slowing the max_accel would probably lower that, currantly
at 1000.. cruizing noise is perhaps +- .20 division worst case.
A little bit of FF2 can help with spikes at the beginning 
and end of a move.  But, VERY small amounts are required, in 
the 0.001 range.



Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 23:09:36 Jon Elson wrote:

> On 02/10/2021 07:08 PM, Gene Heskett wrote:
> > But is the error also in degrees? The halsope is
> > measuriing volts and I have not found anyplace where it
> > states the error is in the same sized unit the rest of
> > that particular servo is using. And, if its degrres I
> > should have tripped a coup le dozen or more times while
> > playing as I'm seeing very short term peaks that are 2x
> > that setting.. Thank you Jon. Cheers, Gene Heskett
>
> Halscope measures "Units".  It has no idea what they mean.
> Position and following error
> are in "user units", ie. whatever you have defined them with
> in your SCALE parameters in
> the .ini file.  Velocities are in user units/second, except
> encoder deltas are in counts/servo period.
>
> So, looking at PID_ERROR with Halscope, with a scale of
> 200u, and assuming inch units,
> that means one vertical division is 200 uInch, or 0.0002 inch.
>
> The only place Volts really show up is in velocity DAC
> commands, where a properly scaled DAC driver would show the
> same thing as a physical analog scope hooked to the DAC output.
>
> Jon
>
>
So, looking at pid.error with a 100mv/div scale, 1 div would be .1 
degree? I think my gain is quite a bit higher than that, but I just ran 
it from here and that is what the pid.error channel is showing for gain, 
100m. Only the leading edge of a g0 mdi move shows more than .1 degree 
of error, and slowing the max_accel would probably lower that, currantly 
at 1000.. cruizing noise is perhaps +- .20 division worst case.

On a different front both USPS and UPS is runniung on time as I got a 3" 
boring head kit with a large selection of indexed 3/4" shank bars from 
USPS and half an hour later 2 sets of 19 metric r8's showed up with nice 
wooden racks to store them in. All the metallic stuff is sealed in 
plastic which I'll leave on until its warmed up so it won't sweat and 
rust. So I'm a happier camper, which translates to pulling the post, 
reaming the bolt holes a mm bigger and putting it back together square, 
which means I will have to break down and buy a cylindrical square. 
Starts at 300 usd, good used is 5 or 7&1/2 hundred for new. Ouch!!

Take care and stay well everybody.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Thursday 11 February 2021 10:40:12 Jon Elson wrote:

> On 02/10/2021 10:37 PM, Gene Heskett wrote:
> > I went to take the bs-1 off its table, and found I can't
> > take it very far as I have negleted to build a 2nd set of
> > inline connectors so I can disconnect the encoder and
> > really take it away. And I've yet to come up with a scheme
> > to detect that it is plugged in, and if not, disable
> > linuxcnc's ability to see an error because its not there.
> > 2 of my machines need such a bit of ini and hal magic.
>
> Well, if you have encoder feedback, you'd want to ground the
> A and B lines so the encoder counter never detects movement
> from electrical noise.

Only the GO704 will need that, but wouldn't switching off the feedback 
into the pid do the same thing?

checking in the 6040's hal:

net b-prsnt <= hm2_5i25.0.7i76.0.0.input-09 # high is it plugged in?

but no further use of it now. Could run the sel line of the two mux2's.
addf them just above the the pid_a in the GO704, and interrupt the feed 
back from the stepgen and joint stuff do the same thing?
 
Hmm, no pid's in the 6040, so disable these paths in the 6040's hal:

Switch this with a mux2 at the =>
net bpos-cmd joint.3.motor-pos-cmd => hm2_5i25.0.stepgen.03.position-cmd

Ditto
net bpos-fb  hm2_5i25.0.stepgen.03.position-fb => joint.3.motor-pos-fb

And output the b_prsnt to the A axis stepgeg.enable with a 3rd mux2 at 
the => point.
net benable  joint.3.amp-enable-out => hm2_5i25.0.stepgen.03.enable

And rewire the driver box for individual enables and add those 4 wires as 
they are presently open and on by default. I need to get in there and 
turn that motors current down, it gets burnya hot just sitting there 
doing nothing 99.9% of the time. It was originally built to run a 
270oz/in motor on a 4" rotary, and the motor now on it is smaller. I've 
not actually used it since making the tap hats. I need to modify that A 
axis anyway, to a smaller tooth belt as its capable of about 3 rps ATM, 
one is sufficient and that would multiply its holding power I found some 
more parametric pulleys on thingiverse so I think I can make gt2's on my 
modified ender-3. I already made a usable 20 tooth gt2 and theres room 
for an even bigger pulley on the axel shaft. I'll make that as a rim for 
an alu hub though. And I've sourced some ball bearing idlers for belt 
tensioners and increased wrap on the small 20 toother.

> And, you'd want to set those axes so 
> they had to be homed individually, not as part of a
> multi-axis homing sequence.  Other than that, I don't see
> why LinuxCNC needs to know the axis is there or not.  Of
> course, with open-loop, all move commands will have no
> effect, and with feedback, would cause a following error.
>
That sounds like a job for a couple of mux2's in the hal file, with 
their .sel lines tied to the contact loop coming back, 2 to ground the 
missing pid_a.feedback, and ground the pid_a.command input. In the 
GO704's hal.

Anything else?

> Jon
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On 02/10/2021 10:37 PM, Gene Heskett wrote:
I went to take the bs-1 off its table, and found I can't 
take it very far as I have negleted to build a 2nd set of 
inline connectors so I can disconnect the encoder and 
really take it away. And I've yet to come up with a scheme 
to detect that it is plugged in, and if not, disable 
linuxcnc's ability to see an error because its not there. 
2 of my machines need such a bit of ini and hal magic.
Well, if you have encoder feedback, you'd want to ground the 
A and B lines so the encoder counter never detects movement 
from electrical noise.  And, you'd want to set those axes so 
they had to be homed individually, not as part of a 
multi-axis homing sequence.  Other than that, I don't see 
why LinuxCNC needs to know the axis is there or not.  Of 
course, with open-loop, all move commands will have no 
effect, and with feedback, would cause a following error.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Thursday 11 February 2021 07:28:51 andy pugh wrote:

> On Thu, 11 Feb 2021 at 04:39, Gene Heskett  
wrote:
> >  I've yet to come up
> > with a scheme to detect that it is plugged in, and if not, disable
> > linuxcnc's ability to see an error because its not there
>
> I have a GPIO pin looped up to the connector socket and back. A jumper
> in the plug completes the circuit.
>
> However, I only actually use this to not enable the servo drive. I
> don't even know if it is possible to load a 3-axis config if the
> rotary is unplugged.

I can't since homeing A is first in the homing sequence on the 6040. And 
last on the GO704. I don't know if I could remove it from the auto home 
and unplug it. I do have that loop wired to detect its missing on the 
c6040 but have not figured out how to disable its driver if its missing. 
Yet.  Thats probably solvable given the spare IO I have on both 
machines. 

> There is scope for HAL logic the HAL Tcl, but I don't know of any way
> to use logic in the INI.

'Twould be easy with the addition of an IF/then/else/endif to the INI 
file

> I suppose a launcher script could do it, but it would have to load the
> drivers, a realtime thread, poll the GPIO, store the result, shut down
> realtime and then launch the required config.

Thats been my general idea, but that means maintaining 2 separate ini and 
hal files, and thats a long term maintenace nightmare I'd druther not 
have to deal with. Humm, how about growing a case sensitive launcher?
With 2 "last" remember buffers.

So linuxcnc -l launches one version, and linuxcnc -L launches the other?
That could be done in a bash script called LinuxCNC, I'll put it on my 
todo list. Unless somebody else beats me to it.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[andy pugh]

On Thu, 11 Feb 2021 at 04:39, Gene Heskett  wrote:

>  I've yet to come up
> with a scheme to detect that it is plugged in, and if not, disable
> linuxcnc's ability to see an error because its not there

I have a GPIO pin looped up to the connector socket and back. A jumper
in the plug completes the circuit.

However, I only actually use this to not enable the servo drive. I
don't even know if it is possible to load a 3-axis config if the
rotary is unplugged.
There is scope for HAL logic the HAL Tcl, but I don't know of any way
to use logic in the INI.

I suppose a launcher script could do it, but it would have to load the
drivers, a realtime thread, poll the GPIO, store the result, shut down
realtime and then launch the required config.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[John Dammeyer]

I've attached the app node pdf from Practical Micro Design for their PMDX-126.

My system is set up as in Figure 1 and at the time it seemed like a really good 
idea.  The trouble is a fault from any of the drives into the PMDX-125 or 126 
effectively removes the ChargePump which results in all outputs stopping and 
relays off.  And so yes, motion of the other axis is stopped.  But so is power 
and any position information.  

I like that the ESTOP is coupled into the board and results in the board 
disabling the Enable output and shutting off all relays.  Once the ESTOP is 
reset regardless of the CNC software, the relays remain off so the spindle or 
coolant doesn't come back on with the untwisting of the ESTOP switch.

But I want power off with mechanical ESTOP but not with faults.  So it looks 
like the fault signal has to disable everything but can't cause power to go 
away.  The ultimate goal is to be able to reset the system so that the 
remaining axis can function while the one that faulted is disabled.  That 
allows some motion on the other axis to be able to get at the machine if needed.

Make sense?

John



AN125-1_MachinePower_02.pdf
Description: Adobe PDF document
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 23:09:36 Jon Elson wrote:

> On 02/10/2021 07:08 PM, Gene Heskett wrote:
> > But is the error also in degrees? The halsope is
> > measuriing volts and I have not found anyplace where it
> > states the error is in the same sized unit the rest of
> > that particular servo is using. And, if its degrres I
> > should have tripped a coup le dozen or more times while
> > playing as I'm seeing very short term peaks that are 2x
> > that setting.. Thank you Jon. Cheers, Gene Heskett
>
> Halscope measures "Units".  It has no idea what they mean.
> Position and following error
> are in "user units", ie. whatever you have defined them with
> in your SCALE parameters in
> the .ini file.  Velocities are in user units/second, except
> encoder deltas are in counts/servo period.
>
> So, looking at PID_ERROR with Halscope, with a scale of
> 200u, and assuming inch units,
> that means one vertical division is 200 uInch, or 0.0002 inch.
>
> The only place Volts really show up is in velocity DAC
> commands, where a properly scaled DAC driver would show the
> same thing as a physical analog scope hooked to the DAC output.
>
> Jon
>
Thanks Jon. Printed, I'll take it to the machine and see if I can 
mentally translate what I'm seeing into degrees.

I went to take the bs-1 off its table, and found I can't take it very far 
as I have negleted to build a 2nd set of inline connectors so I can 
disconnect the encoder and really take it away.  And I've yet to come up 
with a scheme to detect that it is plugged in, and if not, disable 
linuxcnc's ability to see an error because its not there.  2 of my 
machines need such a bit of ini and hal magic.
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On 02/10/2021 07:08 PM, Gene Heskett wrote:
But is the error also in degrees? The halsope is 
measuriing volts and I have not found anyplace where it 
states the error is in the same sized unit the rest of 
that particular servo is using. And, if its degrres I 
should have tripped a coup le dozen or more times while 
playing as I'm seeing very short term peaks that are 2x 
that setting.. Thank you Jon. Cheers, Gene Heskett 
Halscope measures "Units".  It has no idea what they mean.  
Position and following error
are in "user units", ie. whatever you have defined them with 
in your SCALE parameters in
the .ini file.  Velocities are in user units/second, except 
encoder deltas are in counts/servo period.


So, looking at PID_ERROR with Halscope, with a scale of 
200u, and assuming inch units,

that means one vertical division is 200 uInch, or 0.0002 inch.

The only place Volts really show up is in velocity DAC 
commands, where a properly scaled DAC driver would show the 
same thing as a physical analog scope hooked to the DAC output.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 21:58:16 John Dammeyer wrote:

> > From: Gene Heskett [mailto:ghesk...@shentel.net]
> >
> > On Wednesday 10 February 2021 20:51:47 John Dammeyer wrote:
> > > Ah! Was missing
> > > setp hm2_7i92.0.gpio.023.is_output true
> > > setp hm2_7i92.0.gpio.025.is_output true
> > >
> > > All fixed now.  And setting it to DB25-17  (gpio.024) which runs a
> > > relay on this little BoB I can make the relay click on and off
> > > which can run an air solenoid and give me misting. John
> > >
> > > > From: John Dammeyer [mailto:jo...@autoartisans.com]
> > > >
> > > > At the moment using the HAL meter I can switch on Coolant or
> > > > Mist
> > > >
> > > > #  ---coolant signals---
> > > > net coolant-flood <= iocontrol.0.coolant-flood
> > > > net coolant-flood => hm2_7i92.0.gpio.023.out
> > > > net coolant-mist <= iocontrol.0.coolant-mist
> > > > net coolant-mist => hm2_7i92.0.gpio.025.out
> >
> > Be sure and put a flywheel diode on the air valve coil John. The
> > contacts of that teeny little relay will last many times longer. 
> > And the relay driver on the 7i92 should be checked to see if the
> > coil is missing a flywheel, and add a 1N914 if there isn't one. But
> > I expect Mesa has that covered though.
>
> You bet!   I always do that.  And of course it's better to have them
> at the solenoid than at the relay.  Snub it at the source rather than
> letting it radiate off the wire.

Yup, we're on the same page.

> For the servo faults I think I'll end up having to run the fault
> signal into the system rather than to the PMDX-126 dedicated /Fault
> input.   Then logically AND that with the ENABLE out to the servos.  
> That will prevent the AC/DC power from being dropped out which the
> PMDX does when the /Fault, E_Stop or Err signal goes active.
>
> I still have to investigate what will happen to coolant relays.  Like
> the HAL will have to AND them with ENABLE or outputs automatically
> switched off

Yes, I dob't recall the details but there's > 400 lines of hal I wrote 
long ago, on each machine that does something similar to that.

> There's also the question then if
> net estop-external-in=>  iocontrol.0.emc-enable-in
> is needed?

Probably yes if there is a stepper in the system that can lose home, it 
also gets the volatile_home treatment.

>  or would I be better to run the Fault Signal into the emc-enable-in. 
> More research is needed.  If the Estop isn't triggered with a fault
> (and DC/AC power isn't removed) LinuxCNC still needs to know that the
> system is no longer moving.

There are N! ways to do that, so trace the logic and do it the simplest 
way for your setup. With 4 machines each does it in a different way 
here.

Take care & stay well John.

>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[John Dammeyer]

> From: Gene Heskett [mailto:ghesk...@shentel.net]
> On Wednesday 10 February 2021 20:51:47 John Dammeyer wrote:
> 
> > Ah! Was missing
> > setp hm2_7i92.0.gpio.023.is_output true
> > setp hm2_7i92.0.gpio.025.is_output true
> >
> > All fixed now.  And setting it to DB25-17  (gpio.024) which runs a
> > relay on this little BoB I can make the relay click on and off which
> > can run an air solenoid and give me misting. John
> >
> > > From: John Dammeyer [mailto:jo...@autoartisans.com]
> > >
> > > At the moment using the HAL meter I can switch on Coolant or Mist
> > >
> > > #  ---coolant signals---
> > > net coolant-flood <= iocontrol.0.coolant-flood
> > > net coolant-flood => hm2_7i92.0.gpio.023.out
> > > net coolant-mist <= iocontrol.0.coolant-mist
> > > net coolant-mist => hm2_7i92.0.gpio.025.out
> 
> Be sure and put a flywheel diode on the air valve coil John. The contacts
> of that teeny little relay will last many times longer.  And the relay
> driver on the 7i92 should be checked to see if the coil is missing a
> flywheel, and add a 1N914 if there isn't one. But I expect Mesa has that
> covered though.
> 
You bet!   I always do that.  And of course it's better to have them at the 
solenoid than at the relay.  Snub it at the source rather than letting it 
radiate off the wire.

For the servo faults I think I'll end up having to run the fault signal into 
the system rather than to the PMDX-126 dedicated /Fault input.   Then logically 
AND that with the ENABLE out to the servos.   That will prevent the AC/DC power 
from being dropped out which the PMDX does when the /Fault, E_Stop or Err 
signal goes active.

I still have to investigate what will happen to coolant relays.  Like the HAL 
will have to AND them with ENABLE or outputs automatically switched off 

There's also the question then if 
net estop-external-in=>  iocontrol.0.emc-enable-in
is needed?

 or would I be better to run the Fault Signal into the emc-enable-in.  More 
research is needed.  If the Estop isn't triggered with a fault (and DC/AC power 
isn't removed) LinuxCNC still needs to know that the system is no longer moving.

John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 20:51:47 John Dammeyer wrote:

> Ah! Was missing
> setp hm2_7i92.0.gpio.023.is_output true
> setp hm2_7i92.0.gpio.025.is_output true
>
> All fixed now.  And setting it to DB25-17  (gpio.024) which runs a
> relay on this little BoB I can make the relay click on and off which
> can run an air solenoid and give me misting. John
>
> > From: John Dammeyer [mailto:jo...@autoartisans.com]
> >
> > At the moment using the HAL meter I can switch on Coolant or Mist
> >
> > #  ---coolant signals---
> > net coolant-flood <= iocontrol.0.coolant-flood
> > net coolant-flood => hm2_7i92.0.gpio.023.out
> > net coolant-mist <= iocontrol.0.coolant-mist
> > net coolant-mist => hm2_7i92.0.gpio.025.out
> >
> > And the HAL meter shows the GPIO pins changing state when I click
> > the check boxes on the linuxCNC display.  But for some reason the
> > far east simple BoB isn't reflecting that on the outputs.  That's
> > one of those cheap BoBs that has male pins on the DB-25 rather than
> > female pins like most of the rest.  Maybe my crimping job is
> > suspect.

Be sure and put a flywheel diode on the air valve coil John. The contacts 
of that teeny little relay will last many times longer.  And the relay 
driver on the 7i92 should be checked to see if the coil is missing a 
flywheel, and add a 1N914 if there isn't one. But I expect Mesa has that 
covered though.

> > Never seems to end does it?
> >
> > John
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[John Dammeyer]

Ah! Was missing 
setp hm2_7i92.0.gpio.023.is_output true
setp hm2_7i92.0.gpio.025.is_output true

All fixed now.  And setting it to DB25-17  (gpio.024) which runs a relay on 
this little BoB I can make the relay click on and off which can run an air 
solenoid and give me misting.
John

> From: John Dammeyer [mailto:jo...@autoartisans.com]
> 
> At the moment using the HAL meter I can switch on Coolant or Mist
> 
> #  ---coolant signals---
> net coolant-flood <= iocontrol.0.coolant-flood
> net coolant-flood => hm2_7i92.0.gpio.023.out
> net coolant-mist <= iocontrol.0.coolant-mist
> net coolant-mist => hm2_7i92.0.gpio.025.out
> 
> And the HAL meter shows the GPIO pins changing state when I click the check 
> boxes on the linuxCNC display.  But for some reason the
> far east simple BoB isn't reflecting that on the outputs.  That's one of 
> those cheap BoBs that has male pins on the DB-25 rather than
> female pins like most of the rest.  Maybe my crimping job is suspect.
> 
> Never seems to end does it?
> 
> John



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 19:06:56 Jon Elson wrote:

> On 02/10/2021 01:45 PM, Gene Heskett wrote:
> > You may be forgetting that this is calibrated in a degree
>
> Ah, yes, 0.25 degrees doesn't look so huge.
>
> Jon

But is the error also in degrees? The halsope is measuriing volts and I 
have not found anyplace where it states the error is in the same sized 
unit the rest of that particular servo is using. And, if its degrres I 
should have  tripped a coup le dozen or more times while playing as I'm 
seeing very short term peaks that are 2x that setting..

Thank you Jon.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[John Dammeyer]

> From: Jon Elson [mailto:el...@pico-systems.com]
> On 02/10/2021 12:42 PM, John Dammeyer wrote:
> > So back to the original subject.  It's not just motion that can cause a 
> > driver fault.  A broken encoder wire, DC or AC power instability,
> or even random electrical noise.  In all those cases I've found I still have 
> to execute a HOME ALL command to bring things back.  With
> repeatable home switches the G54 still takes the system back to where it was 
> and as long as the replacement tool (or whatever) is still
> in the same place, even after a power loss, machining can continue.
> >
> Yes, with a step-based, open-loop system, you have to
> re-home, as there is no way to know if the last few steps
> were executed or not. With a servo system, or closed-loop
> step-based with encoder feedback, then the computer always
> knows the position, except in cases where the servo drive
> reprocesses the encoder position, and the E-stop powers down
> the drives.
> 
> Jon

Having hooked up DC motors and encoders incorrectly and watching the motor run 
away in the wrong direction I went the route of using what was available with 
the PMDX-126 BoB.  There are problems with it that aren't solvable without 
external hardware.  I wouldn't use it again.

Today while testing the second port of the MESA 7i92H I ran into exactly the 
sort of problem where the STMBL kept faulting and blinking a saturation error.  
Hmmm.  I had finally screwed the 3phase wire shield to the cabinet.  Nope.  
That's not it.  I wiggle connectors.  Nope.   The short DB-25 extension cable I 
grabbed to connect the encoder to the cabinet is probably one of those where 
the ground pins are all connected together.  I swapped to the bigger, thicker 
cable I was using yesterday and no more faults.  

But digging into that I realized the issue with the PMDX-126 BoB.  I use the 
Enable signal to switch on a relay on the BoB through which I run the ESTOP 
signal.  The /FAULT input into the BoB goes through their FPGA and disables the 
relay as well as the DB-25 Pin 1 Enable signal that goes to the drives.  And 
that relay opening the ESTOP circuit shuts of AC/DC high power.   Not really 
exactly what I want.  And I think the ESTOP input into the BoB does the same by 
blocking the ChargePump which also shuts off all outputs.  

All this means is I have to rethink how I handle ESTOP.  No ChargePump means 
DC/AC motor power should be impossible.  So the relay I use needs to run that 
ESTOP signal.  But I may need to rethink using the PMDX-126 /FAULT input since 
I only want the ENABLEs into the drives switched off.  Not the system AC/DC 
power.

Also taking what is called ESTOP on the HP_UHU DC Servo drives FALSE will 
immediately cause the drive to lose position since the only way out of that 
fault is with a processor reset.   Henrik Olssson has said he'd rewrite the PIC 
software for his HP_UHU module so when the fault was released it would recover. 
 But that's potentially a lot of work and testing.For now I don't mind that 
the ENABLE OFF/ON forces a need to rehome.

At the moment using the HAL meter I can switch on Coolant or Mist 

#  ---coolant signals---
net coolant-flood <= iocontrol.0.coolant-flood
net coolant-flood => hm2_7i92.0.gpio.023.out
net coolant-mist <= iocontrol.0.coolant-mist
net coolant-mist => hm2_7i92.0.gpio.025.out

And the HAL meter shows the GPIO pins changing state when I click the check 
boxes on the linuxCNC display.  But for some reason the far east simple BoB 
isn't reflecting that on the outputs.  That's one of those cheap BoBs that has 
male pins on the DB-25 rather than female pins like most of the rest.  Maybe my 
crimping job is suspect.

Never seems to end does it?

John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On 02/10/2021 01:45 PM, Gene Heskett wrote:

You may be forgetting that this is calibrated in a degree


Ah, yes, 0.25 degrees doesn't look so huge.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On 02/10/2021 12:42 PM, John Dammeyer wrote:

So back to the original subject.  It's not just motion that can cause a driver 
fault.  A broken encoder wire, DC or AC power instability, or even random 
electrical noise.  In all those cases I've found I still have to execute a HOME 
ALL command to bring things back.  With repeatable home switches the G54 still 
takes the system back to where it was and as long as the replacement tool (or 
whatever) is still in the same place, even after a power loss, machining can 
continue.

Yes, with a step-based, open-loop system, you have to 
re-home, as there is no way to know if the last few steps 
were executed or not. With a servo system, or closed-loop 
step-based with encoder feedback, then the computer always 
knows the position, except in cases where the servo drive
reprocesses the encoder position, and the E-stop powers down 
the drives.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 11:42:28 Matthew Herd wrote:

> I agree, I feel like that’s a fairly safe assumption, although I
> acknowledge that it is possible the drives might run away.  I figure
> the best way to handle drive faults is to trigger an e-stop (via HAL)
> so that all drives and the spindle halt motion.  Then you could
> one-shot the fault clear lines on the drives when you power up the
> machine.  This would handle the most common faults (i.e. I crashed my
> machine into the side of my vise/table/etc) and avoid trying to slot
> your table or vise with a trashed cutter.  While the following error
> would also trigger the machine to stop, it’s yet another way to ensure
> that things aren’t made worse.  And a one-shot to clear the faults
> would avoid the need to power cycle, rehome, etc.
>
> > On Feb 10, 2021, at 11:29 AM, andy pugh  wrote:
> >
> > I was assuming that the faulted drives would disable themselves. I
> > was thinking about what to do with the drives that have not faulted.
>
Power cycling these new 3 phase step pulse driven servos is appasrently 
the only way to reset the error, so on the Sheldon, a fault from one of 
them resets F2, in turn killing all power to the motor psu's, which of 
coarse unsets the home state too. Takes about 5 seconds or a little more 
because the unloaded psu's take so long to decay. The driver makers 
really should give us a reset input unless there is one in the rj45 
thats undocumented. Cycling the enable doesn't do it in my tests of 
doing that. So I just count ten chimpanzee's before hittin the F2 key to 
get thing restarted, while pulling the tool so I can rehome it without 
hitting the work with the tool.

> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 11:20:22 Jon Elson wrote:

> On 02/10/2021 01:12 AM, Gene Heskett wrote:
> > FERROR = 0.50
> > MIN_FERROR = 0.25
> >
> > And as you can see, running errors allowed are fairly
> > large as I am not done tuning.
>
> Geez, these don't protect you at all from something going wrong!
> Here's the settings on my X axis :
>
> FERROR = 0.003
> MIN_FERROR = 0.005
>
> Jon
You may be forgetting that this is calibrated in a degree
Because of this message I went out to play some more, and now have it 
working a little better ack the halscope.

#
# Axis A
#
[AXIS_A]
MAX_VELOCITY= 30.000
MAX_ACCELERATION= 1000.00

[JOINT_3]
TYPE= ANGULAR
HOME= 0.0
HOME_SEQUENCE   = 3
HOME_SEARCH_VEL = 9.0
HOME_LATCH_VEL  = -1.0
HOME_FINAL_VEL  = 30
HOME_OFFSET = 4.498500
VOLATILE_HOME   = 1
FERROR  = 0.01250
MIN_FERROR  = 0.00625
MAX_VELOCITY= 30.000
MAX_ACCELERATION= 1000.00
P   = 1000
I   = 0.500
D   = 0.500
FF0 = 0
FF1 = 20.5
FF2 = 0.35
BIAS= 0
DEADBAND= 0.00015
BACKLASH= .1
MAX_OUTPUT  = 900.
SERVO_SCALE = 666.7
PWMGEN_TYPE = 2

And its now moving 20% faster, DRO now says 1800 degrees/minute, and it 
settles at about -0.00035 degrees from where its G0 commanded on 
average. there is about a -0.0005 bias that must be coming from the home 
command time delays in getting the home switch status, that particular 
signal is coming in thru a Sainsmart bob, feeding P2 on a 5i25 with its 
input filtering caps on the bob having been removed. So the switch 
status is quantized by the servo thread period. With this new computer 
in might be educational to try a faster servo thread to see if some of 
that error goes away.

And in about an hours playing I did not trigger a single following error.

I have no clue what the unit for this error is, the halscope shows it in 
milivolts about 150 peak at a motion start, cruize settle at a noisy 
zero, adjusted by for bias with FF1, and FF2 can bury the stop spike in 
the noise. The start spike might be somewhat reduced by Dgain but I 
didn't play with that today. Yet. I have a new camera to play with 
first. And a pepperoni roll to call lunch, and mother nature is throwing 
big fluffy snow flakes at me.

You may not be impressed, but I think I've done quite well for basically 
building a servo to drive a BS-1 out of cheap, and unrelated ebay parts.

Thanks Jon
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[John Dammeyer]

Thanks everyone.  Long winded reply below.

The commercial world, I believe, includes electrical standards that require all 
power to be removed with an ESTOP.  That changed as PCs became the controllers 
and ESTOP no longer had to remove power from PCs like they would have from 
PLCs.  But certainly anything that could move and hurt someone fell under that 
envelope.  Standard may vary in different countries.

I had the Gecko Stepper drive fail due to burnt traces on the inner layers that 
heated and then melted the connector.  Possibly due to excess moisture and some 
sort of growth across the pins.  The failure happened to the Z axis drive 
during a knee move  downward while milling.  The subsequent XY move expecting 
the tool bit to be out of the cavity broke the tool and mucked up the work.

The open loop stepper had no idea that it wasn't working anymore.  When I've 
inadvertently run one of the XY DC servos (HP_UHU) into something that results 
in a following error the fault open collector output pulls down the enable 
signal on the other drives (STMBL and the HP_UHU).The Bergerda Spindle 
drive and now knee Bergerda drive are now also wired into that enable signal.  

If I move the Knee and disconnect the encoder from the STMBL the knee stops as 
it should.  

My ESTOP is outside all that.  The ESTOP buttons are in series with the main 
system Motor Power contactor and removes AC power going to the DC power supply 
running the DC Servos and the STMBL 4th axis.  That AC is also fed to the 
Bergerda drives running the spindle and the knee motor.

My theory in both approaches is that since I don't have closed loop control of 
the encoders through the PC (or at least I'm not tracking the encoders with 
existing hardware) that a single fault from say the STMBL that faults the 
HP_UHU DC servos automatically results in a loss of position.  The HP_UHU 
recovery is not just a removal of the fault but a reset of the processor. There 
is no other way out with them.

The Bergerda reset the fault once the enable is disabled and re-enabled.  
Assuming the fault is cleared.  Unplug the encoder and it will stay in fault.

Gene also mentioned start up surge for the DC power supplies for his system.   
My 105VDC supply running the DC Servos and HP_UHU is also brought up softly.  
That delay doesn't affect the HP_UHU drives because their 15V logic circuit is 
powered from the instrument power supply which remains connected during an 
ESTOP.  

But the STMBL introduced a new problem.  It may well have the 24V stable 
instrument power but it faults on low motor voltage.  And the low motor voltage 
is there as the DC supply is brought up.  So the STMBL faults. Which shuts off 
the DC motor power.  Click on the LinuxCNC Power button and up comes the DC 
motor power, the drive enable and the STMBL faults because DC isn't there yet 
but enable is.  Dog chasing the tail.

So now on power up the Enable signal is blocked by a DC power ready signal and 
a 1/2 second delay after that.  Now the STMBL doesn't fault.

So back to the original subject.  It's not just motion that can cause a driver 
fault.  A broken encoder wire, DC or AC power instability, or even random 
electrical noise.  In all those cases I've found I still have to execute a HOME 
ALL command to bring things back.  With repeatable home switches the G54 still 
takes the system back to where it was and as long as the replacement tool (or 
whatever) is still in the same place, even after a power loss, machining can 
continue.

But thanks again for the feedback.
John

> -Original Message-
> From: andy pugh [mailto:bodge...@gmail.com]
> Sent: February-10-21 8:30 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Dealing with Servo Faults
> 
> On Wed, 10 Feb 2021 at 16:26, Jon Elson  wrote:
> 
> > > So, non-faulted drives will stop, but hold position.
> > >
> > Well, the issue there is whether a faulty drive would
> > actually stop when disabled.
> 
> I was assuming that the faulted drives would disable themselves. I was
> thinking about what to do with the drives that have not faulted.
> 
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> � George Fitch, Atlanta Constitution Newspaper, 1912
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Matthew Herd]

I agree, I feel like that’s a fairly safe assumption, although I acknowledge 
that it is possible the drives might run away.  I figure the best way to handle 
drive faults is to trigger an e-stop (via HAL) so that all drives and the 
spindle halt motion.  Then you could one-shot the fault clear lines on the 
drives when you power up the machine.  This would handle the most common faults 
(i.e. I crashed my machine into the side of my vise/table/etc) and avoid trying 
to slot your table or vise with a trashed cutter.  While the following error 
would also trigger the machine to stop, it’s yet another way to ensure that 
things aren’t made worse.  And a one-shot to clear the faults would avoid the 
need to power cycle, rehome, etc.

> On Feb 10, 2021, at 11:29 AM, andy pugh  wrote:
> 
> I was assuming that the faulted drives would disable themselves. I was
> thinking about what to do with the drives that have not faulted.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[andy pugh]

On Wed, 10 Feb 2021 at 16:26, Jon Elson  wrote:

> > So, non-faulted drives will stop, but hold position.
> >
> Well, the issue there is whether a faulty drive would
> actually stop when disabled.

I was assuming that the faulted drives would disable themselves. I was
thinking about what to do with the drives that have not faulted.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On 02/10/2021 03:38 AM, andy pugh wrote:

On Wed, 10 Feb 2021 at 05:11, John Dammeyer  wrote:


Should just the enables to the other servo drives be removed or should power be 
cut to all drives.

I don't know what the industry standard is, but I can think of
arguments for leaving the drives enabled, but stopping the motion
controller.
So, non-faulted drives will stop, but hold position.

Well, the issue there is whether a faulty drive would 
actually stop when disabled.  I can easily imagine some 
faults that could leave the drive in a servo runaway 
situation and ignore enable.


If there is a way to kill the motor power but leave the 
drive logic active, that would be best.
If the drive does NOT process encoder signals, so the drive 
can be completely powered off without losing position 
alignment, then that would be fine (think traditional analog 
velocity servo amps).


You also want to be sure that E-stop applies a braking 
resistor to the motor in some manner.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On 02/10/2021 01:12 AM, Gene Heskett wrote:
FERROR = 0.50 
MIN_FERROR = 0.25 


And as you can see, running errors allowed are fairly 
large as I am not done tuning.


Geez, these don't protect you at all from something going wrong!
Here's the settings on my X axis :

FERROR = 0.003
MIN_FERROR = 0.005

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Todd Zuercher]

Servo faults are relatively rare occurrences.  These machines are generally 
only shut down over weekends and holidays, and a fault that requires a restart 
only generally occurs a handful of times a year.  (mostly due to power 
failures.)  Nothing like most consumer electronics which may see multiple power 
cycles per day.  Besides with the reliability reputation Fanuc is know for, I'm 
pretty sure precautions and safety measures have been engineered into the 
designs to accommodate safely power cycling for much longer than the machines 
projected service life.

Todd Zuercher
P. Graham Dunn Inc.
630 Henry Street 
Dalton, Ohio 44618
Phone:  (330)828-2105ext. 2031

-Original Message-
From: Gene Heskett  
Sent: Wednesday, February 10, 2021 10:03 AM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Dealing with Servo Faults

[EXTERNAL EMAIL] Be sure links are safe.

On Wednesday 10 February 2021 09:11:58 Todd Zuercher wrote:

> On the Fanuc machines I work with a servo amp fault is very similar to 
> an e-stop condition, only worse.  In E-stop power is not removed from 
> the spindle VFD, the servos are disabled (I don't think power is 
> removed from them), and the VFD is sent an e-stop signal and brakes to 
> a stop (actually the VFD has an input that monitors the estop chain).
> The control and all logic circuits remain fully powered and any axis 
> brakes (such as for the Z axis) are engaged.  The effect of a servo 
> fault is essentially the same except the entire machine must be power 
> cycled at the main disconnect to clear the servo fault (simply power 
> cycling at the control is not enough.)  Where clearing an e-stop only 
> requires resetting the e-stop and pressing the reset button.  Part of 
> why I believe power is not removed from the servos at e-stop is the 
> fact that a tiny power blink on one or all phases will usually cause 
> the servos to set an alarm that requires cycling the power to reset.
> This is the same for multiple machine models from 3 different large 
> manufacturers.
>
> Todd Zuercher
> P. Graham Dunn Inc.
> 630 Henry Street
> Dalton, Ohio 44618
> Phone:  (330)828-2105ext. 2031

I'd call that a major PITA Todd. The inrush from turning it back on likely 
accounts for 90% of the parts failures those controls suffer.

What the hell were they thinking?  More income from selling replacement boards?

Stuff with larger inrushes gets soft-started here, so that inrush is slowed 
some by a high powered resistor of 50 ohms or so in series with the line power 
for the first 3 or 4 seconds. IMO thats a powerfull contribution to not having 
any parts failures. The GO704 with its huge spindle supply, draws about 3 amps 
working the average job.  Tutn it on with a normal swich and you will useally 
hear a 30 amp breaker fall. But I've only a 20 in that slot for the last 5 
years, tripped once when I plugged a 1500 watt heater into that circuit. No 
repeats since turning the heater down to the 700 watt coil only.

> -Original Message-
> From: John Dammeyer 
> Sent: Wednesday, February 10, 2021 12:09 AM
> To: 'Enhanced Machine Controller (EMC)'
>  Subject: [Emc-users] Dealing with 
> Servo Faults
>
> [EXTERNAL EMAIL] Be sure links are safe.
>
> Quick question.
>
> There's a multi-axis operation in progress.  For whatever reason one 
> of the servos throws out a fault and of course stops.
>
> Should just the enables to the other servo drives be removed or should 
> power be cut to all drives.
>
> I'm not really in favour of dropping out power because that would mean 
> you also lose the ability to easily recover.  The other drives and 
> spindle were working so you really just want them stopped and things 
> like coolant shut off.
>
> This isn't the same as an ESTOP which does remove all power that could 
> result in motion.  Low voltage control and PC are left running.
>
> For my PMDX-126 BoB my faults are consolidated and brings the PMDX 
> /FAULT input low.  That disables the ChargePump which in turn disables 
> all outputs including the enable to all the drive.  And the orange 
> button beside the red one on the user screen goes greyed out.
>
> After 4 seconds the /FAULT input is once again brought high (inactive) 
> and now the orange ENABLE button on the screen (or F2) can be clicked 
> which then asserts the ENABLE output to the drives and allows hardware 
> to be controlled again.
>
> For my servos taking the ENABLE signal FALSE and then TRUE resets the
> FAULT condition.   If the fault is still there then the /FAULT is
> brought low again. Etc...
>
> What do other systems (including commercial) do when a drive faults on 
> one axis.
>
> John
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.s

Re: [Emc-users] Dealing with Servo Faults

[Jon Elson]

On Wednesday 10 February 2021 00:08:41 John Dammeyer wrote:


Quick question.

There's a multi-axis operation in progress.  For whatever reason one
of the servos throws out a fault and of course stops.

Should just the enables to the other servo drives be removed or should
power be cut to all drives.

OK, on my system (hommade analog velocity servo amps) the 
E-stop removes motor DC power from the amps, as well as 
removing enable. The encoders continue to feed back to the 
PPMC encoder card, so position alignment is never lost.  So, 
I can hit E-stop any time I want to, then click a button to 
go back to live.


Just last week I got an unexpected following error.  Didn't 
understand it immediately, but a closer look showed that a 
drill bit had just ran through the work and into a parallel 
bar.  I had to adjust the fixturing to make sure the 
parallel was not right under the hole.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 09:11:58 Todd Zuercher wrote:

> On the Fanuc machines I work with a servo amp fault is very similar to
> an e-stop condition, only worse.  In E-stop power is not removed from
> the spindle VFD, the servos are disabled (I don't think power is
> removed from them), and the VFD is sent an e-stop signal and brakes to
> a stop (actually the VFD has an input that monitors the estop chain). 
> The control and all logic circuits remain fully powered and any axis
> brakes (such as for the Z axis) are engaged.  The effect of a servo
> fault is essentially the same except the entire machine must be power
> cycled at the main disconnect to clear the servo fault (simply power
> cycling at the control is not enough.)  Where clearing an e-stop only
> requires resetting the e-stop and pressing the reset button.  Part of
> why I believe power is not removed from the servos at e-stop is the
> fact that a tiny power blink on one or all phases will usually cause
> the servos to set an alarm that requires cycling the power to reset. 
> This is the same for multiple machine models from 3 different large
> manufacturers.
>
> Todd Zuercher
> P. Graham Dunn Inc.
> 630 Henry Street 
> Dalton, Ohio 44618
> Phone:  (330)828-2105ext. 2031

I'd call that a major PITA Todd. The inrush from turning it back on 
likely accounts for 90% of the parts failures those controls suffer.

What the hell were they thinking?  More income from selling replacement 
boards?

Stuff with larger inrushes gets soft-started here, so that inrush is 
slowed some by a high powered resistor of 50 ohms or so in series with 
the line power for the first 3 or 4 seconds. IMO thats a powerfull 
contribution to not having any parts failures. The GO704 with its huge 
spindle supply, draws about 3 amps working the average job.  Tutn it on 
with a normal swich and you will useally hear a 30 amp breaker fall. But 
I've only a 20 in that slot for the last 5 years, tripped once when I 
plugged a 1500 watt heater into that circuit. No repeats since turning 
the heater down to the 700 watt coil only.

> -Original Message-
> From: John Dammeyer 
> Sent: Wednesday, February 10, 2021 12:09 AM
> To: 'Enhanced Machine Controller (EMC)'
>  Subject: [Emc-users] Dealing with
> Servo Faults
>
> [EXTERNAL EMAIL] Be sure links are safe.
>
> Quick question.
>
> There's a multi-axis operation in progress.  For whatever reason one
> of the servos throws out a fault and of course stops.
>
> Should just the enables to the other servo drives be removed or should
> power be cut to all drives.
>
> I'm not really in favour of dropping out power because that would mean
> you also lose the ability to easily recover.  The other drives and
> spindle were working so you really just want them stopped and things
> like coolant shut off.
>
> This isn't the same as an ESTOP which does remove all power that could
> result in motion.  Low voltage control and PC are left running.
>
> For my PMDX-126 BoB my faults are consolidated and brings the PMDX
> /FAULT input low.  That disables the ChargePump which in turn disables
> all outputs including the enable to all the drive.  And the orange
> button beside the red one on the user screen goes greyed out.
>
> After 4 seconds the /FAULT input is once again brought high (inactive)
> and now the orange ENABLE button on the screen (or F2) can be clicked
> which then asserts the ENABLE output to the drives and allows hardware
> to be controlled again.
>
> For my servos taking the ENABLE signal FALSE and then TRUE resets the
> FAULT condition.   If the fault is still there then the /FAULT is
> brought low again. Etc...
>
> What do other systems (including commercial) do when a drive faults on
> one axis.
>
> John
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Todd Zuercher]

On the Fanuc machines I work with a servo amp fault is very similar to an 
e-stop condition, only worse.  In E-stop power is not removed from the spindle 
VFD, the servos are disabled (I don't think power is removed from them), and 
the VFD is sent an e-stop signal and brakes to a stop (actually the VFD has an 
input that monitors the estop chain).  The control and all logic circuits 
remain fully powered and any axis brakes (such as for the Z axis) are engaged.  
The effect of a servo fault is essentially the same except the entire machine 
must be power cycled at the main disconnect to clear the servo fault (simply 
power cycling at the control is not enough.)  Where clearing an e-stop only 
requires resetting the e-stop and pressing the reset button.  Part of why I 
believe power is not removed from the servos at e-stop is the fact that a tiny 
power blink on one or all phases will usually cause the servos to set an alarm 
that requires cycling the power to reset.  This is the same for multiple 
machine models from 3 different large manufacturers.

Todd Zuercher
P. Graham Dunn Inc.
630 Henry Street 
Dalton, Ohio 44618
Phone:  (330)828-2105ext. 2031

-Original Message-
From: John Dammeyer  
Sent: Wednesday, February 10, 2021 12:09 AM
To: 'Enhanced Machine Controller (EMC)' 
Subject: [Emc-users] Dealing with Servo Faults

[EXTERNAL EMAIL] Be sure links are safe.

Quick question.

There's a multi-axis operation in progress.  For whatever reason one of the 
servos throws out a fault and of course stops.

Should just the enables to the other servo drives be removed or should power be 
cut to all drives.

I'm not really in favour of dropping out power because that would mean you also 
lose the ability to easily recover.  The other drives and spindle were working 
so you really just want them stopped and things like coolant shut off.

This isn't the same as an ESTOP which does remove all power that could result 
in motion.  Low voltage control and PC are left running.

For my PMDX-126 BoB my faults are consolidated and brings the PMDX /FAULT input 
low.  That disables the ChargePump which in turn disables all outputs including 
the enable to all the drive.  And the orange button beside the red one on the 
user screen goes greyed out.

After 4 seconds the /FAULT input is once again brought high (inactive) and now 
the orange ENABLE button on the screen (or F2) can be clicked which then 
asserts the ENABLE output to the drives and allows hardware to be controlled 
again.

For my servos taking the ENABLE signal FALSE and then TRUE resets the FAULT 
condition.   If the fault is still there then the /FAULT is brought low again. 
Etc...

What do other systems (including commercial) do when a drive faults on one axis.

John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Frank Tkalcevic]

My home made machine connects the enables to the machine enable.  I don't
think it was my idea - I think it was based on one of the servo examples.
E-Stop is completely independent - connects to the e-stop switch, and axis
limit switches and kills power to the spindle and servos (originally it cut
ALL power, but shutting the PC down was silly).

-Original Message-
From: John Dammeyer [mailto:jo...@autoartisans.com] 
Sent: Wednesday, 10 February 2021 4:09 PM
To: 'Enhanced Machine Controller (EMC)'
Subject: [Emc-users] Dealing with Servo Faults

Quick question.

There's a multi-axis operation in progress.  For whatever reason one of the
servos throws out a fault and of course stops.

Should just the enables to the other servo drives be removed or should power
be cut to all drives.

I'm not really in favour of dropping out power because that would mean you
also lose the ability to easily recover.  The other drives and spindle were
working so you really just want them stopped and things like coolant shut
off.  

This isn't the same as an ESTOP which does remove all power that could
result in motion.  Low voltage control and PC are left running.

For my PMDX-126 BoB my faults are consolidated and brings the PMDX /FAULT
input low.  That disables the ChargePump which in turn disables all outputs
including the enable to all the drive.  And the orange button beside the red
one on the user screen goes greyed out.

After 4 seconds the /FAULT input is once again brought high (inactive) and
now the orange ENABLE button on the screen (or F2) can be clicked which then
asserts the ENABLE output to the drives and allows hardware to be controlled
again.  

For my servos taking the ENABLE signal FALSE and then TRUE resets the FAULT
condition.   If the fault is still there then the /FAULT is brought low
again. Etc...

What do other systems (including commercial) do when a drive faults on one
axis.

John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[andy pugh]

On Wed, 10 Feb 2021 at 05:11, John Dammeyer  wrote:

> Should just the enables to the other servo drives be removed or should power 
> be cut to all drives.

I don't know what the industry standard is, but I can think of
arguments for leaving the drives enabled, but stopping the motion
controller.
So, non-faulted drives will stop, but hold position.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Dealing with Servo Faults

[Gene Heskett]

On Wednesday 10 February 2021 00:08:41 John Dammeyer wrote:

> Quick question.
>
> There's a multi-axis operation in progress.  For whatever reason one
> of the servos throws out a fault and of course stops.
>
> Should just the enables to the other servo drives be removed or should
> power be cut to all drives.
>
> I'm not really in favour of dropping out power because that would mean
> you also lose the ability to easily recover.  The other drives and
> spindle were working so you really just want them stopped and things
> like coolant shut off.
>
> This isn't the same as an ESTOP which does remove all power that could
> result in motion.  Low voltage control and PC are left running.
>
> For my PMDX-126 BoB my faults are consolidated and brings the PMDX
> /FAULT input low.  That disables the ChargePump which in turn disables
> all outputs including the enable to all the drive.  And the orange
> button beside the red one on the user screen goes greyed out.
>
> After 4 seconds the /FAULT input is once again brought high (inactive)
> and now the orange ENABLE button on the screen (or F2) can be clicked
> which then asserts the ENABLE output to the drives and allows hardware
> to be controlled again.
>
> For my servos taking the ENABLE signal FALSE and then TRUE resets the
> FAULT condition.   If the fault is still there then the /FAULT is
> brought low again. Etc...
>
> What do other systems (including commercial) do when a drive faults on
> one axis.
>
> John
>
Good question John. I only have one servo, the A on the GO704, and my 
cobbled up servo has only the following error as a fault. And a 
following error is cross couppled into resetting f2. From my present 
ini:
===
#
# Axis A
#
[AXIS_A]
MAX_VELOCITY= 30.000
MAX_ACCELERATION= 1500.00

[JOINT_3]
TYPE= ANGULAR
HOME= 0.0
HOME_SEQUENCE   = 3
HOME_SEARCH_VEL = 9.0
HOME_LATCH_VEL  = -1.0
HOME_FINAL_VEL  = 30
HOME_OFFSET = 4.498500
VOLATILE_HOME   = 1
FERROR  = 0.50
MIN_FERROR  = 0.25
MAX_VELOCITY= 30.000
MAX_ACCELERATION= 1500.00
P   = 6000
I   = 0.500
D   = 0.500
FF0 = 0
FF1 = 21.5
FF2 = 0.55
BIAS= 0
DEADBAND= 0.00015
BACKLASH= .1
MAX_OUTPUT  = 900.
SERVO_SCALE = 666.7
PWMGEN_TYPE = 2
===
And as you can see, running errors allowed are fairly large as I am not 
done tuning. MAX_VELOCITY is restricted to about 4% of what it can do to 
keep the pid from winding up, something the man page says the 900 should 
do but doesn't. So I have to restrict the run vel in order to detect the 
very narrow true condition of the home switch because if I run it any 
faster for SEARCH_VEL, it sails right on by the home switch. At those 
restricted speeds friction stops it short of a null, but the max error 
at stopped is in the .0005 to .0015 degree range. There is also a 
max_decel that is not stated, enforced by the driver because if its 
asked to stop too quick, the reversal of the pwmgen causes excess 
current while the motor is still spinning fwd, crowbaring the 400 watt 
24 volt supply and shutting it down for 2 or 3 minutes while it cools. 
The 6 dollar BTS 7960 based driver runs plumb cold as it can handle 43 
amps.

Like I said, I'm not done tuning yet. Stopping the windup is the next 
thing to do, and I could sure use some advice from servo experts on 
that.

However, if there is anything helpfull here, be my guest John. It for 
instance takes that FF1 to make it cruise at nearly zero error, and the 
P=6000 can't be made much more without oscillating, and that heats the 
motor and psu rapidly.

The SERVO_SCALE was determined by using the home switch as an index, 
recording the count at turn 2, in some extra .hal stuff, running it till 
turn 102 of the BS-1, freezeing the encoder count and subtracting the 
turn 2 count from the turn 102 count, dividing that by 36000 to get 
counts per degree. The motor driveing the BS-1's worm is also a worm 
output so the BS-1 turns rather leasurely. The encoder is in the motor 
and has no index output, designed to run the gate across an estate 
driveway, using about 100 watts to move the gate.

So its working mostly, and I've brought that machine up by replacing it 
box with a faster Dell running buster, and the opencv version of camview 
is working, so getting that calibrated to the new camera is next.

But this continued bad weather is making me want to hibernate, so 
progress is slower than I'd like.

The new scope has arrived, 10" touch screen, 4 trace, 350MHz BW from a 
2gigahertz sampler, sweet but I'm still learning how to 

Re: [Emc-users] Dealing with Servo Faults

[David Berndt]

No experience on commercial systems. But I agree, a servo fault throwing  
e-stop wouldn't be the best. The behaviour that seems standard on fault is  
that the machine goes to power off which removes enable from all the other  
axis and spindle is effective and limits the chaos to a reasonable level  
and makes recovery possible.


That would be especially important for servo drives that don't have  
separate control and power inputs where in an e-stop you'd be forced to  
kill all drive power, encoder counting probably stops happening, position  
info is lost and you're stuck re-homing or whatever else is required to  
check your offsets.



-Dave


On Wed, 10 Feb 2021 00:08:41 -0500, John Dammeyer   
wrote:



Quick question.

There's a multi-axis operation in progress.  For whatever reason one of  
the servos throws out a fault and of course stops.


Should just the enables to the other servo drives be removed or should  
power be cut to all drives.


I'm not really in favour of dropping out power because that would mean  
you also lose the ability to easily recover.  The other drives and  
spindle were working so you really just want them stopped and things  
like coolant shut off.


This isn't the same as an ESTOP which does remove all power that could  
result in motion.  Low voltage control and PC are left running.


For my PMDX-126 BoB my faults are consolidated and brings the PMDX  
/FAULT input low.  That disables the ChargePump which in turn disables  
all outputs including the enable to all the drive.  And the orange  
button beside the red one on the user screen goes greyed out.


After 4 seconds the /FAULT input is once again brought high (inactive)  
and now the orange ENABLE button on the screen (or F2) can be clicked  
which then asserts the ENABLE output to the drives and allows hardware  
to be controlled again.


For my servos taking the ENABLE signal FALSE and then TRUE resets the  
FAULT condition.   If the fault is still there then the /FAULT is  
brought low again. Etc...


What do other systems (including commercial) do when a drive faults on  
one axis.


John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users