On Thu, 19 Apr 2012, Viesturs L?cis wrote: > Date: Thu, 19 Apr 2012 15:20:09 +0300 > From: "[UTF-8] Viesturs L?cis" <[email protected]> > Reply-To: "Enhanced Machine Controller (EMC)" > <[email protected]> > To: "Enhanced Machine Controller (EMC)" <[email protected]> > Subject: [Emc-users] 2 issues with LinuxCNC > > Hello, gentlemen! > > I have 2 strange things about LinuxCNC, I hope that someone can help > me out with an advice. > > First is that the machine has only servo thread and servo period set > at 500000 ns (running at 2 kHz). About a minute after starting > LinuxCNC, I get "realtime error, check dmesg for details". The strange > part is that in dmesg output I see this: > > [ 1002.729793] In recent history there were > [ 1002.729796] 1004274, 805509, 913005, 901971, and 902286 > [ 1002.729798] elapsed clocks between calls to the motion controller. > [ 1002.729805] This time, there were 968040 which is so anomalously > [ 1002.729808] large that it probably signifies a problem with your > [ 1002.729810] realtime configuration. For the rest of this run of > [ 1002.729813] EMC, this message will be suppressed. > > The machine consists of: > D525MW board > 2 gb of ram > 4 gb cf card for hdd > Mesa 5i23 with 2 7i39s > On top of it there is Lucid and fresh install of 2.5.0 version. > It has hyperthreading disabled in bios and also isolcpus=1 in grub settings. > Increasing servo period to 750000 does help avoiding that error message. > > The 2 things that I do not understand are: > 1) why are values 1004274, 805509, 913005, 901971, and 902286 > considered as acceptable, but 968040 is not acceptable, given that one > of those acceptable values is bigger than this one. > 2) I had set servo period to 500000 ns, but this is not even close to that. > > I have latency test running now (not very long, 10 minutes maybe) and > max servo period (1 ms) jitter is 11281 ns, max jitter for 25 us base > thread is 14312. > How do I run "glxgears"? Pressing alt+f2 and typing glxgears and > pressing enter gives error message about error stating file, no such > file or directory. > > > > The second strange thing is: > Previously this machine had 2.5.pre buildbot version (cannot tell, > which exactly, but somewhere from winter). > Approximately 6-8 weeks ago I had situation, when LinuxCNC stopped > showing changes of gpio pin state - not limit/homing switch, not > encoder signal inputs, nothing. It was working just fine and then > turning machine on after several hours of resoldering encoder wires it > just was not showing anything. I thought that it was problem with 5i23 > card, so shipped it back to Mesa and received it back this week. > Today I put the card in and it still was not responding to any changes > in gpio pin state - I measured on the back of the card (where the legs > of P3 connector stick out of pcb) with multimeter that limit switches > drive that pin from 0,35 V to 5,03 V and back, so the signal was > received on the card, but in "Show HAL config", in "Watch" tab not > that nor any of the neighboring pins did not change their state. > I already thought that the card is still bad. > But then I somehow figured to install the 2.5.0 version and it started > showing the changes to input pins. It shows the change of joint > position, if I turn the servos by hand and I see limit switches > working. > The motors still do not want to move. Not even steppers. Does anyone > have any idea, what might be wrong? Everything was working before that > initial "stop responding to input pins" situation and I have not > changed anything in the configs or wiring. > > Viesturs
This does rather sound like a watchdog issue (no outputs working) Note that the 5I23 card returned to you was damaged in the field by excessive input voltage (>7V is normally needed to damage the input bus switches which was the situation with your returned card) If you still have a overvoltage situation, this can disable a whole connector of pins at the bus switch for that set of 24 pins. I would check the I/O on the FPGA with nothing else connected ,and check your signal sources carefully for overvoltages Peter Wallace Mesa Electronics ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
