On Saturday 18 January 2020 16:09:38 Peter C. Wallace wrote: > On Sat, 18 Jan 2020, Gene Heskett wrote: > > Date: Sat, 18 Jan 2020 15:58:23 -0500 > > From: Gene Heskett <ghesk...@shentel.net> > > Reply-To: "Enhanced Machine Controller (EMC)" > > <emc-users@lists.sourceforge.net> > > To: emc-users@lists.sourceforge.net > > Subject: Re: [Emc-users] I'm back to a sseriel failure that can only > > be fixed with a full powerdown of the whole system. > > > > On Saturday 18 January 2020 15:07:35 John Dammeyer wrote: > >> Hi Gene, > >> > >> I've run into similar problems with my system as I try and make it > >> intrinsically safe. The issues I've run into involve the various > >> levels of intelligence in the hardware. I don't know if your 7i76 > >> can solve your problem since I'm not familiar with it. > >> > >> As I've said before I'm using the PMDX-126 Break Out Board which > >> was really more designed around MACH3 than LinuxCNC. Obvious > >> because the two ribbon cable connections and 4 mounting holes are > >> designed to hold the Smooth Stepper. (USB or Ethernet). Still > >> haven't connected second port on the MESA 7i92. But that's a > >> different story. > >> > >> One of the 'features' of this BoB is the Charge Pump input. MACH3 > >> can generate this on any parallel port pin with a checkbox and can > >> even keep it running during the ESTOP IN (Pin 10 normally) by > >> checking a box in the main config screen. > >> > >> Under Linux CNC this is generated with stepper driver #4 > >> net machine-is-enabled => hm2_7i92.0.stepgen.04.enable > >> > >> The BoB, when configured to use a charge pump shuts off all outputs > >> when the charge pump vanishes. This includes the machine enable > >> signal (Pin 1). Under Linux this is: setp > >> hm2_7i92.0.gpio.000.is_output true > >> net machine-is-enabled => hm2_7i92.0.gpio.000.out > >> > >> Since the BoB has a couple of relays, one of them (SPDT) normally > >> allocated to motor direction or coolant, uses the NO contacts to be > >> in series with the ESTOP switch on the machine and feeds into the > >> ESTOP input (Pin10) on th BoB. If the Charge Pump vanishes, the > >> BoB itself takes care of shutting off the outputs which is like > >> mechanically hitting the ESTOP. > >> > >> Same with the limit switches. A FAULT (or NC ESTOP opening) input > >> into the BoB also causes all outputs to shut off. A small micro > >> removes that FAULT 4 seconds later but the system ENABLE > >> (controlled with the F2 power button) remains off after this. > >> AC/DC power is returned to the motors and the system. > >> > >> The problem I ran into was the FAULT or ERROR output from the > >> various motor drivers. A missing power supply voltage caused a > >> fault on the STMBL AC Servo drive. Something wrong on the DC > >> HP_UHU servo drives causes a FAULT. In all cases that shuts OFF > >> High Voltage power and then ON again. To reset the STMBL I have > >> to bring the ENABLE FALSE and TRUE. That's Pin 1 and done with the > >> F2 button on the user display. > >> > >> The HP_UHU drives were more problematic. They don't have an > >> enable. To clear a fault you either cycle 16V low voltage power or > >> bring the processor reset pin low. I did that with the NOT ENABLE > >> signal and a couple of opto coupler open collector transistors. > >> Now when not enabled the DC Servo drives are held in reset. And > >> it's true, HV DC and a shorted transitor driver pair could keep the > >> motor running open loop so still not the safest. > >> > >> I first tried enabling the high voltage with the system enable. > >> This created a race condition for both drives. The STMBL was > >> enabled but High Voltage wasn't there yet so it created a fault > >> which shut off the HV. Circular problem. > >> > >> The HP_UHU drive, when reset is released, blips the FAULT which > >> shut off high voltage again resulting in ENABLE going false which > >> again held the drive in RESET. > >> > >> SO the issue is that just after a reset or HV DC power being > >> restored both the STMBL and the HP_UHU blip their fault line. That > >> shuts off the BOB which removes the HV. Then when the HOV is > >> re-applied it starts all over again. Vicious circle. Hence the 4 > >> second delay before power is restored but the enable is held off > >> keeping all the servo drives either reset or not enabled. > >> > >> Once the ENABLE is set true, the FAULT from the drives is blocked > >> for a few seconds to allow the random start up faults to fix > >> themselves. All done with a PIC12F609 8 pin processor. > >> > >> For real safety I need to add a latching relay circuit that > >> requires a manual energize button to latch it on. So anything > >> that shuts off the HV opens this relay. And a button must be used > >> to relatch it. The original mill hardware has that on the Spindle > >> and Coolant switches. An ESTOP requires both switches set back to > >> OFF before the released ESTOP restores power. > >> > >> So for your system, look at a charge pump as a method of resetting > >> hardware. Then a relay wired in such a way that you have to > >> manually close the latching circuit to lock that relay closed. An > >> ESTOP or missing charge pump or even Limit switch can remove power. > >> All your switch has to do is momentarily close this relay and a > >> second pair of contacts will hold it closed. Since the primary > >> contacts on this CAN be part of the ESTOP NC circuit a machine > >> FAULT like a limit switch or motor driver automatically causes a > >> removal of voltages. And, like untwisting the ESTOP switch, you > >> need to press a physical ON button to relatch power. > >> > >> Hope that makes sense. > >> John Dammeyer > > > > For you it does, but without going to a separate parport, and using > > it to control power to the interface box and resetting the 5i25 > > jumpers for remote power from the boxes own supply, its a chicken v > > egg problem. > > > > IOW I can't use a signal that has to pass thru the interface, to > > control the power to the interface, And even then with logic power > > coming in from the 5i25, will that leakage prevent the full drainage > > to zero that is needed to fully recover the substrate scr someplace > > in the 7i76D. Thats not what happened this time as the 12 volts > > remained good, whereas on the 6040, the 12 volts was being crowbared > > by this not on the schematic scr, but this time it was not. > > > > Maybe Peter has conjured up a theory by now, but I've not. > > Not really other than possibly some 5V issue ( a shorted cable 5V > might cause this kind of flaky behaviour due to PTC cycling and > dropping the bus isolator power, losing communication ) We have close > to 10000 systems in the field using the sserial code used on the > 7I76/7I77/7I84 and we have never heard of such an issue before. A SCR > latchup would destroy the driver chips even with a .5A supply so its > not likely thats an issue > I am moderately convinced its related to the 12v field power, which I am not capable of shutting it down independently atm.
Which power src actually runs the serial link? On the 6040 interface, when it died, once I climbed the ladder I could see two leds blinking at about 1 10ms blink a second, one on the supply and the field pwr led on the 7i76its running since with a free wheeling diode across a relay coil that I didn't put in originally. That is the only change. This short caused by swarf wedging itself across the bottom of the y home switch didn't put a crowbar on the 12 volt line after the swarf was removed. Rebooting the computer didn't fix it, but a full powerdown did. I could pull the supply to field power wire but there are cautions about that in the doc, presumably as that would damage things with the nanosecond current rise times as its reconnected. So I've not gone down that path. But both missbehaviors involved the 12 volt, 1.15 amp supply. 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
