This entry tries to guide you, in case you could start a print and later on the print stopped for unknown reasons. That is something that normally does not happen, so there must be a reason. And often if the causing reason does not get removed it will happen over and over again. So if you have frequent unintentional stops, follow this guide and see what it is.įirst thing you need to understand is how the communication flow is. Printer Firmware: The firmware has a communication buffer for in and outgoing messages.The flow from printer into Repetier-Server takes the following steps. Usb Hip (optional): Some users have cascades of USB hubs to get enough USB ports.USB Cable: No active component, but electric noise, bad contacts, bad shielding or just long cables can add communication errors here, so it is a possible source of failure.Printer USB: This is either a USB-Serial converter and printer firmware talks to it via serial connection or a native USB driver that is integrated in the printer firmware.It checks incoming messages with line numbers and checksums for communication errors. Repetier-Server connected vie communication portĪs you see there are up to 6 instances involved and each has it’s own possible source of problems.Usb of your PC, PC Operating System: The OS serial driver sees the device, creates a communication port in the OS to connect to.Each hub has to split and resend data, so possible source again. So the main step required is to find out which device is causing it and what can you do against it. One of the most important parts to identify the problem are log files. ![]() On server side the relevant parts are server.log which shows when a serialconnection gets opened or closed. But it is with these informations at least possible to identify the timestamp when exactly the problem happened. The other server file is server print logging. ![]() You can enable this in printer conext menu. Normally it is just unneeded information and writes, so it is disabled by default. ![]() But when you are searching why you are loosing connections you should enable it. Part ofit can also be seen in the console, so that is also a nice source for real time view of problems, but you only see result of last 2000 lines, so information might be gone when you need it. The last are logs from the operating system. Note that syslog gets rotate on dayly basis, so if you download you always only get the one for the current day.įirst check is connection quality when it works.įor linux this is the file /etc/logs/system – which you can download in the server log window as well. So for a longer print check a log and count how many resend requests you see from printer and how many timeouts you see.Ī resend happens when a firmware receives a command with checksum and the checksum does not match, so it means the line we did send is not identical to the received one. Something between step 5 and 1 changed the content or dropped part of the data send.Įspecially with real serialUSB converter a modification happens easily. There is no timing line, so if clocks of devices are not running at exactly same speed they might misinterpret a bit every now and then. When the printer allows switching baud rate you can try switching 115200 with 250000 or the other way around. Sometimes one of them creates less errors. Speed wise it makes not much difference as usb latency is the main speed limiter. If you get very frequent resends, like 1 every 5-10 lines, your setting for input buffer size is too high and we are sending more data then the printer firmware can cache. If that does not help switch to ping-pong-mode where we only send a new command when firmware marks the last send command as finsihed. Timeouts are a result of communication errors in the other direction from printer firmware to server. For every command we send, we need to receive one line that starts with “ok”. A typical case is that the “o” is missing and “k” is not “ok”. So we wait and wait for it and firmware is waiting for next command not knowing that we did not receive the “ok”. ![]() So after the set value of “timeout” seconds and when we know the command should be fast, we assume this case, write the timeout message and continue sending data. Here you need to watch out to shoose a good value. Modern firmwares support a busy protocol, meaning if a command takes longer it send “busy” resetting the timeout every 2 seconds. In this time you can set timeout to 3 seconds and have a fast recover. If this is not supported, timeout should be 30 seconds or at least longer then the longest slowest move you plan to execute.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |