![]() ![]() Timeout messagesĪ timeout means we had send a command to printer and did not receive an ok message for it in the expected time. 230400 instead of 250000 or electric noise on the cables. Reasons are slightly wrong baud rate, e.g. If the issue remains also in ping-pong mode the error rate is very high. Lower values make no sense and you should use ping-pong mode then. Stay in ping-pong mode or disable it and reduce input buffer until the error disappears. Try first activating ping-pong mode and if it disappears that was the reason. One is that you have set the input buffer too high. If you constantly see this error there are two typical reasons. This happens if interrupts in printer firmware were blocked too long. Not necessarily because the data was not transmitted correctly, but also maybe because the printer did not process it until the next byte was received. In console or log you see the resend messages.Īs long as it only happens once in a while this is nothing to worry about. If you see such an error it means the printer detected a mismach and wants the server to reesend the line. Then putting too many commands in parallel will delay pauses or print stops too much simply because we can not cancel already send commands.Īs explained above we normally send line numbers and checksums with every command. This is normally disabled and makes only sense if the input buffer is really big. The second limit is that you can limit the number of parallel commands. And firmware can send 2 ok messages maybe in a single data packet. A typical input buffer is 127 byte and when we can have 2 commands inside with more or less double the possible communication speed. As long as we do not send more than would fit inside we are save. That buffer is on the printer side and stores received data for later processing. So what happens if you disable ping-pong is that we send multiple commands and count the bytes send without having gotten an “ok”. Without line number it only halves the number of timeouts. Ideally the printer firmware adds the line number to the ok message so we see that we missed an ok and correct it on the fly. ![]() But as long as we can send more parallel commands the next one can still be send causing no timeout. There is no checksum solution for the backchannel, so if “ok” becomes “k” we will not know that we can send next command. The second issue it solves is missing “ok” from printer. With very curvy models and with very small triangles in the stl model it can be higher. So assume you print at 100 mm/s that means with 250 lines/s your average move length should be below 100 mm/250 = 0.4 mm. How tiny is defined depend on print speed. Only thing is in some edgy cases it is not enough and you will see the printer stutter ot move unevenly. 250 lines per second is a good speed and most prints can also print good with even 100 line per second. That makes 4 ms per command or 1000 ms/4 ms = 250 commands per second. One command needs 2 ms to be send and then we wait 2 ms for the ok to see we can send more data. So assume a latency of 2ms and unlimited speed otherwise. Due to all the involved parts a message has to go through there is not only the physical possible speed, but also a latency from starting sending a message until the first byte is received. The first is increasing communication speed. So why should you consider that and what does it do? This solves two issues. If you are familiar with our configuration, you saw that there is the possibilty to disable ping-pong. We call this communication solution ping-pong-mode, simply because it goes always in one direction and then waits for response and so on. When the printer sees this it computes the checksum as well and when it differs it will complain and request a resend of the correct command. So what we do is that we prepend a line number to each command you send with the N-parameter and end a line with *checksum. Now the printer developer knows that the commands might get corrupted. From time to time the printer will also send additional data like temperatures, status changes and more. When the server receives this ok message it knows it can send the next command and so on. A command gets send and when the printer has received it and is ready to get the next command, it will send back a line starting with “ok ” or only “ok”. The basic communication works driven by the server side. ![]() Only if the data can flow exactly as wanted between printer CPU over all involved parties to the server you will get the desired print result. In between there is also the operating system or eventually an USB to serial driver chip. These are connected via usb cable, serial cable, network or a 3rd party intermediate software (Klipper Pi app, Duet control server) with one Repetier-Server instace. You have two disconnected devices – a 3d printer and Repetier-Server running on a computer. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |