CNC Router - GRBL-UGS-Linux connection issue

Happy Friday -

I have been having a frustrating time recently, where I have booted up my CNC router (Lunyee 4040, GRBL-based) and opened up Universal GCode Sender (UGS), and have been unable to connect.

Sharing screenshot below.

After several reboots of the computer and the CNC router, it seems to eventually connect - I haven’t found the exact cause.

Does anyone have ideas why this might be? Operating system is Debian Linux “Bookworm”. Also, who can suggest some diagnostic tools - for example, what can I run from the terminal to figure out if the CNC is online or not, and diagnose the issue.

Thank you!

I note that it doesn’t say /dev/ttyACM0 but maybe it defaults to /dev?

Is it possible you have two ACM devices and they race for the number 0?

The command dmesg will show the kernel log. You can also see whether you have multiple ttyACM devices in /dev when it fails, or zero (failure to initialize at all).

This is my UGS boot-up log:

*** Connecting to jserialcomm://ttyACM0:115200
Grbl 1.1f ['$' for help]
*** Fetching device status
>>> ?
<Idle|MPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:S|WCO:-172.534,-13.720,-12.024,0.000>
An error was detected while sending '?': (error:2) Missing the expected G-code word value or numeric value format is not valid. Streaming has been paused.
*** Fetching device version
>>> $I
Monport
[VER:1.1f.20230316:]
[OPT:VMZHL,35,254]
*** Fetching device settings
ok
>>> $$
*** Fetching device state
$0 = 10    (Step pulse time, microseconds)
$1 = 25    (Step idle delay, milliseconds)
$2 = 0    (Step pulse invert, mask)
$3 = 1    (Step direction invert, mask)
$4 = 0    (Invert step enable pin, boolean)
$5 = 0    (Invert limit pins, boolean)
$6 = 0    (Invert probe pin, boolean)
$10 = 1    (Status report options, mask)
$11 = 0.010    (Junction deviation, millimeters)
$12 = 0.002    (Arc tolerance, millimeters)
$13 = 0    (Report in inches, boolean)
$20 = 0    (Soft limits enable, boolean)
$21 = 1    (Hard limits enable, boolean)
$22 = 1    (Homing cycle enable, boolean)
$23 = 3    (Homing direction invert, mask)
$24 = 25.000    (Homing locate feed rate, mm/min)
$25 = 1000.000    (Homing search seek rate, mm/min)
$26 = 250    (Homing switch debounce delay, milliseconds)
$27 = 2.000    (Homing switch pull-off distance, millimeters)
$30 = 5000    (Maximum spindle speed, RPM)
$31 = 0    (Minimum spindle speed, RPM)
*** Connected to GRBL 1.1f
$32 = 0    (Laser-mode enable, boolean)
$33 = 0   
$34 = 0   
$35 = 0   
$36 = 0   
$37 = 0   
$38 = 10   
$39 = 0   
$100 = 800.000    (X-axis travel resolution, step/mm)
$101 = 800.000    (Y-axis travel resolution, step/mm)
$102 = 800.000    (Z-axis travel resolution, step/mm)
$103 = 800.000   
$110 = 5000.000    (X-axis maximum rate, mm/min)
$111 = 5000.000    (Y-axis maximum rate, mm/min)
$112 = 2000.000    (Z-axis maximum rate, mm/min)
$113 = 2000.000   
$120 = 200.000    (X-axis acceleration, mm/sec^2)
$121 = 200.000    (Y-axis acceleration, mm/sec^2)
$122 = 100.000    (Z-axis acceleration, mm/sec^2)
$123 = 100.000   
$130 = 1500.000    (X-axis maximum travel, millimeters)
$131 = 1500.000    (Y-axis maximum travel, millimeters)
$132 = 1000.000    (Z-axis maximum travel, millimeters)
$133 = 1000.000   
ok
>>> $G
[GC:G0 G54 G17 G21 G90 G94 M5 M M9 T0 F0 S0]
ok

Contents of dmesg - is there a way to attach text files here? Or what’s the best way to share logs…

Ahh this is frustrating - it’s actually disconnecting in the middle of jobs…

Interesting - I am using a USB-A extension cord (Male-to-Female), I wonder if there is an issue there. I will have to move the computer/CNC in order to test out a more direct connection…

