Alfawise U20, M110
kfsone last edited by kfsone
It seems that the Alfawise U20 has some kind of dumbed-down version of Marlin, not 100% sure. When I connect MatterControl to it via USB it gets stuck in an infinite loop:
N1 M110 N1*125 ok N2 M105*37 Resend: 1 ok ok N1 M110 N1*125
"M110" sets the line number, and as best I can tell it affects what the next line number will be. So, after "M110 N1" you should send "N1", what should be happening is:
N1 M110 N1*125 N1 M105*39
Kinda - but on purpose it keeps setting line number to 1 then asks for the temp which in this case is 37, then sets the line number back to 1 and asks the temp. This is so it can display the temp on top. Otherwise imagine if it does it once a second and you leave it run for a day what the line count would be up to. I think it stops resetting the line count to 1 once you send actual Gcode- you can filter those messages out though. You will also so similar "loops" for polling the limit switches etc during execution of the code. Mine does it too and I think its by design. But then I did not write the software and am just a user
I'll have to edit it so you can see the '*'s: it never gets a response to M105 because it claimed it was N2 instead of N1.
Do you have the latest version cause I remember that being a bug a while ago. Can't check it on mine for the next 14 hours as there is a major print going on
(edited the original, should be clearer now)
18.104.22.16869, says its up to date.
If I interpret it correctly the N... Are the replies usually it goes like this
Client (computer) sends Gcode
N nnn G1 F1200
nnn is the line number then the gcode in this case set speed to 1200 mm/min is sent back and then and ok or error code.
you can test it by typing into the terminal some gcode even M110 or M105 and you should get it back with the next line number I am pretty sure the 37 after the star is your temperature.
I guess if it properly displays the temp and prints I wouldn't worry about it
kfsone last edited by kfsone
The 'N' values are actually line numbers being sent to the printer, added so that its possible to resume. When a connection starts, it's set to 1 - meaning the next line the printer anticipates is N1. However, that only applies to lines that have an N prefix, and lines that have an N prefix have to include a checksum which is designated by a '*'.
So if you were to do the following:
G20 G90 M106 S0
the N line-number count hasn't changed. If I wanted to send them as numbered (resumable) lines and query the temperatures in-between each one, I could do this:
N1 G20*26 M105 N2 G90*18 M105 N3 M106 S0*100 M105
at the end, N is 4.
If we were to resume, I'd do an "M110 N4" - and that's the important bit; here, they're setting N to 1 and then the next line they send is marked as N2.
Possibly - will check when my print is over. But I remember a couple of month ago a post on github about a line number problem that supposedly was fixed. Check if there are any updates. I currently only use MC to run the gcode and add the bed leveling. I do my actual slicing with SLIC3R
ah - after following a breadcrumb trail, it appears that it's a known issue with MC/Marlin (since 2017)
Guess it wasnt fixed then