On 11/5/2011 7:09 AM, Viesturs Lācis wrote: > 2011/11/5 Slavko Kocjancic<[email protected]>: > >> Hello... >> >> I think the 1'st thing is to check what is wrong. Not to do something to >> eliminate problem but not know what problem it is. >> > Yes, that is exactly my question - is there anything I can do to > diagnose the cause of problem? > > >> If EMC doesn't crash then motherboard isn't problem (CPU/RAM/ROM/S,N >> bridges...) so try to check where is problem. It can be somewhere betwen >> CPU bus (aka whatewer card you use for IO) throu motor driver board. >> Just I don't understand how you are can continue work on next piece >> after crash without rehoming? Do you have servo or stepper. In case of >> stepper there should be position loss so rehoming is mandatory. (Or you >> just tolerate absolute error as you touchof coordinate to part >> machined?) If that's true then jou maybe just have missconfigured >> configuration. Eg you measure latency and got for example 10us and you >> conclude that is it. But sometime some events thermal recalibration of >> HDD for example can cause little longer latency and jou hit the problem. >> And this occour in random time not periodic. Just put that pc with >> intensive work to measure latency for few hours to werify. If you have >> servo then EMI can be problem. (for stepper to but less possible as >> machine run long time without trouble). >> > Here is some data about the machine: > 4 MotionKing stepper drives with Mesa 7i43 for step generation. > PC is dual-core Intel Pentium CPU with 1GB memory, no idea about motherboard. > EMC version is 2.4.6 running on Lucid. > > These are the symptoms: > 1) EMC won't start running a file, when a PLC (currently controls > pneumatics, it will be removed eventually) sends a signal to do so. > In HAL file I have: > > net deb-in debounce.0.0.in<= hm2_[HOSTMOT2](BOARD).0.gpio.034.in_not > net oneshot-in debounce.0.0.out => oneshot.0.in > net oneshot-out oneshot.0.out => and2.0.in0 > > setp debounce.0.delay 5 > > setp oneshot.0.rising 1 > setp oneshot.0.retriggerable 1 > setp oneshot.0.width 5 > > net ready pyvcp.ready => and2.0.in1 > net start and2.0.out => halui.mode.auto halui.program.run > > Incoming signal from PLC is filtered through debounce and routed into > oneshot to watch for rising edge. > There is pyvcp button "Ready for work" for operator to enable EMC > following PLC commands. > > I have been watching these pins in "Show HAL Config": > hm2_[HOSTMOT2](BOARD).0.gpio.034.in_not > and2.0.out > halui.program.run > halui.program.is-running > halui.mode.auto > halui.mode.is-auto > > What I have observed: > There are cases, when EMC does not run a file, when PLC sends a signal > to do so - I can see that on GPIO pin and and2.0 output pin. > The thing is that pins that request changing to auto mode and running > a file are "true", but EMC does nothing. Resetting the GPIO pin > usually solves the situation. So EMC does behave unusually. > Blowing out the dust from all the cases - PC, monitor and the box with > Mesa card and stepper drives. EMC behaved correctly for ~30 minutes > and then this behavior started to repeat once in ~10 minutes. > > 2) One of the spindles takes a wrong path. > The work process is that operator places the material in fixture and > presses "Start" button - pneumatic cylinders hold it in place and > spindles conduct a movement, shaping both ends of material. Cylinders > release the material, operator takes the part out and puts the next > part in and presses "Start" again. > And then repeat this for hundreds of times. > > I have 2 joints hardcoded to X and other 2 joints hardcoded to Y in > kinematics module. > > The error is that sometimes one of the spindles (not the same spindle > all the times) moves less than needed along X thus ruining part. The > differene is ~1mm. > > Most surprising is that after such a wrong move next part is correct. > The thing is that deviance of 0.1 mm can already be seen on the part > due to the shape of the tool and the shape of the cut. > > I have a suspicion that this might be something connected with Mesa > card and magnetic field from VFD and also spindle motors, because > there is CRT monitor ~0,5m from spindle motor and the picture gets > creeped. It is good as soon as motor is turned off and gets creepy as > soon as it is turned on. The pattern of creepiness changes as the > motor moves. > > If there was a noise in step/dir signals, then the error should > remain. But the thing is that in all the cases it recovers and next > part is totally fine. > > The pattern for this error was something like this: > No error for first 40-50 minutes. > One part ruined. > Fine for 5-10 minutes. > One part ruined. > Fine for ~20 parts. > One part ruined. > Fine for 6 parts. > One part ruined. > Fine for 4 parts. > One part ruined. > Fine for 10-15 parts. > One part ruined. > Then I lost the track. > > Confirmed by supervisor - the tendency is that all these errors (and > they say that there are other errors that I was not able to observe > during 3 hours I was there) get worse and worse as the machine is > working. So if one shift (7 hours) somehow can work, then the night > shift comes in and in the morning there is almost nothing done. > Let the machine rest for few hours and then it can work for a while. > > > So is there anything I can do to diagnose the problem? > > Viesturs > > >
I didn't see your mention of VFDs initially. I have had some bad EMI noise problems with VFDs. I once had a 24 volt power supply that was feeding circuits to a VFD and the VFD was throwing out so much noise that the noise was migrating to other circuits through the 24 volt wiring. The same wiring was feeding an Allen Bradley Micrologix PLC which I was using to move a hydraulic servo valve - via the Micrologix step and direction outputs. The hydraulic cylinder was drifting around in position after many parts were processed. Turns out the noise from the VFD was scrambling the step and direction outputs circuitry of the Micrologix controller. It took a while to find that problem. The fix was to add a separate 24 volt power supply that fed only the PLC and the sensitive step and direction outputs, and use the original power supply for everything else, including the PLC non-step and direction related PLC outputs. What I did to verify that the VFDs were the problem was to run the machine without the VFD powered up - pull the fuses or unwire them.. Then try running parts for an hour or so. Remove the cutters if need be.. . If the problem vanishes you likely have an VFD related noise problem. If you find out that is the issue, start splitting your control circuits via additional power supplies, or use other AC feeds temporarily, to find a fix. If you have marginal grounding - then that will just make your system more susceptible to EMI issues. For some reason I have not had similar EMI issues with servo drives. Dave ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
