Linux does not connect to CNC

General CNC
1

Hi, having a problem connecting to a brand new machine, never before connected/run.

LAPTOP: Dell Latitude 5550, i5-5200U CPU @ 2.20GHz x 2

OPERATING SYSTEM: Linux Mint 21, Cinnamon 5.4.12, Kernel: 5.15.0-164-generic

APPLICATION: Universal G-Code Sender, Ver. 20251130

Firmware: GRBL (1.1h), Port: ttyUSB0, Baud: 115200/9600

MACHINE: Sainsmart Genmitsu PROVer XL 4030 v2

Computer setup & operated as Single User with full system Permissions and Dialout group membership, ‘Brltty’ file deleted.

PROBLEM: Attempting to connect to machine -

***Connecting to jserialcomm://ttyUSB0: 9600

***Fetching device status

>>>?

***Fetching device status (2 of 10)…

>>>?

.

.

.

***Fetching device status (10 of 10)…

>>>?

***Connection closed

A baud of 9600 or 11500 produces denticle results. Google AI suggested adjusting the ‘connection timeout’, but I cant find the appropriate settings.

Thanks

2

Initial safety check; I assume you tried 115200 baud (not 11500 as you wrote)?

What happens if you try to connect with a normal serial terminal program?

tio is a good one to use if liunux based:

eg: `$ tio /dev/ttyUSB0 115200

There is also pyserial-miniterm

Try other baud rates too; 57600 is a commonly used speed on some controllers.

1 Like
3

Google AI says you should be using 115200 for the baud rate, not 9600 or 11500

4

Hi, Owen,

thanks for your time. typo assumption correct, 115200 not 11500. As to ‘tio’, it’s not installed (at this time), however, /webserial.io/ returns “connected - ch340 serial converter 1086-7523”.

I’ve tryed baud rates of 9600, 57600 & 115200 with identicle results. I’m thinking it sees the control box but can’t talk to it.

The folks over @ V1 engineering had me run the command “sudo cat /var/log/syslog | grep -1 usb”, which returned (excerpt):

Jan 26 08:47:51 user-Latitude-E5550 systemd[1069]: Started VTE child process 1788 launched by gnome-terminal-server process 1763.
Jan 26 08:50:41 user-Latitude-E5550 kernel: [ 233.835331] usb 2-1: new full-speed USB device number 3 using xhci_hcd
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 233.984795] usb 2-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 233.984808] usb 2-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 233.984814] usb 2-1: Product: USB Serial
Jan 26 08:50:42 user-Latitude-E5550 mtp-probe: checking bus 2, device 3: “/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1”
Jan 26 08:50:42 user-Latitude-E5550 mtp-probe: bus: 2, device: 3 was not an MTP device
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 234.009821] usbcore: registered new interface driver usbserial_generic
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 234.009838] usbserial: USB Serial support registered for generic
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 234.012215] usbcore: registered new interface driver ch341
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 234.012693] usbserial: USB Serial support registered for ch341-uart
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 234.012867] ch341 2-1:1.0: ch341-uart converter detected
Jan 26 08:50:42 user-Latitude-E5550 kernel: [ 234.014869] usb 2-1: ch341-uart converter now attached to ttyUSB0
Jan 26 08:50:42 user-Latitude-E5550 mtp-probe: checking bus 2, device 3: “/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1”
Jan 26 08:50:42 user-Latitude-E5550 mtp-probe: bus: 2, device: 3 was not an MTP device

As you can see it is seeing the ch340 / 341-uart on the USB0 port, but I think without the MT protocol it can’t complete the handshake?

5

I don’t have a GRBL machine nearby but used webserial.io to connect to a Marlin 3D printer. I saw the serial port and then I connected(hit Connect 2 times ). You can see in the window Marlin is trying to send data. GRBL should show something and if you enter “$$” into the lower command area it should dump setting information.

screen2
screen21280×736 71.5 KB

screen3
screen31280×736 54.7 KB

6

The baudrate of my 3d printer is 250000. I would not stop testing at 115200.

1 Like
7

SOLVED: It turns out that communications is disconnected when the Emergency Stop is down and locked, this fact is not mentioned anywhere in readily available documentation. I had the E-stop down as a safety. Thank you for time and assistance.

3 Likes
8

Thank you for following up with the solution, so the next puzzled person has a chance to find this answer. :tada:

1 Like