Home › Forums › TinyG › TinyG Support › TinyG Lockup
- This topic has 6 replies, 3 voices, and was last updated 10 years, 4 months ago by perfectphase.
-
AuthorPosts
-
June 29, 2014 at 9:58 pm #6285perfectphaseMember
I’ve been playing around with TinyG 435.7 and found a scenario that locks up TinyG. Not sure what the procedure for submitting bugs are, but you can reproduce it with the script below.
Text in bold is what I typed
{“r”:{“fv”:0.970,”fb”:435.07,”hp”:1,”hv”:8,”id”:”2U2971-YKY”,”msg”:”SYSTEM READY”},”f”:[1,0,0,5141]}
{“qr”:28,”qi”:1,”qo”:1}
g0x10y10
{“r”:{},”f”:[1,0,9,4402]}
{“sr”:{“line”:0,”posx”:0.000,”posy”:0.000,”posz”:0.000,”posa”:0.000,”feed”:0.00,”vel”:0.01,”unit”:1,”coor”:1,”dist”:0,”frmo”:1,”momo”:0,”stat”:5}}
{“qr”:27,”qi”:1,”qo”:0}
{“sr”:{“posx”:0.004,”posy”:0.004,”vel”:12.61}}
{“sr”:{“posx”:0.057,”posy”:0.057,”vel”:85.79}}
{“sr”:{“posx”:0.229,”posy”:0.229,”vel”:235.17}}
{“sr”:{“posx”:0.616,”posy”:0.616,”vel”:428.59}}
{“sr”:{“posx”:1.256,”posy”:1.256,”vel”:646.41}}
{“sr”:{“posx”:2.088,”posy”:2.088,”vel”:825.05}}
{“sr”:{“posx”:3.142,”posy”:3.142,”vel”:948.63}}
{“sr”:{“posx”:4.236,”posy”:4.236,”vel”:995.57}}
{“sr”:{“posx”:5.412,”posy”:5.412,”vel”:999.47}}
{“sr”:{“posx”:6.575,”posy”:6.575,”vel”:970.43}}
{“sr”:{“posx”:7.611,”posy”:7.611,”vel”:877.00}}
{“sr”:{“posx”:8.545,”posy”:8.545,”vel”:707.65}}
{“sr”:{“posx”:9.219,”posy”:9.219,”vel”:505.51}}
{“sr”:{“posx”:9.680,”posy”:9.680,”vel”:292.35}}
{“sr”:{“posx”:9.913,”posy”:9.913,”vel”:123.00}}
{“sr”:{“posx”:9.989,”posy”:9.989,”vel”:29.57}}
{“sr”:{“posx”:10.000,”posy”:10.000,”vel”:0.53}}
{“sr”:{“posx”:10.000,”posy”:10.000,”vel”:0.00,”stat”:3}}
{“qr”:28,”qi”:0,”qo”:1}
g54
{“r”:{},”f”:[1,0,4,4397]}
g56
{“r”:{},”f”:[1,0,4,4397]}
{“sr”:{“coor”:3}}
g55
{“r”:{},”f”:[1,0,4,4397]}
{“sr”:{“posx”:-40.000,”posy”:-40.000,”coor”:2}}
{“pos”:””}
{“r”:{“pos”:{“x”:-40.000,”y”:-40.000,”z”:0.000,”a”:0.000,”b”:0.000,”c”:0.000}},”f”:[1,0,11,7668]}
g10P2L2x10y10
{“r”:{},”f”:[1,0,14,73]}
{“sr”:{“posx”:0.000,”posy”:0.000}}
{“sr”:””}
{“r”:{“sr”:{“line”:0,”posx”:0.000,”posy”:0.000,”posz”:0.000,”posa”:0.000,”feed”:0.00,”vel”:0.00,”unit”:1,”coor”:2,”dist”:0,”frmo”:1,”momo”:0,”stat”:3}},”f”:[1,0,10,5000]}
g54
{“sr”:””}
{“pos”:””}
{“pos”:””}
Dead?!?Cheers,
Stephen.
- This topic was modified 10 years, 4 months ago by perfectphase.
- This topic was modified 10 years, 4 months ago by perfectphase.
June 30, 2014 at 8:57 am #6294cmcgrath5035ModeratorAs long as you are using DEV build, try 435.08.
Also, post a link to a text file with your configs:
Enter $$, save results to a dropbox or equiv.June 30, 2014 at 4:54 pm #6298aldenMemberI tried this on 435.07 (and 435.10) and did not see a lockup or anything else unusual. Can you please post your settings? A $$ dump is fine. Thanks.
June 30, 2014 at 7:11 pm #6300perfectphaseMemberHi all, thanks for taking the time to respond.
I have updated to 435.10. Still locks up, here is a modified sequence that causes a problem
http://pastebin.com/0HwGTazR
http://pastebin.com/BzCuAa2HA dump of my config is http://pastebin.com/zbXCnZ6Y
I’ve also noticed I’m getting ‘prep_null encountered’ quite a bit, for example
Hope that helps a bit.
Thanks
Stephen.
P.S. I notice from the startup and commits that the defaults have been changed so $defa in 435.10 loads the defaults for the Shapeoko 375mm rather than the “Default settings for release” profile.
July 1, 2014 at 6:50 am #6306aldenMemberI think you have found a bug in the way G10 works. The work-around for now is to use the $g55x=… format instead, which does the same thing.
July 1, 2014 at 8:53 pm #6314aldenMemberI found the cause of the lockup. I posted a fix that is still under test if you are interested in trying. I’ll push to edge once I’m satisfied with it.
https://www.dropbox.com/s/l43pohzcgchhhap/tinyg_435.14_dev.hex
It’s pretty low-level what was going on. Certain chips in the AVR Xmega series require a work-around to write to EEPROM (or any non-volatile memory, also including FLASH). This requires all interrupts to be turned off for the duration of the write, about 20-30 ms. The G10 function is therefore written to defer persisting the changed coordinate offset values until after the machining cycle, as this would stop the stepper interrupts and hence the motion. But due to a change in the way I run cycle ends they were being called from an interrupt during the finalization of the machining cycle, causing a deadlock. I moved the persistence to the main controller loop as a callback and the problem went away. Thanks for finding this.
July 3, 2014 at 10:23 am #6317perfectphaseMemberThat’s awesome, thanks. I’m traveling at the moment, will have a play when I get home.
-
AuthorPosts
- You must be logged in to reply to this topic.