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 ------------------------------------------------------------------------------ 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
