USB forwarding of the SnapMaker

My SnapMaker resides in the basement. If using Luban, I can access it via WLAN, of course. But more advanced software like Cura or LightBurn does not have this access.

Consequently, we need to enhance the connectivity of the SnapMaker. By its USB port, I attach it to a Linux machine nearby. In my case this is a nice little micro PC, but any decent Raspberry Pi does the job. On this Linux machine I run OctoPrint, connecting to the SnapMaker and pretty nicely administrating all 3D print jobs. But, still limited to 3D printing and not tailored to either Laser or CNC operation. Files generated by Cura or any other software can be uploaded, though.

I order to access the SnapMaker directly from LightBurn or Cura, we need to do something else: Forwarding the USB port of the SnapMaker via network to a different computer.

In order to do so, some software has to be installed on the Linux machine that resides next to the SnapMaker:

sudo apt install linux-tools-generic hwdata

Part of these tools is the host for USB forwarding. The kernel module is started by

sudo modprobe usbip_host

In order to have this to start automatically when the machine boots, issue

sudo echo ‘usbip_host’ >> /etc/modules

To test for the proper status of the module, boot your SnapMaker and issue the command

sudo usbip list -l

on the attached Linux machine. The output should contain two lines similar to the following

busid 1-3.2 (1a86:7523)
QinHeng Electronics : HL-340 USB-Serial adapter (1a86:7523)

The busid shows in which way the SnapMaker (which has the HL-340 USB-Serial adapter built in) is connected to your Linux machine. Write down this busid, which my be different in your case.

We now bind the SnapMaker USB port to usbip by issueing

sudo usbip bind -b 1-3.2 (of course with your actual busid)

and start the usbipd program

sudo usbipd

We do not start this as a daemon, since we might kill the port forwarding when using the local OctoPrint server.

As a final check, test wether the SnapMaker is exported properly:

sudo usbip list -r localhost

which results in an output similar to the following:

Exportable USB devices

  • localhost
    1-3.2: QinHeng Electronics : HL-340 USB-Serial adapter (1a86:7523)
    : /sys/devices/pci0000:00/0000:00:15.0/usb1/1-3/1-3.2
    : Vendor Specific Class / unknown subclass / unknown protocol (ff/00/00)

Next, we switch to the machine running LightBurn - in my case my laptop computer. For the moment we say it is a Linux machine as well. Of course, it needs the client side of the usbip software:

sudo apt install linux-tools-generic hwdata

from which we take a kernel module

sudo modprobe vhci-hcd

Automatically starting this at boot time means to issue

sudo echo ‘vhci-hcd’ >> /etc/modules

We can then test if the SnapMaker is available by issueing

sudo usbip list -r

which results in an output similar to

Exportable USB devices

  • 192.168.0.xx
    1-3.2: QinHeng Electronics : CH340 serial converter (1a86:7523)
    : /sys/devices/pci0000:00/0000:00:15.0/usb1/1-3/1-3.2
    : Vendor Specific Class / unknown subclass / unknown protocol (ff/00/00)

As the next step, I include this USB port into the local USB structure on my laptop computer:

sudo usbip attach -r <IP address of the …> -b 1-3.2

And, voilá, questioning the USB devices on my laptop by

sudo lsusb

then also includes the following line

Bus 001 Device 008: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Consequently, on my laptop I can then use the remote SnapMaker as if it were attached locally !

One more thing needs to be done in order to find it also by LightBurn, because at the moment the imported USB port can only be opened by root. So issue

sudo dmesg | grep USB

which tells us to which serial port the SnapMaker is attached, in this case /dev/ttyUSB1

[ 416.421307] usb 5-1: new full-speed USB device number 2 using vhci_hcd
[ 416.592190] usb 5-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 416.592200] usb 5-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 416.592204] usb 5-1: Product: USB Serial
[ 416.638979] usbserial: USB Serial support registered for generic
[ 416.639706] usbserial: USB Serial support registered for ch341-uart
[ 416.652698] usb 5-1: ch341-uart converter now attached to ttyUSB1

My final command then is

sudo chmod 666 /dev/ttyUSB1

Of course the change of the permissions can be made permanent, in the usual way.

And LightBurn connects very nicely to this port:

6 Likes

Intense, thank you for sharing the write up.

Did you think of using USB over Ethernet?

I’ve been using such adapters for many years.

No solution in this case, because the SnapMaker USB is connected to the OctoPrint server.

pah

1 Like

I’m sorry, I don’t get why it can’t be solution for this. I hope translation doesn’t kill communication here =)

I made a sketch on the white board, it’s editable, you are welcome to draw there - Witeboard

