Home › Forums › TinyG › TinyG Support › Red flashing light when trying to adjust settings?
- This topic has 9 replies, 4 voices, and was last updated 4 years, 1 month ago by A.R.Martin.
-
AuthorPosts
-
February 19, 2020 at 10:46 am #11789AiricMember
Greetings,
I have gotten my new TinyG board installed in the last month or so. It worked perfectly when I got it, but has now gotten flaky. I have only done some test moves running in air; have not cut anything or used it under load yet.
Here is what happened:
I was getting a resumable error when I tried my first Gcode run. So I started changing things in the post processor to address this, as described in various internet posts.
One the many Gcode files that I created with different settings seemingly caused the TinyG to lock up, and it never recovered. It had the constantly flashing red light and was unresponsive. “Resets” and power cycles did not help.I cruised around and discovered that Synthetos has an “Updater” tool to reload or update code on the board. That seemed promising.
The first time that I ran the Updater, the TinyG will did not work. But the second time that I ran the Updater, the TinyG resumed working and seemed okay.
Except, that now I can’t change settings. When I issue a #tr command to adjust travel resolution or something, and then request a movement, the TinyG goes back into red flashing light behavior. BUT, a power cycle brings it back to working. Try again = repeat.
If I don’t adjust any settings, then it seems okay. It homes itself, and will run Gcode and move around through air without issue or error. But I need to be able to adjust configuration settings!
Something is not right? This is a brand new board that hasn’t been used yet, still being set up.
Any ideas what is happening, or how to address it?
(I sent a message with this same description to Synthetos via the website last week, and received no response.)
Thanks for any help!
February 20, 2020 at 9:20 am #11790cmcgrath5035Moderator(I sent a message with this same description to Synthetos via the website last week, and received no response.)
Sent via “Contact Us” ? I am supposed to be copied on those, did not see anything. Something there not working right.
I was getting a resumable error when I tried my first Gcode run. So I started changing things in the post processor to address this, as described in various internet posts.
What post processor are you referring to?
And please share your perception of a ‘resumable error’.
What CAM software are you using?(Chilipeppr, cnc.js, Coolterm, etc.)Do you have limit switches attached and enabled? Flashing red usually menas limit switch activated, causing a had stop of tinyG, recoverable only by reset (push button or power cycle). You could disable limit switches while you experiment with motion.
Spurious limit switch firing is usually attributable to wiring issues. Can you describe how you have the switches connected to tinyG?A look at yur parameters might be helpful.
Run $$ in a console, scrape the output to a text file, put the file on a Cloud share and provide a URL.February 21, 2020 at 11:35 am #11791AiricMemberI am post processing from HSMXpress.
cnc.js popped up questions saying ‘There is a resumable error. Would you like to continue running?’. I have since found the setting to ‘ignore resumeable errors’.The homing and limit switches work fine. The machine homes itself properly, and the limit switches kill it if they are tripped. Everything actually work brilliantly with no jitters or odd behavior – until I try to change a setting.
I am seeing errors at startup that I don’t remember (but I wasn’t paying attention in the past because it all worked great).
This is what the console shows when I connect:
————————————————————–
CNCjs 1.9.20 [TinyG]
Connected to COM4 with a baud rate of 115200
feeder> {ej:1}
feeder> {jv:4}
feeder> {qv:1}
feeder> {sv:1}
feeder> {si:100}
{“r”:{“jv”:4},”f”:[1,0,7,7333]}
{“sr”:{“posx”:0.000,”posy”:0.000,”posz”:0.000,”posa”:0.000,”feed”:0.00,”vel”:0.00,”unit”:1,”coor”:1,”dist”:0,”frmo”:1,”stat”:1}}
{“r”:{“qv”:1},”f”:[1,0,7,6003]}
{“r”:{“sv”:1},”f”:[1,0,7,9250]}
{“r”:{“si”:100},”f”:[1,0,9,2707]}
feeder> {spe:n}
{“r”:{“spe”:null},”f”:[1,100,8,8836]}
{“err”:{“code”:100,”msg”:”Unrecognized command or config name”}}
feeder> {spd:n}
{“r”:{“spd”:null},”f”:[1,100,8,6786]}
{“err”:{“code”:100,”msg”:”Unrecognized command or config name”}}
feeder> {spc:n}
{“r”:{“spc”:null},”f”:[1,100,8,4736]}
{“err”:{“code”:100,”msg”:”Unrecognized command or config name”}}
feeder> {sps:n}
{“r”:{“sps”:null},”f”:[1,100,8,704]}
{“err”:{“code”:100,”msg”:”Unrecognized command or config name”}}
feeder> {com:n}
{“r”:{“com”:null},”f”:[1,100,8,2342]}
{“err”:{“code”:100,”msg”:”Unrecognized command or config name”}}
feeder> {cof:n}
{“r”:{“cof”:null},”f”:[1,100,8,4826]}
{“err”:{“code”:100,”msg”:”Unrecognized command or config name”}}
feeder> {sr:{stat:t,line:t,vel:t,feed:t,unit:t,coor:t,momo:t,plan:t,path:t,dist:t,admo:t,frmo:t,tool:t,posx:t,posy:t,posz:t,posa:t,posb:t,posc:t,mpox:t,mpoy:t,mpoz:t,mpoa:t,mpob:t,mpoc:t}}
feeder> {sys:n}
feeder> {mt:n}
feeder> {pwr:n}
feeder> {qr:n}
feeder> {sr:n}
{“r”:{“sr”:{“stat”:true,”line”:true,”vel”:true,”feed”:true,”unit”:true,”coor”:true,”momo”:true,”plan”:true,”path”:true,”dist”:true,”admo”:true}},”f”:[1,100,181,722]}
{“err”:{“code”:100,”msg”:”Unrecognized command or config name”}}
{“r”:{“sys”:{“fb”:440.20,”fv”:0.970,”hp”:1,”hv”:8,”id”:”8U1122-MUJ”,”ja”:100000,”ct”:0.0100,”sl”:0,”st”:1,”mt”:2.00,”ej”:1,”jv”:4,”js”:1,”tv”:1,”qv”:1,”sv”:1,”si”:100,”ec”:0,”ee”:0,”ex”:1,”baud”:5,”net”:0,”gpl”:0,”gun”:1,”gco”:1,”gpa”:2,”gdi”:0}},”f”:[1,0,8,1385]}
{“r”:{“mt”:2.00},”f”:[1,0,7,1467]}
{“r”:{“pwr”:{“1″:0,”2″:0,”3″:0,”4″:0}},”f”:[1,0,8,9987]}
{“r”:{“qr”:32},”f”:[1,0,7,7766]}
{“r”:{“sr”:{“posx”:0.000,”posy”:0.000,”posz”:0.000,”posa”:0.000,”feed”:0.00,”vel”:0.00,”unit”:1,”coor”:1,”dist”:0,”frmo”:1,”stat”:1}},”f”:[1,0,7,3689]}
>——————————————————————-
And this is what resumeable errors look like:
{“r”:{},”f”:[1,0,9,4402]}
{“sr”:{“posz”:0.000}}
{“qr”:32}
> G2 X-0.4143 Y-0.0886 I0. J0.0554
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:41,”data”:”G2 X-0.4143 Y-0.0886 I0. J0.0554″}}
> X-0.3664 Y-0.0609 I0.048 J-0.0277
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:42,”data”:”X-0.3664 Y-0.0609 I0.048 J-0.0277″}}
> G3 X0.1571 Y0.0221 I0. J0.0554
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:45,”data”:”G3 X0.1571 Y0.0221 I0. J0.0554″}}
> X0.1092 Y0.0498 I-0.048 J-0.0277
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:46,”data”:”X0.1092 Y0.0498 I-0.048 J-0.0277″}}
> G2 X-0.4205 Y0.1329 I0. J0.0554
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:48,”data”:”G2 X-0.4205 Y0.1329 I0. J0.0554″}}
> X-0.3726 Y0.1605 I0.048 J-0.0277
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:49,”data”:”X-0.3726 Y0.1605 I0.048 J-0.0277″}}
> G3 X0.3303 Y0.2436 I0. J0.0554
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:53,”data”:”G3 X0.3303 Y0.2436 I0. J0.0554″}}
> X0.2824 Y0.2713 I-0.048 J-0.0277
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:54,”data”:”X0.2824 Y0.2713 I-0.048 J-0.0277″}}
> G3 X0.4205 Y0.4651 I0. J0.0554
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:61,”data”:”G3 X0.4205 Y0.4651 I0. J0.0554″}}
> X0.3726 Y0.4928 I-0.048 J-0.0277
{“err”:{“code”:155,”msg”:”Arc specification error”,”line”:62,”data”:”X0.3726 Y0.4928 I-0.048 J-0.0277″}}
client> {“qr”:””}
{“r”:{“qr”:32},”f”:[1,0,10,9617]}February 25, 2020 at 7:50 am #11792cmcgrath5035ModeratorSorry for delay.
I have no knowledge of HSMXpress and limited cnc.js experience.
Here are some more or less generic comments based on reported errors I see
Is your design in inch or mm? Frequently arc errors are the result of lost computation precision, made worse by repeated mm to inch conversions. tinyG uses mm as the native mode, so regenerating your Gcode in mm may help.
Or, changing the post processor to not use arcs will usually eliminate the arc errors.Are you making parameter tweaks then attempting to resume from the recoverable error? That is not likely to work. When such an error occurs, there is still a queue of pre-computed movements waiting to be executed based on the original parameter set. Resetting or power cycling tinyG will recompute the movements then using your modified parameters.
March 5, 2020 at 10:43 am #11793AiricMemberThanks for the reply.
The resumable errors problem is fixed – it was a decimal precision problem as you predicted, and is no longer a problem.
This is what the problem is now:
When I connect a console to the TinyG, I get errors that I don’t remember happening with my previous TinyG. I am working now with a new TinyG – order #5309, and the startup errors are shown in the previous posting above.The TinyG acts like it has come up okay, but when I try to change a $tr setting (to tweak travel resolution for example), the TinyG stops and goes into “flashing red light mode”. A power cycle brings the TinyG back to working again – until I again try to change a $tr setting.
I don’t believe that there is anything physically wrong with the TinyG, it homes and moves and runs Gcode as long as no $tr settings are changed, but it acts like something is wrong with the code on the board.
Should I run the Updater again to reload software? Or is it a firmware problem?
Thanks!
March 6, 2020 at 5:46 am #11794cmcgrath5035ModeratorI don’t think reloading FW is required or desired. AVRDUDE, the core downloader, does a check on the installed image, if it exits without error the FW image is most likely installed correctly and accurately.
As for the startup errors, I believe it is tinyG responding to cnc.js startup commands that it does not understand. Have you tried posting that sequence on a cnc.js forum? I am no expert and do’t have a machine to play on at the moment
Are you attempting to tweak $tr while a gcode file is running? You can’t do that.
March 10, 2020 at 9:23 am #11795AiricMemberI’m trying to tweak the travel resolution, so I have a caliper clamped to the rail to measure movement of the carriage. (not running G code, just moving an axis).
I turn on the rig, request a movement, look at the actual movement, then issue a different $tr value, and request the movement again to measure the change.
When I send the $tr command, it appears to work, but when I request a movement, that TinyG goes into red flashing mode. But it does come back after a power cycle.
I will try to use Coolterm instead of cncjs to see if anything is different.
April 17, 2020 at 1:14 pm #11819kiwigrantMemberThis is may not be related but during one episode where I got the red flashing LED of Doom I discovered that I was under powering the power supply onto the board.
If I recall the board appeared to be powered when you plug the USB but doesnt have enough juice to allow the board to function properly.
For what its worth…
April 18, 2020 at 10:56 am #11821cmcgrath5035Moderator@kiwigrant, I am a little confused by your powering from USB comment, are you running a tinyG V8 or an arduino of sorts?
V8 schematics are here https://github.com/synthetos/TinyG/tree/master/hardware/v8schematics
Power is on sheet 2. USB is terminated by the FTDI device (FT230) and it may push out some 3.3V to the 3.3V bus, but is not intended to run that way.- This reply was modified 4 years, 7 months ago by cmcgrath5035.
October 19, 2020 at 10:42 pm #11910A.R.MartinMemberAiric –
I’m also getting err 155 with cncjs and hsm expressMy origin file is coming from SolidWorks with native CAM – post set to tinyg
Are you able to change gcode to mm in hsm express or did you have to change at the geometry “SolidWorks” level
Thanks!
-
AuthorPosts
- You must be logged in to reply to this topic.