The issue I am describing below is not caused by Octoprint; I'm posting this here just to get an advice/suggestions from the community on how to address it.
I have IDEX printer of my own design running Repetier 1.04 firmware connected to Octoprint. The mainboard is Ultratronics Pro 1.0 that stores firmware inside the board while EEPROM content is stored on SD card.
I have 2 versions of firmware - one is for single head printing, which I use 95% of the time, another for Ditto printing when both heads print identical parts in parallel. To switch the firmware I have to reflash the board, which is extremely inconvenient. The reason I keep two firmware versions is because when printing with single head using dual extruder firmware I sometimes experience unexpected tool change that ruins the prints. Repetier has M111 S7 command that sends back to the terminal the last command it received and I am seeing that the error happens when the last received G-Code was misinterpreted as T1. Octoprint shows really low resend rate, could be a dozen of errors in few hundred KB long files, yet any of this errors under certain conditions may cause tool change.
Repetier 1.04 reached end of development, I am more or less familiar with the code and should be able to customize it to address this. I am thinking about the following 2 options
Add custom flag to EEPROM that will enable/disable T1 command. If disabled, checksum error could be generated and Octoprint will re-send the last command.
Modify T1 command handler and add extra parameter (e.g. T1 S12345) and switch the tool only if this extra parameter is present, otherwise, return checksum error.
Which of these 2 options would you choose or is there a better way?
If you have a tool swap because of misinterpretation of a faulty received command,
you may improve the serial connection.
When a command can be seen as a tool change, it also can be seen as other weird information: Reverse extrusion, false coordinates, changing temps of nozzle and/or bed etc.
That's what I'd expect as well, but that is not happening. If tool does not change the print completes without any issues. Just finished 5 hour long print that had only 11 retries. Considering that GCode file was several Megabytes is size, such retry number should be negligible IMHO.
I have reported this in Repetier support forum and the developer replied that the "problem is that T1 is really a short command and if G1 gets T1 the rest is irrelevant, also checksum should normally prevent this."
So it shows a checksum error but there is no resend request generated, to ask OctoPrint to send the line again. That's a bug or problem in the firmware, it's great knowing there is a checksum error but you can't do anything about it without knowing which line to resend...
I am also a little curious why you would say this is not a possible error with the serial connection.
I have done prints of 2 1/2 days and had 0 resends on that long a print using repetier firmware. You said you had 11 resends in a 5 hour print, so that tells me there is something wrong either with the actual serial connection or with the baud rate being used that is triggering the resends.
Maybe a simple fix would be to lower the baud rate slightly to reduce the potential for spurious data corruption in the transmitted signal.
Many thanks! You actually answered the question which I should ask at the first place - should resend number be at 0 or having a handful of resends is OK. I will try to lower baud rate and check if that helps.
My premise is that the baud rate should be at the lowest level it can and allow the printer to print at its fastest speed.
Attempting to transfer data faster than required simply allows for errors to creep in for unexplained reasons and some errors are not recognized as such and can cause problems. In over 3 years and many hours of printing I have never seen one single data error or retransmit.
Admittedly my printer is slower than many (Max 80 mm/s due to an inadequately rigid frame) but I use a 57600 baud and never see the printer buffer less than full. If needed I could bump that up but since it works as is, why break it?