Error:Missing linenumber

Printer Support
#1

Hi, I have a Hesine M505 Printer with the latest self-compiled Repetier 0.92.8 firmware (latest pull as of this post, March 14th). I get through a print OK, then after Astrobox changes state from “Printing” to “Operational” things go haywire and I need to perform a physical reset of the printer for Astrobox to get a connection back. I suspect the error is with Astrobox. Anyway, the serial.log indicates;

2016-03-15 03:05:46,589 - SERIAL - DEBUG - Changing monitoring state from ‘Printing’ to ‘Operational’
2016-03-15 03:05:46,910 - SERIAL - DEBUG - Recv: X:0.00 Y:85.78 Z:1.950 E:0.0000
2016-03-15 03:05:46,922 - SERIAL - DEBUG - Recv: ok 4058
2016-03-15 03:05:46,942 - SERIAL - DEBUG - Recv: T:189.71 /0 B:49.12 /50 B@:255 @:0
2016-03-15 03:05:46,959 - SERIAL - DEBUG - Recv: wait
2016-03-15 03:05:46,965 - SERIAL - DEBUG - Send: M140 S5.000000
2016-03-15 03:05:46,977 - SERIAL - DEBUG - Recv: wait
2016-03-15 03:05:46,983 - SERIAL - DEBUG - Send: M104 S5.000000
2016-03-15 03:05:47,002 - SERIAL - DEBUG - Recv: Error:Missing linenumber
2016-03-15 03:05:47,008 - SERIAL - DEBUG - Changing monitoring state from ‘Operational’ to 'Error: Missing linenumber
2016-03-15 03:05:47,018 - SERIAL - DEBUG - Recv:
2016-03-15 03:05:47,030 - SERIAL - DEBUG - Recv: Resend:4059
2016-03-15 03:05:47,039 - SERIAL - DEBUG - Recv: ok
2016-03-15 03:05:47,055 - SERIAL - DEBUG - Recv: Error:Missing linenumber
2016-03-15 03:05:47,062 - SERIAL - DEBUG - Recv:
2016-03-15 03:05:47,075 - SERIAL - DEBUG - Recv: Resend:4059
2016-03-15 03:05:47,085 - SERIAL - DEBUG - Recv: ok
2016-03-15 03:05:47,195 - SERIAL - DEBUG - Recv:

If anyone knows any quick edits I can make, let me know. It appears that when Astrobox tries to set the heat bed target to S5.000000, the printer doesn’t come back and say “ok 4059”, but just “Ok” without the line number (hence missing line number). Changing the monitoring state from “Printing” to “Operational” does it need to require the OK sequence number? Thanks for Astrobox, it is awesome!

Wanhao Duplicator i3 issues
#2

Something has gone ‘wrong’ between Repetier Firmware and Astroprint.

See this forum discussion:

I have been fighting this for a while. My current fix is a bit of
odd end code and the hack to Repetier so that line numbers are not always required. I am not sure the hack is required with the end code but the hack alone is not sufficient in my experience.

1 Like
#3

Yes, it is an odd that repetier started requiring all commands to have line numbers. This is wrong in my opinion. Why would line numbers be required when you’re moving the head around, preheating, etc.

I get the value of line numbers during a print but don’t think they should be required always. Does this happen with the latest repetier firmware?

#4

I can see the reasoning behind always having a line number but I agree also it seems odd for free moves to require them…The reasoning I can see for having them is error correction and resends etc.

However I just updated to Astrobox .86 and I have Repetier Firmware from a week or so ago and just did my first print…so far even without the end code things seem to have finished and maintained the connection.

Oddly however my Astrobox can now not connect to the astrobox web site…nor can I send a file from the web to the astrobox. Not exactly sure when that happened maybe with the update.
The astrobox can actually communicate online as I am controlling it remotely using the ‘inbox’ web controls.

My Astrobox now communicates with the AstroPrint website…seemed to require a full power cycle to make contact again…or something else just changed elsewhere.

#5

I just downloaded a fresh copy of Repetier Firmware and installed it on my printer, I had things working pretty well but wanted to test without the firmware patches I had made along the way.

My disconnection problems have returned…serial logging indicates that it does seem to be the line number ‘bug’ again…I will recompile the same firmware files with just the patch that doesn’t require line numbers if they have been used previously. If I upload this and the problem goes away then I think we can pretty much assume that the problem lies with this new line number requirement if line numbers have ever been used.

I note that Repetier doesn’t actually always require line numbers just that once you start using them you can’t stop. Which I think Astrobox uses line numbers when running a job but then once it goes back to simply polling the printer for temp status it no longer uses them…which sorta makes sense but Repetier doesn’t know the job is done and thus keeps expecting the numbers.

I am wondering if there is some switch in the firmware via an M command that can make the firmware reset to the line number optional state it starts up in. Something like placing the printer in standby mode. I may experiment with this or take a look at the source code to see if it is possible before repatching…

2 Likes
#6

I’d love to be able to check out your patches.

#7

I am currently running un-patched Repetier 0.92.8 (I will post the relevant patch in my next post.)

I have not found a good want to cause the reset of the line number requirement, but what seems to work is to add an M112 to the finish code…this forces a printer kill and reboot, at least on my configuration. The result is the printer goes back to it’s initial state and doesn’t require a line number at least until the next line number is used, which is typically when the next program is run which then terminates with the M112…adding to the kill code also seems to be a good idea and not just for the one number issue.

1 Like
#8

Joseph…following is the patch that removed the line number requirement.

This function is in “gcode.cpp”

/**
  Check if result is plausible. If it is, an ok is send and the command is stored in queue.
  If not, a resend and ok is send.
*/
void GCode::checkAndPushCommand()

if you remove the code starting at line 225:

else if(lastLineNumber) { // once line number always line number!
		if(Printer::debugErrors())
        {
			Com::printErrorFLN(PSTR("Missing linenumber"));
		}
		requestResend();
		return;
	}

Then Repetier doesn’t not require the line numbers even if it previously got one.

There might be more elegant ways of doing this, and I am considering making this a official request, though perhaps adding an command to simply reset the line number status would be better.