Skip to content
This repository has been archived by the owner on Aug 27, 2023. It is now read-only.

Communication timeout #336

Open
ahmetonat opened this issue Jun 25, 2023 · 3 comments
Open

Communication timeout #336

ahmetonat opened this issue Jun 25, 2023 · 3 comments

Comments

@ahmetonat
Copy link

My setup is: Tiertime Up Mini printer electronics and mechanics, but the controller is replaced by an Arduino Nano (yes only an Atmega 328P). I am at a point where it is possible to home the printer and control the extruder satisfactorily.

The next problem is communication timeout. The printer will hang at an arbitrary point after about 1 minute or so of printing. Repetier Host (that I am using with it) issues "communication timeout" errors and tries to re-connect in vain.
Sometimes the printer will slow down to a crawl but will recover to the previous speed after about 30 seconds or so.

Another problem I noticed when trying to print cylindrical objects is that the printer seems to skip vertices. It starts drawing a line segment, but the next segment is quite far ahead and the filament follows the shortest path between them. What should be circles are drawn as arbitrary polygons.

I assume that the processor is running out of memory or cannot complete calculations between consecutive commands received from the PC.

What I did is:

  • Reduced the communication speed as low as I can (19200baud from 115200) in an attempt to give the processor more time to complete calculations
  • Increased the receive buffer to 14 (from the default of 8). This gives RAM utilization of 81%, so I assume it is safe
  • In Repetier Host, I set what they call Ping-pong mode where new commands are sent only after an ACK is received from the printer.

None of these changed the behavior of the printer.

Any ideas? Perhaps I should just quit this processor and move on to an ARM and perhaps full size Marlin FW or similar?

Thanks.

@phord
Copy link
Collaborator

phord commented Jul 11, 2023

The issue with skipping waypoints is probably unrelated to the processor speed. More likely it is caused by RH sending data faster than it can be printed without waiting for the UART buffer to drain.

"Ping-pong" mode sounds like the usual reprap communication style, but it's strange that it doesn't work for you. Maybe the responses are not to Repetier's liking.

I wanted to use RepetierHost when it came out, but I experienced a number of weird effects with it, too. Whenever I tried to send my G-Code with some other tool like Pronterface, it always worked fine. So I eventually gave up on RepetierHost. I've successfully used many other tools without the sorts of problems RH had. Have you tried sending your g-code with any other tool?

@ahmetonat
Copy link
Author

Thanks for the tip! Actually I only tried Repetier host as I am not very familiar with 3D printing tools on the PC side, so I assumed that the popular Repetier Host would work just fine.

Let me try Pronterface, and see how it goes. Do you have any other recommendations for PC side software?

In RH (and others probably), there is an option for the printer firmware. I have been using Marlin as that seems to be the closest alternative but I am not sure if it is the correct option.

@phord
Copy link
Collaborator

phord commented Jul 12, 2023

I thought RH had a Teacup option for "controlled firmware", but maybe I added it manually when I was testing it. (My memory is fuzzy since it was almost 10 years ago.)

I have also used Cura, Slic3r and Prusa Slicer to send G-code to the printer. But mostly I use Octoprint which uses one of these engines internally, I think, but I don't remember which one. Octoprint usually runs on a Raspberry Pi control board which is attached permanently to the printer. It allows me to print over the network by uploading files in the GUI and clicking the Print button.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants