› ›

Recommended baud rate?

ajfreed00ajfreed00
in Questions & Answers
I am using a Raspberry Pi 2 Model B running Raspbian Jessie, which has been updated to the latest packages. It is running Repetier-Server Free, and controlling 3 WANHAO Duplicator i3 3D Printers.

However, even with this entire setup, the prints stutter while they are running after about 5-15 minutes. Sometimes it's a small stutter, sometimes it simply stops for 10 seconds-several minutes. The prints themselves do not stop, and Repetier-Server does not show any errors or glitches in the log.

I am wondering if this is a problem with the baud rate configured on the serial port of the printers/Raspberry Pi.

From what I am reading online, others have had this problem, but that was in earlier releases, and in the later releases (in the update notes), they mentioned that they fixed these problems. Why, then, am I still having them?

Please respond as soon as possible.

Thanks.

Comments

  • RepetierRepetier
    Which firmware did you select resp. which do the printers have?

    In ascii mode (marlin, smoothieware) you can only buffer 50% of the commands in printer queue compared to binary mode. That should only matter with tiny moves where speed really matters. Normally 115200 or 250000 baud should work find and usb->serial latency is the bottleneck.

    If you have communication errors obscruring returned "ok" you get a lock at some point and after "timeout" seconds this should be detected and print continues.

    I hope you are using 0.70.1 - older versions had some problems with solving the misse do correctly.

    Maybe you could show a log excerpt 200 lines around where such a pause happens. That normally helps to underdstand what is going on.

    Also what else are you doing on the pi when it happens? What is load and what does htop show (shows threads with cpu usage as well).
  • ajfreed00ajfreed00
    Which firmware did you select resp. which do the printers have?

    In ascii mode (marlin, smoothieware) you can only buffer 50% of the commands in printer queue compared to binary mode. That should only matter with tiny moves where speed really matters. Normally 115200 or 250000 baud should work find and usb->serial latency is the bottleneck.

    If you have communication errors obscruring returned "ok" you get a lock at some point and after "timeout" seconds this should be detected and print continues.

    I hope you are using 0.70.1 - older versions had some problems with solving the misse do correctly.

    Maybe you could show a log excerpt 200 lines around where such a pause happens. That normally helps to underdstand what is going on.

    Also what else are you doing on the pi when it happens? What is load and what does htop show (shows threads with cpu usage as well).
    I am using Marlin. So are you saying I should set the baud rate to 115200 and the buffer to half (127/2=~63)? Would that fix it? Thank you
  • RepetierRepetier
    I didn't say anything about 63 bytes. That would only help if your firmware buffer is that small. With latest compiler I think marlin also has 127. But thats what the log would show I talked about. It shows what happens and then you know what to do.
  • ajfreed00ajfreed00
    Ok, I think I found a glitch. Whenever the printer stutters, it sends to the Pi "wait". Is it waiting for commands, and the Pi isn't sending them, or is there some type of communication glitch?
  • ajfreed00ajfreed00
    warning: seems like we missed a ok - continue sending.

    That is another glitch that appears in the log.

    Could it be that our slicer is not compatible with the way Repetier Server works? We are using Craftware. It works fine with SD cards, but Repetier lags and glitches like this.
  • RepetierRepetier
    If firmware sends "wait" it was waiting for new commands and did not get any.
    warning: seems like we missed a ok - continue sending. means server wanted to send but did think buffer was full. If they are in direct order the wait told server there is nothing.

    I still would need to see the log where it happens to say more.

    Also if it happens please send
    in terminal and tell what it reports. This gives some infos about internal communication state helping to solve such things.

Sign In or Register to comment.