RepetierHost connects to my miniRAMBo on laptop, but not my desktop

Running Linux Pop!_OS based on Ubuntu 21.04

When I try to connect to my miniRAMBo on my laptop, it seems to work (although not every time) and spits out the following logs:

However, when I try to connect with my desktop, I get the error No start signal detected - forcing start

The output for the laptop (working) is :
17:00:12.484 : Printer reset detected - initializing
17:00:12.484 : echo:start
17:00:12.484 : Marlin 510S 2.0.7.2
17:00:12.489 : echo: Last Updated: 2020-10-15 | Author: (V1 Engineering, Ryan, 510S)
17:00:12.489 : echo:Compiled: Jul 7 2021
17:00:12.491 : echo: Free Memory: 3341 PlannerBufferBytes: 1472
17:00:12.614 : N1 M11034
17:00:12.614 : N2 M115
36
17:00:12.614 : N3 M10536
17:00:12.614 : N4 M114
35
17:00:12.629 : N5 M111 S698
17:00:12.630 : N6 T0
60
17:00:12.631 : N7 M2022
17:00:12.631 : N8 M80
19
17:00:12.631 : N9 M10546
17:00:15.714 : N10 M105
22
17:00:19.321 : DIGIPOTS Loading
17:00:19.321 : DIGIPOTS Loaded
17:00:19.329 : DIGIPOTS Loading
17:00:19.330 : DIGIPOTS Loaded
17:00:19.334 : echo:V82 stored settings retrieved (665 bytes; crc 51211)
17:00:19.588 : N11 M10523
17:00:19.601 : FIRMWARE_NAME:Marlin 510S 2.0.7.2 (Jul 7 2021 16:27:49) SOURCE_CODE_URL:url/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:V1CNC 510S EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
17:00:19.601 : Cap:SERIAL_XON_XOFF:0
17:00:19.601 : Cap:BINARY_FILE_TRANSFER:0
17:00:19.603 : Cap:EEPROM:1
17:00:19.603 : Cap:VOLUMETRIC:1
17:00:19.603 : Cap:AUTOREPORT_TEMP:1
17:00:19.603 : Cap:PROGRESS:0
17:00:19.603 : Cap:PRINT_JOB:1
17:00:19.603 : Cap:AUTOLEVEL:0
17:00:19.604 : Cap:RUNOUT:0
17:00:19.604 : Cap:Z_PROBE:0
17:00:19.604 : Cap:LEVELING_DATA:0
17:00:19.604 : Cap:BUILD_PERCENT:0
17:00:19.604 : Cap:SOFTWARE_POWER:0
17:00:19.608 : Cap:TOGGLE_LIGHTS:0
17:00:19.608 : Cap:CASE_LIGHT_BRIGHTNESS:0
17:00:19.608 : Cap:EMERGENCY_PARSER:0
17:00:19.608 : Cap:PROMPT_SUPPORT:0
17:00:19.608 : Cap:SDCARD:1
17:00:19.612 : Cap:AUTOREPORT_SD_STATUS:0
17:00:19.613 : Cap:LONG_FILENAME:0
17:00:19.613 : Cap:THERMAL_PROTECTION:1
17:00:19.613 : Cap:MOTION_MODES:1
17:00:19.615 : Cap:ARCS:1
17:00:19.615 : Cap:BABYSTEPPING:0
17:00:19.615 : Cap:CHAMBER_TEMPERATURE:0
17:00:19.620 : N12 M220 S100
82
17:00:19.620 : X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
17:00:19.620 : N13 M221 S10082
17:00:19.624 : echo:DEBUG:INFO,ERRORS
17:00:19.625 : N14 M111 S6
82
17:00:19.625 : echo:No media
17:00:19.625 : echo:Unknown command: “M80”
17:00:19.625 : N15 T014
17:00:19.625 : N16 M155 S1
87
17:00:19.637 : echo:DEBUG:INFO,ERRORS

