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

Comments

  • With such errors you should always consult the console and disable all filters so you see what is going on. E.g. when idle firmware sends every second a wait. Or assuming you used the old 0.92.x firmware you should see every second a M105 being send and returning a temperature. When baud rate is bad, buffers are wrong you might get many resends or timeouts. If usb stack is in trouble disconnect usb port and reconnect. That resets them and normally works. Restarting serve ris normally not needed.
  • Hi,
    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
  • Further to the above I powered the printer off and then on after 2 minutes. The initial lines in the log are
    11:28:47.242 : M20
    11:28:47.243 : Connection closed by os.
    11:30:49.976 : Connection started
    11:30:49.981 : M20
    11:30:50.082 : Dtr: false Rts: false
    11:30:50.082 : Dtr: true Rts: true
    11:30:52.986 : Free RAM:81456
    11:30:52.986 : Response while unconnected:SelectExtruder:0
    11:30:52.986 : SelectExtruder:0
    11:30:53.473 : Response while unconnected:wait
    11:30:57.561 : Warning: Seems like we missed a ok - continue sending.
    11:31:00.637 : Warning: Seems like we missed a ok - continue sending.
    11:31:04.511 : Warning: Seems like we missed a ok - continue sending.
    11:31:12.573 : Warning: Seems like we missed a ok - continue sending.
    11:31:28.575 : Warning: Seems like we missed a ok - continue sending.
    11:31:44.592 : Warning: Seems like we missed a ok - continue sending.
    11:32:00.697 : Warning: Seems like we missed a ok - continue sending.
    11:32:16.599 : Warning: Seems like we missed a ok - continue sending.
    11:32:32.617 : Warning: Seems like we missed a ok - continue sending.

    This is most perplexing - have other users experienced this and found a solution?
    Graham
  • Still having problems so I have investigated further:
     - 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
  • You have commands/ack disabled and M105 filter enabled in console. That way you only see the non standard messages and have no idea what is going on.

    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.
  • You are indicating that everything is correct and that the printer should be responding to the commands. This is my point: under this condition the printer is not accepting the commands and temperature status values 'returned' are not applicable. See my above posts: the temperature in R-S is not the same value as reported in R-H.

    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:
    21:02:12.539 : wait
    21:02:13.533 : wait
    21:02:13.848 : G1 X1 F4800
    21:02:14.530 : Warning: Seems like we missed a ok - continue sending.
    21:02:14.530 : wait
    21:02:15.623 : wait
    21:02:16.612 : wait
    21:02:17.607 : wait
    21:02:17.784 : G1 X11 F4800
    21:02:18.554 : wait
    21:02:19.145 : G1 X21 F4800
    21:02:19.647 : wait
    21:02:20.602 : wait
    21:02:21.591 : wait
    21:02:22.589 : wait
    21:02:23.525 : wait
    21:02:24.573 : Warning: Seems like we missed a ok - continue sending.
    21:02:24.573 : wait
    21:02:25.566 : wait
     
    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
  • Ok I see we receive responses from firmware but firmware is not receiving anything. Try changing RTS or DTR to and with the opposite state when finished. So high->low gets low->high and see if that helps. Some drivers use this as hardware flow control while we don't have that and just use it to reset board.  So just select what makes the board happy. Once it is the correct combo you should see a "ok" after sending a command which is what is missing here.
  • I worked through the RTS/DTR combinations while trying a manual move from the server - while monitoring through the console. Some seemed better but none gave proper control. I then read another post (Repetier-Host, Connection Problem, Marek33, https://forum.repetier.com/discussion/5765/connection-problem) who suggested restarting the server. I also looked at my previous post where I also suggested restarting the server but the comment in response was 'this shouldn't be necessary' (so I had avoided doing so).

    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
  • Host is a bad choice for such tests. It shows connected because it is connected with the server. The state of printer connection is independent from this. Only in the server tab you might note that hitting print is not possible, In server gui this is much clearer.
  • Hmmm,
    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
Sign In or Register to comment.