@nweolu I think you’re slightly confused. The link you sent is for connecting a network adapter (modem) to the USB port, and the SM can then connect to that network with a hardwire instead of Wi-Fi.

What @profhenning has outlined here is how to hook up an rpi as a USB proxy over Ethernet server, so the server (rpi connected to the SM) can receive a connection from a client (some other computer) and that client will see the server’s USB connections as local connections, allowing the client to connect to the SM as if it was directly plugged in over USB.

The issue with this is that you can really only have one system controlling the USB ports on the rpi at a time, so you can either let octoprint take control, or let the USB-proxy-over-ethernet have control.

If you really wanted to not have to switch between the 2 (should be doable with a simple script on the rpi, and I bet you could even use a plugin in octoprint to trigger it), you could have 2 rpis, one acting as an octoprint server, one acting as the proxy server, and then you’d only have to switch which client (octoprint server or your laptop running lightburn) is connected to the proxy server, although IDK if the software makes it easy to switch between clients connected to the proxy server.

@nviekmai, correct. The script for switching between Octoprint and the usbip is already in operation.

LG

pah

1 Like

Remote laser control in lightburn is not implemented because of security issues. Beware using your laser remote.
Usbip is not reliable. If you have a network hiccup, it could be possible that your laser stands still in 100 % laser mode and makes a fire. It will simply stop getting gcode commands from your control host.

Usbip could loose connection because of: power spikes, network load, hibernation of laptop and so on.

Found the solution by myself half a year ago, tested it and stopped using it because of unreliability.

1 Like

First of all, you should never let a laser with ignition capability run unsupervised. And yes: supervision can also be done with a live camera feed, as is done in professional laser cutting systems.

Secondly, any laser system should have a high temperature safeguard. In my case, a temperature sensor in the enclosure cuts power to the SnapMaker and surrounding devices if necessary. If you do not know how to set up such a system, I recommend reading one of my books on home automation.

Third remark: The arguments that you use against remote laser control via LightBurn apply also to remote Laser control via Luban. You don’t suggest taking this feature away from Luban, do you?

pah

this is great stuff guys.

@nivekmai
Sorry, not sure where you got the modem part. profhenning has it connected to octoprint first, then USB forwarded to the laptop. Or I might be confused as you say. Anyhow.

Something like 1 Port USB over Cat5 / Cat6 Extender - USB Extenders | StarTech.com can be used to extend the USB over Ethernet if direct connection is needed. Or an fiber optic usb cable - some pulling involved, but great distance with same low latency.

Some confusion I do indeed see here.

1.Octoprint is a backend server - not a frontend for modeling or gcode generation. The Octoprint server accesses the SnapMaker via USB, like Luban does if directly connected. In this case, there is no USB forwarding, as Octoprint has a nice Web UI as well as an API.

2.USB forwarding is needed only when Octoprint is disconnected from the SnapMaker - and this is necessary because Octoprint is not (yet) suited to handle Laser or CNC jobs. USB forwarding then is done to connect the SnapMaker to LightBurn. LightBurn (unfortunately) combines job processing with a modeling frontend, and (unfortunately) does not connect to the SnapMaker via WLAN (as does Luban).

And since I do not like the idea of manually unplugging the USB cord from the micro PC running Octoprint into any hardware USB extender (and back again), software is the only solution.

In the longer run, I hope for a Plugin to Octoprint which may be accessed from LightBurn.

pah

There is a difference that increases safety using Luban (or my drag/drop auto start). Trying to use Lightburn remotely is still sending line by line, any disconnect or hiccup could make the laser stop and wait for the next command with the laser full power, potentially creating a fire.

Luban, however, actually sends the entire file to the machine and runs it. Luban then simply monitors and shows the status every second. You can close Luban entirely and the project will continue to run unimpeded instead of potentially freezing up from a drop in network, long as you don’t tap the stop button on the touchscreen.

2 Likes

I consider this a marginal increase in safety, as a “hiccup” can also occur in other places.

And, again: No operation of the laser if not supervised. See my post on case modding part II: Adding a video camera was one of my first issues.

LG

pah

Snapmaker makes a plug-in for Cura that works great with the machines Wi-Fi connection, and there’s always octoprint that also has snapmaker plugins.

1 Like

The Snapmaker plugin for Octoprint is, unfortunately, for the original Snapmaker and does not do anything useful with a Snapmaker 2.0 (last development steps 5 years ago). I have started a fork, but this will take time…

The Snapmaker plugin for Cura can send a gcode file to a networked printer- but this is not “control of the printer”.

The use case for USB forwarding still exists.

Regards

pah

For the archival value, adding the fresh ltt video about extenders -

Also added this good stuff thread to GitHub - shurushetr/awesome-snapmaker: Curated list of things that help you make something awesome with Snapmaker machines.