The output for my desktop (not working) is :
16:50:15.267 : No start signal detected - forcing start
16:50:15.268 : N1 M11034
16:50:15.268 : N2 M115
36
16:50:15.268 : N3 M10536
16:50:15.268 : N4 M114
35
16:50:15.272 : N5 M111 S698
16:50:15.273 : N6 T0
60
16:50:15.273 : N7 M2022
16:50:15.273 : N8 M80
19
16:50:15.273 : N9 M10546
16:50:18.368 : N10 M105
22
16:50:58.383 : Communication timeout - reset send buffer block
16:50:58.383 : N11 M10523
16:51:00.384 : N12 M105
20
16:51:03.385 : N13 M10521
16:51:06.386 : N14 M105
18
16:51:09.387 : N15 M10519
16:51:12.388 : N16 M105
16
16:51:15.389 : N17 M10517
16:51:18.390 : N18 M105
30
16:51:21.391 : N19 M10531
16:52:01.405 : Communication timeout - reset send buffer block
16:52:01.405 : N20 M105
21
16:52:03.506 : N21 M10520
16:52:06.507 : N22 M105
23
16:52:09.508 : N23 M10522
16:52:12.510 : N24 M105
17
16:52:15.511 : N25 M10516
16:52:18.612 : N26 M105
19
16:52:21.613 : N27 M10518
16:52:24.615 : N28 M105
29
16:53:04.628 : Communication timeout - reset send buffer block
16:53:04.628 : N29 M10528
16:53:06.929 : N30 M105
20
16:53:09.931 : N31 M10521
16:53:12.932 : N32 M105
22
16:53:15.933 : N33 M10523
16:53:18.933 : N34 M105
16
16:53:21.935 : N35 M10517
16:53:24.936 : N36 M105
18
16:53:27.937 : N37 M10519
16:54:07.949 : Communication timeout - reset send buffer block
16:54:07.949 : N38 M105
28
16:54:10.051 : N39 M10529
16:54:13.052 : N40 M105
19
16:54:16.052 : N41 M10518
16:54:19.054 : N42 M105
17
16:54:22.056 : N43 M10516
16:54:25.056 : N44 M105
23
16:54:28.157 : N45 M10522
16:54:31.258 : N46 M105
21
16:55:11.271 : Communication timeout - reset send buffer block
16:55:11.271 : N47 M10520
16:55:13.572 : N48 M105
27
16:55:16.572 : N49 M10526
16:55:19.574 : N50 M105
18
16:55:22.576 : N51 M10519
16:55:25.576 : N52 M105
16
16:55:28.578 : N53 M10517
16:55:31.579 : N54 M105
22
16:55:34.579 : N55 M10523
16:56:14.593 : Communication timeout - reset send buffer block
16:56:14.593 : N56 M105
20
16:56:16.695 : N57 M10521
16:56:19.696 : N58 M105
26
16:56:22.697 : N59 M10527
16:56:25.698 : N60 M105
17
16:56:28.700 : N61 M10516
16:56:31.800 : N62 M105
19
16:56:34.901 : N63 M10518
16:56:37.902 : N64 M105
21

