Ok, on first sight it looks the same just failing in server version. Is this a new phenomen for the server or the first try you use server with that printer?
What board das the kossel use? If it is a malayan board try RTS High, DTR Low.
Also please have a look at server.log in C:/ProgramData/Repetier-Server/logs and see if it contains some informations about the close reason.
2018-09-27 18:22:13: Connection started: Kossel MAX 2018-09-27 18:22:13: Reset printer Kossel MAX 2018-09-27 18:22:19: Port closed for kossel_MAX 2018-09-27 18:22:19: Connection closed: Kossel MAX 2018-09-27 18:22:51: Connection started: Kossel MAX 2018-09-27 18:22:51: Reset printer Kossel MAX 2018-09-27 18:22:57: Port closed for kossel_MAX 2018-09-27 18:22:57: Connection closed: Kossel MAX 2018-09-27 18:23:57: Connection started: Kossel MAX 2018-09-27 18:23:57: Reset printer Kossel MAX 2018-09-27 18:24:03: Port closed for kossel_MAX 2018-09-27 18:24:03: Connection closed: Kossel MAX
I've found the problem, the printer goes offline when i push the emergency button on Repetier Host, connected to the Server. After this i need to restart the server service.
This is happening to me on repetierposerver 90.7 with the latest Marlin Firmware on all 5 of my CR10-S printers. I have 2 Rapsberry-Pi 3B+ that are experiencing the EXACT same problem where anytime a print job is Stopped or Emergency Halted you have to reboot the Repetier-Server to get the printers ACTIVE again. The printers default goto DEACTIVATED and no matter what setting you use, no matter what port you switch them to, no matter how many times you can unplug/plug in the printer the ONLY solution is to reboot the Pi3b+.
I'm so glad I'm not the only one experiencing this problem and has only occured in 90.7. Previous version I did not have this problem.
I'm not really aware of a change in connection. What is new since 0.90.0 is that you can select how RTS/DTR is toggled, but default value is low to high like in host as well. So boards that require special settings of the state e.g. when used for hardwrae flow control they may not work with all combinations. E.g. I heard that the new Malayan baords need RTS high and DTS low. What board is used in your printer? Can you try if changing RTS/DTR gives a always connecting combination?
Creality CR-10S uses a FTDI chip for communication (or a fake clone who knows). RuRamps4D no idea what they use as serial communication chip. Just tested with a read due and it could reconnect/disable/enable at any time. But they also use DTR only to create a reset on toggle and ignore RTS completely. So they do not implement any type of flow hardware control.
Now since it sometimes works and sometimes not the assumption is that changing the pin states can block communication in the one or other direction. There is no standard for serial pin usages just ways often used.
So fact is you might need one of the combination high/high, high/low, /low/low or low/high. Only tests can say if that helps to connect at any time. I do not really see a difference between connecting on start or later connect except that on the very first connection test we haven't touched RTS/DTR which is done after port is opened. So what we try is set them to the same mode as on first connect as it seems to work. So hopefully one of the 4 combinations make it work reliable.
Did you try starting a print job on the CR10S with the latest marlin firmware, then hitting the EMERGENCY STOP button? This is the part that causes the CR10S to go into being unable to be communicated with.
Just had this bug happen again with a printer that was working flawlessly now it's doing the same OFFLINE status after I hit emergency stop.
I tried all 4 variations of HIGH/LOW in either option. LOW/HIGH would get me a constant reboot cycle where the printer would consistently reboot itself.
What version of Marlin are you testing the software with?
At this rate I will have to roll back to an early version of Repetier that doesn't have this problem. Is there a link to older versions of .90? Looking for V8 as that was the one that is based off RP3B+ which is what I am using.
finally, where can i find a log of the printer's connection errors? Where does Repetier store logs of connections on the filesystem?
This may be useful for troubleshooting. This could be related to the RP3B+ as I had RP3B and didn't have this problem.
Connections are logged in logs/server.log in storage directory.
For older versions just replace the version number in download link:-)
I do not think that 3B+ and 3B will behave different.
Also firmware should not depend on it working or not. After a reset it will start again and send "start". What we do on emergency stop is send M112 and then toggle DTR/RTS also with fixed setting nothing will toggle, so only M112 will be send. If that stops firmware and does not reset firmware you will in deed have no more communication until you hit the reset button of the printer.
Can you test what simply sending M112 does to the connection? Best while in console.
What Marlin version do you use? I normally test on repetier-firmware as my printers use it. I also have a Prusa with Marlin which I can test.
I'll try sending the M112 in the console when the printer is printing.
The only way I have been able to fix this problem is to reset the Repetier-Server on the RP3B+ itself. Resetting the printer does nothing, removing the USB power and power from the printer and plugging back in does nothing. The only way that the printer is able to communicate with Repetier again is by rebooting the entire RP3B+. This is not optimal as I have 3 Printers on Repetier running jobs and if one fails Emergency Stop stops all print jobs. I can't have that happen as that's wasted time and material especially on long prints.
That seems a very penetrant problem then. Normally reset, unplug or disable work on all printers I have. If new connection does not reset unplug + reset should do the trick.
What is if you are in console and press the reset button on the printer. This is technically no reconnect. All that would happen normally is that you see in console "start" and firmware starts again but server detects it. So would be same result as emergency stop but would expect connection to still work.
What is if you insetad of rebooting the pi only restart the server sudo service RepetierServer restart
does that also help reconnecting? I think of another occation where another software was using the port. As a test you can do
Here my printer is on /dev/ttyACM0 and fuser tells me process 16104 is using the port. I have for example teh problem that when klipper is running on my pi it tries to use the port as well preventing server from connection. So on reboot server might just be first to connect so it works and later on the other software breaks it. Just an idea also I think not really that it is the problem. Then you would see server trying to connect over and over again.
1. Restart the Repetier service on the inoperable Pi, see if this works. 2. Start a print job, send the M112 code to the printer while printing. see what happens there. 3. check the logs and examine the ports in question to see if the service is still trying to use the port after M112 is called or Emergency Stop.
I will be doing this on a Raspberry Pi 3B+ with 2 CR10S' attached with Marlin 1.1.9 firmware and version 90.7 of Repetier.
Not sure what is the issue here, could be the EEPROM mismatch, but then why would the printer work when server/service restarts and not after emergency stop? Is there something checking in repetier that is not accepting the firmware/eeprom?
I found I didn't save my EEPROM. I fixed that by running a M502 and then M500. Saved my EEPROM, started a new print job.
I then did an emergency stop and the problem repeated itself: Once the firmware was restarted the printer was not seen by Repetier at all. No reconnection was found, could not activate, Repetier had to be reset in order to start printing again.
here you see clearly that reconnection works. We get the "start" from firmware and lots of output. What I do not see is any responses to commands being send just as if they do not get to the printer. I wonder if that is caused by fake ftdi chips. Some ftdi drivers are known to to bad tricks on them to stop produces from faking them. See for example here: http://www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html
Could you test if you have a original or fake FTDI chip?
Original. All these printers were working with earlier version of repetier, emergency stop was working, and never had an issue till I upgraded to the latest version of Marlin Firmware+Repetier....
Do you have compiled marlin with flow control? As I see the startup works the question is why we get no more feedback. Since you updated both it now hard to say whose changes cause the problem.
What was the last server version that had no problems? Then I could compare the changes since then.
Comments
What board das the kossel use? If it is a malayan board try RTS High, DTR Low.
Also please have a look at server.log in C:/ProgramData/Repetier-Server/logs and see if it contains some informations about the close reason.
2018-09-27 18:22:13: Reset printer Kossel MAX
2018-09-27 18:22:19: Port closed for kossel_MAX
2018-09-27 18:22:19: Connection closed: Kossel MAX
2018-09-27 18:22:51: Connection started: Kossel MAX
2018-09-27 18:22:51: Reset printer Kossel MAX
2018-09-27 18:22:57: Port closed for kossel_MAX
2018-09-27 18:22:57: Connection closed: Kossel MAX
2018-09-27 18:23:57: Connection started: Kossel MAX
2018-09-27 18:23:57: Reset printer Kossel MAX
2018-09-27 18:24:03: Port closed for kossel_MAX
2018-09-27 18:24:03: Connection closed: Kossel MAX
After this i need to restart the server service.
I'm so glad I'm not the only one experiencing this problem and has only occured in 90.7. Previous version I did not have this problem.
What can we do?
Do we need to set RTS/DTR to be HIGH/HIGH or LOW/LOW?
Now since it sometimes works and sometimes not the assumption is that changing the pin states can block communication in the one or other direction. There is no standard for serial pin usages just ways often used.
So fact is you might need one of the combination high/high, high/low, /low/low or low/high. Only tests can say if that helps to connect at any time. I do not really see a difference between connecting on start or later connect except that on the very first connection test we haven't touched RTS/DTR which is done after port is opened. So what we try is set them to the same mode as on first connect as it seems to work. So hopefully one of the 4 combinations make it work reliable.
I tried all 4 variations of HIGH/LOW in either option. LOW/HIGH would get me a constant reboot cycle where the printer would consistently reboot itself.
What version of Marlin are you testing the software with?
At this rate I will have to roll back to an early version of Repetier that doesn't have this problem. Is there a link to older versions of .90? Looking for V8 as that was the one that is based off RP3B+ which is what I am using.
finally, where can i find a log of the printer's connection errors? Where does Repetier store logs of connections on the filesystem?
This may be useful for troubleshooting. This could be related to the RP3B+ as I had RP3B and didn't have this problem.
For older versions just replace the version number in download link:-)
I do not think that 3B+ and 3B will behave different.
Also firmware should not depend on it working or not. After a reset it will start again and send "start". What we do on emergency stop is send M112 and then toggle DTR/RTS also with fixed setting nothing will toggle, so only M112 will be send. If that stops firmware and does not reset firmware you will in deed have no more communication until you hit the reset button of the printer.
Can you test what simply sending M112 does to the connection? Best while in console.
What Marlin version do you use? I normally test on repetier-firmware as my printers use it. I also have a Prusa with Marlin which I can test.
I'll try sending the M112 in the console when the printer is printing.
The only way I have been able to fix this problem is to reset the Repetier-Server on the RP3B+ itself. Resetting the printer does nothing, removing the USB power and power from the printer and plugging back in does nothing. The only way that the printer is able to communicate with Repetier again is by rebooting the entire RP3B+. This is not optimal as I have 3 Printers on Repetier running jobs and if one fails Emergency Stop stops all print jobs. I can't have that happen as that's wasted time and material especially on long prints.
What is if you are in console and press the reset button on the printer. This is technically no reconnect. All that would happen normally is that you see in console "start" and firmware starts again but server detects it. So would be same result as emergency stop but would expect connection to still work.
What is if you insetad of rebooting the pi only restart the server
sudo service RepetierServer restart
does that also help reconnecting? I think of another occation where another software was using the port. As a test you can do
pi@FelixPi:~ $ sudo fuser /dev/ttyACM0
/dev/ttyACM0: 16104
pi@FelixPi:~ $ ps aux | grep 16104
repetie+ 16104 6.3 2.0 303448 19568 ? S<sl 16:31 0:33 /usr/local/Repetier-Server/bin/RepetierServer -c /usr/local/Repetier-Server/etc/RepetierServer.xml --daemon
pi 17599 0.0 0.2 4272 2012 pts/0 S+ 16:40 0:00 grep --color=auto 16104
Here my printer is on /dev/ttyACM0 and fuser tells me process 16104 is using the port. I have for example teh problem that when klipper is running on my pi it tries to use the port as well preventing server from connection. So on reboot server might just be first to connect so it works and later on the other software breaks it. Just an idea also I think not really that it is the problem. Then you would see server trying to connect over and over again.1. Restart the Repetier service on the inoperable Pi, see if this works.
2. Start a print job, send the M112 code to the printer while printing. see what happens there.
3. check the logs and examine the ports in question to see if the service is still trying to use the port after M112 is called or Emergency Stop.
I will be doing this on a Raspberry Pi 3B+ with 2 CR10S' attached with Marlin 1.1.9 firmware and version 90.7 of Repetier.
Will report my findings
2. I performed M112 on the console while printing. Printer restarted, firmware restarted. Connnection did NOT come back.
Here is the part from the log file:
What in the name of the world is this? Why would my EEPROM be mismatched here? What could cause this?
3. Ran fuser command and there was nothing running on that port:
Not sure what is the issue here, could be the EEPROM mismatch, but then why would the printer work when server/service restarts and not after emergency stop? Is there something checking in repetier that is not accepting the firmware/eeprom?
I then did an emergency stop and the problem repeated itself: Once the firmware was restarted the printer was not seen by Repetier at all. No reconnection was found, could not activate, Repetier had to be reset in order to start printing again.
Here's some of the log of the job:
Connection Started
Reset Printer
Port Closed
Connection Closed
Connection Started
Reset Printer
All within the span of 10-15s.
More logs after I restarted the Service:
here you see clearly that reconnection works. We get the "start" from firmware and lots of output.
What I do not see is any responses to commands being send just as if they do not get to the printer. I wonder if that is caused by fake ftdi chips. Some ftdi drivers are known to to bad tricks on them to stop produces from faking them. See for example here:
http://www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html
Could you test if you have a original or fake FTDI chip?
What was the last server version that had no problems? Then I could compare the changes since then.