[ 8500.209798] iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
[ 8500.209871] wlp1s0: Connection to AP e8:da:00:1b:45:e3 lost
[ 8519.795726] wlp1s0: authenticate with e8:da:00:1b:45:e3
[ 8519.803175] wlp1s0: send auth to e8:da:00:1b:45:e3 (try 1/3)
[ 8519.804438] wlp1s0: authenticated
[ 8519.805131] wlp1s0: associate with e8:da:00:1b:45:e3 (try 1/3)
[ 8519.806384] wlp1s0: RX AssocResp from e8:da:00:1b:45:e3 (capab=0x411 status=0 aid=1)
[ 8519.807777] wlp1s0: associated
[ 8519.845577] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready
[ 8519.890555] wlp1s0: Limiting TX power to 30 (30 - 0) dBm as advertised by e8:da:00:1b:45:e3
[ 8574.165150] usb 1-5: USB disconnect, device number 115
[ 8577.140885] hub_port_connect: 12 callbacks suppressed
[ 8577.140888] usb usb1-port5: connect-debounce failed
[ 8697.794055] usb 1-1: USB disconnect, device number 12
[ 8733.252111] usb 1-5: new full-speed USB device number 117 using xhci_hcd
[ 8733.889695] usb 1-5: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[ 8733.889709] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 8733.889716] usb 1-5: Product: LUNYEE_4axis_Control
[ 8733.889720] usb 1-5: Manufacturer: tomeko net
[ 8733.892822] cdc_acm 1-5:1.0: ttyACM0: USB ACM device
[ 8763.565173] usb 1-5: USB disconnect, device number 117
[ 8764.059992] usb 1-5: new full-speed USB device number 118 using xhci_hcd
[ 8764.209607] usb 1-5: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[ 8764.209620] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 8764.209627] usb 1-5: Product: LUNYEE_4axis_Control
[ 8764.209632] usb 1-5: Manufacturer: tomeko net
[ 8764.212506] cdc_acm 1-5:1.0: ttyACM0: USB ACM device
[ 8800.361197] usb 1-5: USB disconnect, device number 118
[ 8801.155888] usb 1-5: new full-speed USB device number 119 using xhci_hcd
[ 8801.495896] usb 1-5: device descriptor read/64, error -71
[ 8845.659729] usb usb1-port5: Cannot enable. Maybe the USB cable is bad?
[ 8889.287603] usb usb1-port5: Cannot enable. Maybe the USB cable is bad?

Using cable directly - so far so good, and not seeing the message about bad USB cable. I tried both USB extension cables I have - both had this issue, which is a bit odd… Perhaps Linux compatibility? Or the CNC signal is very sensitive…?

[   30.252848] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready
[   39.970895] usb 1-5: new low-speed USB device number 3 using xhci_hcd
[   40.123107] usb 1-5: New USB device found, idVendor=046d, idProduct=c018, bcdDevice=43.01
[   40.123122] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   40.123129] usb 1-5: Product: USB Optical Mouse
[   40.123134] usb 1-5: Manufacturer: Logitech
[   40.126418] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/0003:046D:C018.0003/input/input19
[   40.126883] hid-generic 0003:046D:C018.0003: input,hidraw2: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:14.0-5/input0
[   80.465375] usb 1-3: new full-speed USB device number 4 using xhci_hcd
[   80.615012] usb 1-3: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[   80.615027] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   80.615034] usb 1-3: Product: LUNYEE_4axis_Control
[   80.615039] usb 1-3: Manufacturer: tomeko net
[   80.629008] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[   80.629029] usbcore: registered new interface driver cdc_acm
[   80.629031] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 1067.371689] usb 1-3: USB disconnect, device number 4

I will need an extension cable at some point!

The:

lines are the ones that show when the disconnects happen, and the device descriptor read/64, error -71 line implies a signal/comms error.

All of these suggest a bad cable/connector, or some sort of interference happening on the USB cable.

  • Can you relate this to anything? Does it happen when spindles switch on etc?
  • Is it a USB-Micro connector on the control board? If so; try more cables. Reduce the cable length as much as possible.
    • USB-Micro is the worst connector ever and I have had occasions where three or four cabes in a row fail before I find one that can actually make reliable contact.

I’m thinking of mechanical (intermittent wires, dodgy contacts, dirt in the connector) issue here. Linux’s kerel support (aka: drivers) for USB serial is very solid.

