On Thursday 30 June 2016 19:28:47 Gene Heskett wrote: > On Thursday 30 June 2016 17:18:00 Sebastian Kuzminsky wrote: > > On 06/30/2016 01:53 PM, Gene Heskett wrote: > > > You guys all know I don't mind loseing a drop or two of virtual > > > blood while running the bleeding edge stuff, but other than > > > expenses like this, I don't mind playing the part of the canary in > > > WV cal mine. > > > > > > gcode pgm attached. May be buggy... > > > > > > LinuxCNC version: 2.8.0-pre1-2239-gb97a7ca, axis interface, Dell > > > Dimension 745 computer, 5i25 interface card. > > > > 2.8.0-pre1-2239 is just after the JA merge, so huge thanks for test > > it and reporting on what you find. This is the first step to > > getting bugs fixed. > > > > > lathe. Seeing that it isn't cutting quite like I wanted, I have > > > hit the stop button, or the esc key twice today. It takes a while > > > to stop from either key, noticeable second+ lag before everything > > > gets quiet. And 10+ seconds or more to get the screen unghosted. > > > And as the screen is unghosted, the DRO will jump to bogus values > > > for all 3 axis's but so far has not exceeded the range of the > > > program. > > > > I also saw something like this problem on 2.8.0-pre1-2239. I > > recorded my observations here: > > > > https://github.com/LinuxCNC/linuxcnc/issues/96 > > Thats a different kettle of fish, or sure seems so to me, Sebastian. > > > > But just about the time I am clicking on file->edit button, I hear > > > a snap crackle pop from the machine, so I look over at it and find > > > its driving Z another random amount, might be up 5% of the time, > > > might even include x or y or both, but 95% its z down, minimum > > > observed DRO value after I get it stopped was -0.140tysomething > > > but was -0,450tysomething once while cutting air to make sure I > > > was seeing what was going on after I had made trash out of a SC > > > mill with about 15 minutes use on it, For the second time today. > > > > > > Twice in my air cutting just now, this slow creep at maybe f2 > > > speeds has also moved the x or y too. > > > > > > Do I need to call ghostbusters? :) > > > > Yikes! I'm sorry that happened. I never saw any unexpected machine > > motion in my testing, what you saw is way worse. > > > > I'll be looking into this bug. > > See what you get with a simulated stuck key. I just recalled after the > last instance that the form fitting swarf cover on that keyboard was > holding the esc key at an odd angle, and lifting that corner of the > cover allowed it to pop back up to level. Lack of a keyup from the > keyboard can do strange things. Sure, it does a decent job of keeping > the swarf caused jams under control, but I'm beginning to think about > exploring some sort of lube as it sticks to the vertical sides of the > keys and may be creating more problems than its preventing. The > stickage reminds me of jo's blocks. Logitech k-360 keyboards at least > have keytops with vertical sides, so they don't jam down near as often > as a tapered sided key where the swarf follows the key down and wedges > it down. And the air hose will NOT clear that SOB. > > Other keyboards might, probably will do differently, but the stuck key > test could also be informative. > > Now, I need to go see if my lady needs a nose bag, I sure do. After > that, I'll go rip off that cover & retest in air. And if that was it, > we may be able to call in the dogs on this one. You should hear one > way or the other in 2 or 3 hours. > > Cheers, Gene Heskett
Got that taken care of although there was too many potato's in the potato salad, so my glucose is probably north of 200. I went back out, took the cover off & dbl-checked for depressed keys, but didn't find any. Ran it 4 or 5 times, and got post shutown motions every time. Stopped LCNC & restarted it, same old, rebooted the computer, ran LCNC, homed it, reloaded the code, ran it until it had made the first stepdown in depth, clicked stop. Seemed to stop ok, but it was several seconds unghosting the controls, and when it did, the DRO jumped, and the machine started a z down, my guess is till it matched what the DRO said, then stopped, but the DRO was frozen at those readings until it finally stopped. Re-ran the program, and let it run longer, hit esc. Response was the same, starting the erroneous moves from the instant the screen was unghosted, and the dro jumped to bogus values, up to about 10 seconds later than that, again without any change in the dro display. At least once I could discern that in addition to Z, the table was also moving quite slowly. Sorry to be the bearer of bad news, but I believe I have a real problem unless you can see something bogus in my gcode. 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) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
