> 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