I will also often get gargage like : 16:58:41.040 : in?RI??t?l;~??????Vh??T?7?a<?!D?o??@?????c(?1N??I???/??????.?(8xN?T6?[CXU?????i?1J%?I??n??n??$m??D<?!N?D8?L???????f?IDCl?p?YY???!?<4N???T?7?a<?1'

Experience has told me that the serial monitor spitting out garbage is typical of a wrong baud rate, but I have it set to 250,000 just as I do on the laptop. It also wasn’t always working on the laptop, but it seems to be fine now.

any pointers?

Are you running the same version of POP_OS on both your desktop and laptop?
The garbage on a serial monitor is certainly a sign of baud mismatch. UART communication is tricky because while one set of hardware will run just fine, another set will struggle at the same settings.
250,000 is an awkward baud rate, try 230,400 or 115,200.

They are on the same version OS right now, Pop!_OS just released the 21.04 version of their OS which I just upgraded and it wasn’t working beforehand or after. Meanwhile for the laptop it worked both before and after installing the upgrade. I could check the kernels though.

Can you just use a similar baud rate like that or is it fixed ? I’m pretty sure it’s set to 250000 in the firmware provided by V1 Engineering for their MPCNC machine. I’ve tried a few different other baud rates, but to no avail. I’ll give it a shot and see what happens.

Technically, you can use any baud rate you want, so long as the hardware can handle it. However, back in the days of slower electronics, the baud rates were based off of the common system clock frequencies. Because of that, specific clock speeds became standard that communications were based on. A lot of hardware still use those standard speeds, and because of how the clock speed is generated, some clock frequencies like 250,000 may not work out too well on some systems. It’s very hit-and-miss.

Another thought with Linux and communicating over serial connections is the dialout group. It depends on how the rambo board communicates with the system, but you should add your user to the dialout group. That may be a cause of communication issues.

If the above doesn’t work, connect your rambo to your desktop and check your /dev/ folder and see if you have the /ttyASM0 device present.

Let me know how it goes!

You can also look for errors in dmesg. I like to use dmesg -w and plug in the usb to see what it says. I will also watch while I connect with repetier host.

I will second being in the dialout group. I don’t use serial as root.

You can also use miniterm.py or screen or any of the linux serial tools. Miniterm.py is my favorite.

Pronterface and pronsole also work well in Linux.

okay so when I run dmesg -w and connect the board I get the following:

[ 2926.307405] usb 3-4.1: USB disconnect, device number 7
[ 2928.581711] usb 3-4.1: new full-speed USB device number 8 using xhci_hcd
[ 2928.701167] usb 3-4.1: New USB device found, idVendor=27b1, idProduct=0001, bcdDevice= 0.01
[ 2928.701172] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[ 2928.701175] usb 3-4.1: Product: RAMBo
[ 2928.701177] usb 3-4.1: Manufacturer: UltiMachine (ultimachine.com)
[ 2928.701178] usb 3-4.1: SerialNumber: 75535313630351511211
[ 2928.766103] cdc_acm 3-4.1:1.0: ttyACM0: USB ACM device

I don’t see anything being logged after I attempt to connect with the board using RepetierHost.

Miniterm.py seems to communicate clearly with the board:

pyserial-miniterm /dev/ttyACM0 250000
--- Miniterm on /dev/ttyACM0  250000,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
echo:start
Marlin 510S 2.0.7.2

echo: Last Updated: 2020-10-15 | Author: (V1 Engineering, Ryan, 510S)
echo:Compiled: Jul  7 2021
echo: Free Memory: 3341  PlannerBufferBytes: 1472
DIGIPOTS Loading
DIGIPOTS Loaded
DIGIPOTS Loading
DIGIPOTS Loaded
echo:V82 stored settings retrieved (665 bytes; crc 51211)

And if I send a code like G1 Z-10.11 F240*51 using miniterm.py it moves the z-axis fine!

It seems like RepetierHost is having some issue with communicating correctly. If I try to connect with RepetierHost while miniterm.py is running, miniterm will also start to spit out garbage. Is it possible that RepetierHost is glitching with the having the correct baudrate even though it’s set to 250000.

Then @Cobalt I also made sure to add myself to the dialout group with sudo usermod -a -G dialout $USER. I tried different baudrates on RepetierHost. I also confirmed that /dev/ttyACM0 is present.

A word of caution, never run multiple programs that try and communicate with the same serial port. Programs will usually grab access to the port and not let it go unless specially programmed to do so. It’s not impossible, but errors can be had from permissions to access it.

Any time you add a user to a group, they much log out, then log back in for the effects to take place. I just wanted to be sure you have done that after adding yourself to dialout.

From everything you’ve said, it certainly sounds like software issues with RepetierHost.
I’ve never used it, so all that I can suggest is making sure you have the latest version and performing an uninstall/reinstall.

I don’t use repetier host. At least I haven’t in several years. I usually use pronterface to get started and then put it on a v1pi. So I don’t have personal experience. It seems strange though. Unless it is some other serial setting like hardware flow control or something.

I would try with pronterface or the cncjs desktop client. Or install a different version of RH.