Re: [Emc-users] Dealing with Servo Faults
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
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
[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
Re: [Emc-users] machine opinion please
Point was to not let the current arrangement of equipment drive the selection of what new mill you can buy because for not a lot of money you can have the current arrangement of equipment changed. I'd guess the labor cost in rural Indiana is less than here in So Cal. If you are looking to get setup fast, if you buy a REALLY common knee mill you can buy bolt-on CNC conversion kits for it and you can know the final performance before you start the process. > I live outside of a small town of about 1000 in rural Indiana. When I > first moved her in the 90's, each morning about 6:30am a bunch of guys > looking for day work would gather outside a small grocery store in > town. Contractors (many of them Amish) were always looking for help > and they would swing by with their vans and pickup labor as required. > This went on for years. Sometimes there would be 50 guys there looking > for work. One morning, the INS setup a sting and arrested a number of > illegals looking for work.That was the end of that. The work didn't > go away, the labor market just went underground.There are a lot of > cash businesses around here. Some have significant workforces. > > > > > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] machine opinion please
On 2/7/2021 6:59 PM, Chris Albertson wrote: On Sun, Feb 7, 2021 at 9:41 AM Gene Heskett wrote: Space for it means pulling the crooked g0704 out before bringing it in. And more than likely hurting myself getting it backed into the space. But I think I'm a little smarter about such than I was 5 or 6 years ago putting the go704 where it is. Are there no Home Depot stores near you? If you drive by one you will find a good supply of day laborers waiting for work. In the early morning, they all seem to be hoping for a full day of work but after lunch, they will accept a one or two-hour job. You can hire an army of movers for a one-hour shop realignment. Four big guys can haul everything out, sweep the area, and put it all back in not much time. Then you have room for what you want. Around here, $20 per hour plus lunch is the going rate for that kind of unskilled labor. So $200 gets a lot of heavy work done. A few months ago I ordered 16,000 pounds of river rock and the delivery truck could only get it to within 50 to 60 feet of where it was needed. Heck if I was going to move that myself. I'm much younger than 80 but see no reason to move stuff like that myself. Once you get used to hiring these guys, big jobs like filing a stake bed truck with construction debris by hand are easy, You just say "put all this stuff in the truck" and it's done. I live outside of a small town of about 1000 in rural Indiana. When I first moved her in the 90's, each morning about 6:30am a bunch of guys looking for day work would gather outside a small grocery store in town. Contractors (many of them Amish) were always looking for help and they would swing by with their vans and pickup labor as required. This went on for years. Sometimes there would be 50 guys there looking for work. One morning, the INS setup a sting and arrested a number of illegals looking for work. That was the end of that. The work didn't go away, the labor market just went underground. There are a lot of cash businesses around here. Some have significant workforces. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] [Emc-developers] hal_pi_gpio config string
On Tue, 9 Feb 2021 at 13:28, Thomas J Powderly wrote:
> loadrt hal_pi_gpio pi_pins={,,,}{,,,}{,,,}
> each 'quad' consists of braces enclosed data
I think that the modparam handling struggles with embedded commas
inside a single element.
I would suggest:
loadrt hal_gpio config=12or0,1i,23i,...
ie, don't force the format too hard, but work on leading numbers
specify a header number, other code letters (in any order) modify the
behaviour.
Maybe R for reset high and r for reset low?
FWIW a parser like this exists in mux_generic.
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/mux_generic.c#L105
(note how each successive digit multiples the current number
(initially 0) by 10, and adds the new value, so 1, 01, 001 all mean 1)
--
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] hal_pi_gpio config string
I have been working on a new version of hal_pi_gpio.
It uses an array of structures to hold the features for each pin.
struct pinfo
{
hal_bit_t pval; // the last read value for inputs, the
desired output value for outputs
char pnum; // the rpi header pin number
char gpionum; // the gpio number for said pin number
hal_bit_t pdir; // input or output
hal_bit_t pinv; // wether inverted pin is wanted ( inputs only )
hal_bit_t pres; // wether reset feature is wanted (outputs only )
};
I have not implemented the invert or reset pins yet,
but want opinion on a single big change..
the change is about how you enter the config string.
The format I propose is simple:
the config string is a list of 'quad's as follows:
loadrt hal_pi_gpio pi_pins={,,,}{,,,}{,,,}
each 'quad' consists of braces enclosed data
1st pnum a 2 char string representing the rpi header pin number.
2nd is '>' or '<' representing input or output
3rd depends on input or output
if input '+' or '-' declare an inverted pin is wanted or not
if output 0 or 1 declare the initial state , and the state returned
to if 'reset' feature is designed
4th also depends on input or output
if input, this 4th fiel;d is not used, i suggest 'x' used to fill
the need for a single ignored char
if output, the 4th field is 'Y' or 'N' declaring the reset feature
is wanted or not
This way of describing the config string is more intuitive that the
current method
eg: dir=78855 exclude=32918520
So, what is the opinion about the config string format?
example run---
pi@raspberrypi:~/linuxcnc-dev/src $ halrun
halcmd: loadrt hal_pi_gpio pi_pins={03,>.0.Y}{05,>,0,Y}\
halcmd+: {07,>,0,Y}{11,<,+,x}{12,<,+,x}\
halcmd+: {13,<.+,x}{15,>,1,N}{16,>,1,N}\
halcmd+: {18,>,1,N}{19,>,1,N}{21,>,1,N}
Note: Using POSIX realtime
halcmd: show pin
Component Pins:
Owner Type Dir Value Name
4 bit IN FALSE hal_pi_gpio.pin-03-out
4 bit IN FALSE hal_pi_gpio.pin-05-out
4 bit IN FALSE hal_pi_gpio.pin-07-out
4 bit OUT FALSE hal_pi_gpio.pin-11-in
4 bit OUT FALSE hal_pi_gpio.pin-12-in
4 bit OUT FALSE hal_pi_gpio.pin-13-in
4 bit IN FALSE hal_pi_gpio.pin-15-out
4 bit IN FALSE hal_pi_gpio.pin-16-out
4 bit IN FALSE hal_pi_gpio.pin-18-out
4 bit IN FALSE hal_pi_gpio.pin-19-out
4 bit IN FALSE hal_pi_gpio.pin-21-out
4 s32 OUT 0 hal_pi_gpio.read.time
4 s32 OUT 0 hal_pi_gpio.write.time
halcmd: setp hal_pi_gpio.pin-21-out 1
halcmd: setp hal_pi_gpio.pin-15-out 1
halcmd: show pin
Component Pins:
Owner Type Dir Value Name
4 bit IN FALSE hal_pi_gpio.pin-03-out
4 bit IN FALSE hal_pi_gpio.pin-05-out
4 bit IN FALSE hal_pi_gpio.pin-07-out
4 bit OUT FALSE hal_pi_gpio.pin-11-in
4 bit OUT FALSE hal_pi_gpio.pin-12-in
4 bit OUT FALSE hal_pi_gpio.pin-13-in
4 bit IN TRUE hal_pi_gpio.pin-15-out
4 bit IN FALSE hal_pi_gpio.pin-16-out
4 bit IN FALSE hal_pi_gpio.pin-18-out
4 bit IN FALSE hal_pi_gpio.pin-19-out
4 bit IN TRUE hal_pi_gpio.pin-21-out
4 s32 OUT 0 hal_pi_gpio.read.time
4 s32 OUT 0 hal_pi_gpio.write.time
halcmd:
thx
tomp
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
