New server version causes crashes with all printers
Just updated to the latest version for Repetier Server and now I cant run a single print. On all my machines as soon as I kick off a print they all keep disconnecting and reconnecting.
This has shut down my whole farm and I have no option to roll back the changes. Please can you advise what to do here as I have a big backlog of orders I need to get through.
This has shut down my whole farm and I have no option to roll back the changes. Please can you advise what to do here as I have a big backlog of orders I need to get through.
Comments
But can you say what exactly the issue is? Is the server restarting due to some errors or are the printers it self reconnecting for some reason like EMI/Underpower. In new image we used latest bullseye compared to buster before. But at least on our systems it had no issues. YOu see this easily in server.log and syslog downloadable in printer logs for example.
1 machine is running skr 1.4, 1 skr 2 and the other machine running skr mini. All were absolutely fine on version 1.3.0
This will install the old version over the new one. This fixed all those issues for me. I really wish you guys would do a bit more testing on your releases. The bug report area is full of issues relating to 1.4.x
Thankfully I was easily able to roll back. I think ill use a separate pi for future updates just incase all hell breaks loose again.
N13 M75 CE5_16g_Mag_v3_9 Sunlu PLA 109g lw 0.4mm lh 0.28mm flow 100% if 40% ext1 215.0C bed 55.0C
has already 98 byte und there will be also the checksum added. I think marlin line limit is 96 byte so it does not fit generating the error message. So this error will only be visible with extraordinary long file names.
The change causing this was that in marlin.xml in firmare folder we changed
M75
into
M75 {{job.name}}
To show running job on printer. Will now reduce this to max. 20 chars to prevent such an overflow. So server is ok just the name causes overflow in marlin breaking communication. And too many errors then finally disconnect.
So thanks for providing the info for the reason so we can catch this in 1.4.3.
I also have trouble with v1.4.2, but for a FLSUN QQ-S Pro which has been unable to print new g-code uploaded, BUT it could print existing g-code (uploaded with v1.3.1) without any problems. On the console page, a lot of "Expected line nn got line xx" and "Resend line nn" was continuously displayed and it continued even after deactivating the printer. The same g-code causing the problem could be printed from a SD card without any problem. After downgrading to v1.3.0 (as shown by Festivejelly - thanks!) and re-uploading the troublesome g-code, everything works again!
On another note, the FLSUN QQ-S Pro claims to be running Repetier firmware (and Cura is set to produce Repetier g-code), but I have to set Repetier-server to "Marlin" in printer setup for it to work!
Do you mean uploads from 1.3.1 printed with 1.4.2 work and uploaded with 1.4.2 does not work? That would be strange since the gcode is th eunchanged original file we use. Only analysis differs as format for layer file has changed.
"Expected line nn got line xx" happens when buffer in printer overruns. Enable ping-pong mode or reduce input buffer size. Normally 127 is ok. Some need 63 some can do 255, some can not handle parallel commands in all situations and get in trouble which is when ping-pong helps. If you use old marlin you might need to disbale sending progress to lcd especially if it can not handle e.g.
M117 12:34:56
without error. Old versions did not allow : in strings as they are used for time.
M205 defenitely returns the eeprom contents.
So it looks like a repetier firmware. I think they use it for their Q5 as well as for the QQ-S Pro. But if the firmware is set to "Repetier" then the console will display this during the startup (with "Commands" enabled and just the first page of lines):
Regarding the serial (USB) connection, I can assure you that I have tried multiple connection settings, including Ping-pong mode as well as non-ping pong mode with various buffer sizes. Also, as mentioned it did print existing files without any errors :-)
But as it is relatively easy to go forward and back (if needed) in versions, I will check if I can reproduce the errors by updating to v1.4.2 again and let you know if it just was a bad update that was causing the problems or if the problems persists.
If you change protocol to ascii it should then also work with repetier after server restart. Then communication is using correct signals at least and might prevent some errors due to different handling in marlin.
Maybe you also got in 1.4.2 the same issue with long command line length as above. When file names are very long
M75 {{job.name}}
would generate mor ethen 96 chars breaking firmware parsing causing endless loop. repetier.xml does not have this, but uses M531 with filename. So if you have very long file names that could be the issue if it happens on print start.
I tried updating to v1.4.2 again and it still does not print when using the same settings as in 1.3.0, but neighter does the same print from v1.3.0 - so that observation was apparently not the true.
Using "ascii" in the "repetier.xml" file and changing "firmware" to "repetier" does fix the printing problem, But there are still a few "Format errors", so they are probably not using the newest firmware.
Thanks for your help!