One trick is to look at the main system log to see the errors instead of using dmesg (which produces a long output and only shows kernel messages)

  • If you open a new terminal window and run sudo journalctl -f you will see the current full system log in real-time.
    • You can also run journalctl as a ordinary user; but will only see items you have permissions to see.
  • The -f option tells journalctl to ‘follow’ the log. This makes it easier to see the errors as they happen and, maybe, relate them to disturbing the cable, spindle speed changes, etc.
  • I do a lot of development work on linux with ATMega, Expressif, and RPi microcontrollers and USB serial sonnections. My experience is that it is always the cable or connector at fault. The Software side of things (Kernel USB+Serial drivers) is very robust.
Example
owen@moos:~$ sudo journalctl -f
... Several lines of older log get displayed ...
... I then plug in a ESP32 based microcontroller ...
Mar 01 16:20:43 moos.easytarget.org kernel: usb 4-2: new full-speed USB device number 3 using xhci_hcd
Mar 01 16:20:43 moos.easytarget.org kernel: usb 4-2: New USB device found, idVendor=303a, idProduct=4001, bcdDevice= 1.00
Mar 01 16:20:43 moos.easytarget.org kernel: usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 01 16:20:43 moos.easytarget.org kernel: usb 4-2: Product: Espressif Device
Mar 01 16:20:43 moos.easytarget.org kernel: usb 4-2: Manufacturer: Espressif Systems
Mar 01 16:20:43 moos.easytarget.org kernel: usb 4-2: SerialNumber: e4b0638b6a30cb3f
Mar 01 16:20:43 moos.easytarget.org mtp-probe[12295]: checking bus 4, device 3: "/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-2"
Mar 01 16:20:43 moos.easytarget.org mtp-probe[12295]: bus: 4, device: 3 was not an MTP device
Mar 01 16:20:43 moos.easytarget.org kernel: cdc_acm 4-2:1.0: ttyACM0: USB ACM device
Mar 01 16:20:43 moos.easytarget.org kernel: usbcore: registered new interface driver cdc_acm
Mar 01 16:20:43 moos.easytarget.org kernel: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Mar 01 16:20:43 moos.easytarget.org mtp-probe[12298]: checking bus 4, device 3: "/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-2"
Mar 01 16:20:43 moos.easytarget.org mtp-probe[12298]: bus: 4, device: 3 was not an MTP device

A final nuisance is that the tty device number tends to swap between /dev/ttyACM0 and /dev/ttyACM1 at each disconnect reconnect cycle. Especially when the reset is pressed on the controller.

  • This is a race condition (I think actually it’s a bug… but the developers take a different view), and super annoying when it happens.
  • The previous device assignment has not been fully dropped before the new connection request arrives, so the ‘first available number’ is assigned each time, and it flips between 0 and 1.
  • This doesn’t always happen, but is worth being aware of. If you see the controller ‘disappearing’ after a reset then reappearing if reset again, check th elogs and make sure the /dev/ttyXXXN number is not changing…
2 Likes

This, very much.

Router spindles create a great deal of EMI and in radio we say “every wire is an antenna” — try a common-mode choke on your USB cable.

Then if that doesn’t fix it, you can move the common-mode choke to a higher-quality USB cable; you haven’t wasted money.

For a common-mode choke, the easiest thing is snap-together ferrite beads — it’s usually more effective to use a single larger ferrite and run the cord through it multiple times than to use multiple smaller ferrites. However, for a snap-together ferrite, it will not work much at all unless it snaps all the way together; the halves of the ferrite material inside the plastic shell should be touching to complete the magnetic circuit. So don’t run it through so many times that it can’t close.

You can also put ferrite beads around signal wires for things like end stops. When you do that, it’s important to put both both the signal and ground (or signal, power, and ground if you have optical endstops) through the same ferrite in the same direction; that’s what makes them “common mode” chokes. Again, multiple turns will do better than just one. (Each time through the middle is called a “turn” so just clamping it over the wire without making a loop at all is called “one turn”.) But just a few, you don’t need to go crazy. If you can’t make more turns, you can clamp on extra ferrites in a row; that is slightly less effective but is often good enough.

You can buy sets of multiple sizes of ferrite beads for not a lot of money. I bought a set of 80 of them for $21, an assortment with inside diameters of 3, 5, 7, 9 and 13mm.