Ignore due to resend errors, checksum mismatch, etc. after last server/host update

TT_Vert

This may be completely unrelated but I print quite often and this has never occurred until the last server update  to 1.1.2.   

• I'm running in win10 64bit
• I'm using Host V2.2.2
• I'm using Server V1.1.2
• Have not modified printer FW in years, have not touched USB cable in years
• Prints pause, but do continue and complete
• Never had this issue until this last update.  
• Occurs on any print now (Even a basic test print w/ 200 lines)
• Two different machines generate the same results
• Reseated USB 
• Rebooted Pi

These are some of the errors I get and it does pause when this occurs)

11:56:02.641 : Ignore due to resend: Error:Line Number is not Last Line Number+1, Last Line: 25

Error:checksum mismatch, Last Line: 2463 (lot of these w/ a different Last Line number)


Any help/input would be appreciated.

Dave

Repetier

New server is a bit more chatty. Due to multiple lines being send in parallel we can get multiple error messages from firmware. Now server tells you which it is ignoring due to an earlier message that already triggered a resend. So that is ok and just a response on a communication error. 

TT_Vert

Thanks for the response.  I though I posted this (I could not edit original post) but I should update, last night a job w/ a 25mm diameter vertical shaft offset itself about 2mm mid print so it is actually affecting the print jobs.  Also when the job pauses for a second and resumes it does cause print quality issues which i need to resolve.   In your opinion do you think it's  just a coincidence that this all started after updating to latest server version?  Any idea what I can do to further troubleshoot this?  I'm at 115,200 baud right now and have been for years w/o issue.  

Thanks for all the support throughout the years.
Dave

Repetier

The original problem is a communication error here. When you have disabled all helping hints in firmware (marlin normally has anything that helps hosts disabled except busy messages) com errors will sooner or later cause a stop until timeout is reached.

If you have ping pong disabled it helps if marlin has sending line numbers with "ok" enabled. Then we can normally detect a missed "ok" on the fly and correct it without pause. Also activating the "wait" message reduces maximum pause to 1s instead of timeout seconds. Simple checksum errors should be fixed fast enough to have no or only tine move breaks without modification. Good configured firmware will not loose steps from this since path planner stops gracefully except when it hits a fat blob maybe.

I do not really think it is version related. Still printing without much com errors my self. But that also depends on the printer, usb cable, cable shielding, where usb cable is positioned. Sometimes even a different usb port or baud rate can reduce error rate. There are many ways that can have an influence.

TT_Vert

i do not have ping/pong mode on.  it was off and I have no idea what it does so I haven't touched it.  if you think it'll possibly help I'll try it (Is this something configured w/in printer or can just toggling it in server do that?).  Is there  a way for me to easily revert back to an older server version as a test?  Also is there a host/server import/export option of settings yet?  I didn't see it but that's not to say I didn't miss it.  I really do need to troubleshoot this pausing on prints for a split second at least once a layer as it's causing significant print quality issues on the exterior of my prints.   

ThanksD
Dave

Repetier

Do you have timelapse activated? If you enforce a position you will get a pause once per snapshot, but no com error for this. It is just to sync position with image.

You can manually install 1.0.4 for backtesting. It will possibly remove new settings added and upgrading will then add them again with defaults, but it should work without breaking operation. Please enable logging and safe the logs for comparison. Only thing I know is that we are a bit more chatty then in the past, but I think that was already in 1.0.4 the case.

TT_Vert

Thanks for the reply!  I do not have time-lapse on.  After you mentioned the config tests I ran test multiple configs and this is what I got, I'm currently using the 127b buffer and it is RED.   I don't know what to make of this, nor do I know exactly what ping-pong mode is but it looks like the 63b buffer is green w/ no resends.  Should I switch to the lower buffer?  Will I risk buffer overruns doing this?  It may not even be a thing anymore but I know w/ old serial okidata dot matrix printers we ran into lots of buffer overrun issues.    I wonder why i was able to be at 127b before w/o issue and now it seems i need to reduce it.

This is what I see in the test area:
https://cfbinc-my.sharepoint.com/:i:/p/dave/EQpbjrnFw41Ahzd9bQb3XNgBD7d01uhcZhoj9GptB9-wCQ?e=NnpZWl

Thanks
Dave

Repetier

First you should repeat the test a few times to see if it is consistent and not a random case. Most firmwares have 127 byte but in the past when arduino library reduced buffer to 63 there were quite some firmwares having that limit.

Ping-Pong means send one command and wait for firmware answer "ok" and send next. The others with buffer send multiple command sin parallel to speed up communication. But when firmware looses parts of it due to not being able to buffer it you get com errors just from not enough space. So when disabling ping pong it is crucial to know the buffer size so it does not overflow.

Also if you can send 2 commands in parallel one missed "ok" will not cause a pause. Only when a command comes that does not fit into remaining buffer - then you get a timeout and server assumes this case and continues to fix it.

But best is always of course to not get any errors if possible.

So if it gives consistent errors on 127 use 63 or ping pong mode.

TT_Vert

I switched to 63b and it's been working flawlessly.  Oddly I did run the test a few times and I did see that 63b could not communicate when I ran the test a 2nd time.  Even more oddly the 127b test one time showed zero errors.  Nothing in my FW on printer has changed in 5 years so I am unsure why this would be an issue just after repetier server update but who knows if it's really related or just an odd coincidence.

I have sent you a donation for your time.
Dave