Establishing reliable communications
Hi All,
The printer is a Da Vinci reflashed with Repertier firmware and the computer is a general purpose PC running Win10.
Has anyone else experienced this situation where the RS reports the printer is connected however it is not possible to actually send commands to it (such as manual move or a GCode) and have it actually executed? Also the one or other or both of the extruder/bed temperatures are obviously incorrect (often display as 0.0).
I have experienced this from a complete system and printer power up but also after power cycling the printer by itself.
The solution, tried it on this occasion, was to manually stop the server and then restart it.
I cam back a while later and the computer had entered sleep mode so I recovered it and checked I had control by manually moving the axes, which was successful. So I loaded a job and told it to print. Nothing happened - the printer was being sent commands, very slowly, but did not react to them.
Therefore I aborted the job with the Emergency Stop button, homed the Z-axis and again started the job wiht the Print button. This time the printer burst into life and printed the object.
It would seem that the first print attempt, after recovering from the computer sleeping, was not actually communicating correctly with the printer even though manual control of the axes was possible.
From these experiences it looks like the communications between RH, RS and the printer are not as solid and reliable under all conditions as I would have hoped they would be.
Any suggestions? I will try stopping and restarting RS whenever I return to the computer after it has had a sleep.
Regards,
Graham
The printer is a Da Vinci reflashed with Repertier firmware and the computer is a general purpose PC running Win10.
Has anyone else experienced this situation where the RS reports the printer is connected however it is not possible to actually send commands to it (such as manual move or a GCode) and have it actually executed? Also the one or other or both of the extruder/bed temperatures are obviously incorrect (often display as 0.0).
I have experienced this from a complete system and printer power up but also after power cycling the printer by itself.
The solution, tried it on this occasion, was to manually stop the server and then restart it.
I cam back a while later and the computer had entered sleep mode so I recovered it and checked I had control by manually moving the axes, which was successful. So I loaded a job and told it to print. Nothing happened - the printer was being sent commands, very slowly, but did not react to them.
Therefore I aborted the job with the Emergency Stop button, homed the Z-axis and again started the job wiht the Print button. This time the printer burst into life and printed the object.
It would seem that the first print attempt, after recovering from the computer sleeping, was not actually communicating correctly with the printer even though manual control of the axes was possible.
From these experiences it looks like the communications between RH, RS and the printer are not as solid and reliable under all conditions as I would have hoped they would be.
Any suggestions? I will try stopping and restarting RS whenever I return to the computer after it has had a sleep.
Regards,
Graham
Comments
For the last week or so the printer has worked well with several objects being printed and the communication are solid and reliable.
Today, I again have the situation where commands get a response of 'Warning: Seems like we missed a OK - continue sending'.
I have powered the printer off then on, and also tried disconnecting the USB lead as suggested. The printer is reported as 'online' by R-Server but manual control through the console does not move the head and reported bed temperature is 0.0C but the head temperature is correct.
What is the sequence required to resolve this problem?
Graham
Graham
- the PC reports the COM port correctly (COM11) and lists it as Arduino Due
- R-Host reports the extruder temperature as 0.0C/off, bed temperature ads 0.0C/off (both should be ambient ~21C)
- R-Server reports the extruder temperature as 54.8C/off, bed temperature ads 0.0C/off (both should be ambient ~21C)
The firmware version is reported from the printer menu as: da Vinci 1.0, 1.20-06-27_1.1, Repetier 0..92.10M
I am more than happy to assist in resolving this so please feel free to ask me to perform some tests.
Graham
What I see are just warnings - these happen when there is a communication error that got detected. So these are nothing serious. Only the frequency here is quite high. When you enable Ack you should see that noll answers look like "ok 234". Sometimes the o or k is missing typically.
I did have ACK disabled but Commands has always been enabled as this screen shot shows - OK, can't paste a screen shot :-(
With ACK enabled and using R-H to request the X-axis to move the log is:
And the printer didn't move the carriage. How can we resolve this and restore proper and full communication?
Any tests you would like me to do? Any settings to change? Should I drop R-S and directly connect to the COM port?
Also, I changed the USB port which changed the COM number, reconfigured R-S but still no proper communication or control of the printer. R-S says the printer is connected but manual control is ignored like with R-H. I guess that the problem is with R-S not communicating with the printer even though it reports connected (the green link symbol by the printer name).
Correct me if I am wrong: Repetier-Server should be able to connect and control the printer by itself and only when that is operational will Repertier-Host be able to do the same thing. Therefore the focus of this problem is R-S to printer communication.
Graham
So, I used RH to stop the server which was successful.
I then used RH to start the server which failed with RH locked up ('not responding' in the title bar). I waited several minutes then forced RH to close. Restarting RH was OK and start server was successful.
Having restarted the server the printer communications were restored and control over the printer was possible.
The conclusion I draw from this is that the server can struggle to correctly establish communications with the printer even though the server status shows 'connected'. I think this needs to be reported as an issue to be addressed or at least discussed with your software team.
Thanks for your help,
Graham
Maybe host should be improved by showing both the connection to the server and the connection through to the printer. I suspect though that host doesn't actually know that the printer is actually connected so my suggestion could be difficult.
Could be worth discussion how this could be implemented with the software team - there may be a simple solution just waiting to be brainstormed into life!
Thanks for your assistance,
Graham