I’m using the Trial Version with an RPi zero 2W as a server and a Windows 10 PC as a client. I am communicating with a laser engraver (Creality Falcon 2 40 watt) (server) using the Lightburn software (client). Lightburn recognizes the laser engraver. The VirtualHere client and server appear to be working mostly properly. The default Lightburn communication settings are 115,200 baud rate and the transfer mode is Buffered (this can also be set to Synchronous with the same issue I am having).
There is a feature in Lightburn that requests machine data from the laser engraver (max speed, acceleration, true/false toggles, etc.). When I connect to the laser engraver directly through a usb cable the proper parameters are received in Lightburn. When the use the VH client/server connection a smaller set of data is received by Lightburn. When I use a RPI5 configured as a server, more data is received (but not all) and some data is incorrect (e.g., providing a true toggle instead of a false toggle). For the RPi zero 2W I’m using 800 for the USBFS_memory_mb and for the RPI 5 1000.
I tried changing the baudrate in Lightburn, Transfer Mode, the Client Compression Threshold both above and below the default 384 bytes, and the USBFS_memory_mb setting on the server.
It almost seems that the server is responding with different speed and misses data.
Any recommendations to fix this?
.
VirtualHere will never corrupt or miss data. It is impossible. So what is happening is that the latency of the link is too high and the serial chip inside your laser engraver is having a buffer underflow (or overflow) issue. You must use Ethernet if you are having this issue and not WiFi for the link.
Michael, thank you for the…
Michael, thank you for the reply. I didn't mean to imply that it was a VH fault. I was guessing that the laser engraver was communication back with a differnt speed than receiveing. Would you expect a latency issue differnce between using a RPi zero 2W and the RPI 5? These were both conencted to the same WIFI.
So far I don't know any issues with the communications from the PC to the laser engraver when commands are being sent. Does this align with you thoughts?
.
Ive seen similar issue before over the years ive been doing virtualhere. Initially i thought it was a bug in virtualhere somehow corrupting serial data. But then i investigated more and i realized that its the serial chip.
What happens is the serial<->USB chips basically have a very small buffer. They are expecting serial data to be taken from the USB bus within a certain time frame. What happens is that if there is latency in the link then the USB data will be delayed and the next data coming in from the serial port overwrites the pending data in the out hardware buffer in the serial chip. The data is eventually transmitted over the USB bus (and virtualhere) and when its reconstructed at the client side (i.e the other side of the USB "cable") the data is corrupted because its missing chunks. And so eventually the program on the client just doesn't get the data packets it was expecting, it doesn't know what to do (or crashes) and so it just sits there.
The problem with wifi for example is that it has very variable latency. Maybe you might get a spike in latency of 500ms for a brief period. During that 500ms the serial data in the chip on the server side will fill the hardware buffer. So e.g 115200bps mean 7.2kilobytes is pushed to the serial port and yet there is a buffer for e.g only 10 bytes or something.
Thank you, Michael. I just…
Thank you, Michael. I just ran a test in the opposite direction from Lightburn to the laser engraver. I had laser engraver follow a tortuous Damascus pattern with many fast short movement changes in direction, as shown below. The laser had to move 0.1 mm chunks and requires a fast data transmission to prevent the laser from pausing.
G1 X206.364 Y199.702
G1 X206.402 Y199.596
G1 X206.425 Y199.513
There was no issue in the path from LightBurn to laser engraver. Was it because the PC (client) was handling the buffering on the transmitting end and the RPI (server) was handling the buffering/handshaking at the receiving end?
The RPI 5 as a server was able to do “better” than the RPI zero 2W as a server. Was this because the RPI 5 was on the 5GHz wifi (with lower latency) versus the 2.4GHz for the RPI zero 2w? Is it possible to set RPI buffers to absorb the laser engraver output data then re-transmit when it has a chance?
.
There is no buffering in the actual pi or in virtualhere. Its not possible to buffer a signal at the USB protocol layer.
Buffering it was never written into the USB standard. The USB standard works very simply. It asks for data and then gets data in return, then it asks for data and gets data etc. Asking for data and getting data returned is what drives the USB state machine forward. It cant ask for data , ask for data etc to buffer - because there is no way for it to know what to ask for next without the data being returned one packet at a time.
Buffering is always done at a higher protocol layer. Virtualhere cant see higher layers. The pi5 will do better because the cpu is fast. If you get your wifi latency fixed under a certain amount. e.g 5ms for example then it would work fine
Michael, Thank you for the…
Michael, Thank you for the additional info. I've performed more testing to directly control the laser engraver, and it looks like for low data rate engraving the connection works flawlessly. However for high data rate engraving there is some pausing and then the engraving quits due to a loss of communication. I saw the same result even when the client (Raspberry Pi 5) was connected vis ethernet cable (the PC was already conencted to my wifi router via an ethernet cable). I'm agreeing with you that this is a laser engraver serial data buffer issue and was never design to accomodate latency.
.
Im surprised even with ethernet it does not work. It must be a really cheap serial adapter.
Do you know what type of adapter it is, right click on it in the virtualhere client and select Properties and what is the Vendor ID and Product ID?
Here is the dat when I…
Here is the dat when I select Properties:
Name: Espressif Device
Vendor: Espressif Systems
Product: Espressif Device
Vendor ID: 0x303A
Product ID: 0x4001
This is a Creality Falcon 2 40 watt laser engraver. These are made in China.
.
OK that seems to be a homegrown serial adapter VID/PID they are using...im not sure . If it was an ftdi or silabs adapter we might of been able to adjust the buffering
Simular Situation
I wish I had looked here earlier. Falcon 2 on Pi Zero 2W. Everything seemed to work great, purchased the license and kept running. When burns got larger or more complex things went down hill. Failed jobs, jobs not looking right, and jittery laser movement. Did my own head banging thinking it was a LAN issue. Using USBDeview and a USB stick did some tests. PI 4 was 5x faster on WIFI and LAN vs Pi Zero 2W. Not a 1:1 test for falcon but a way to see 'throughput.' Every test on Pi Zero 2W completed but with errors about significant changes in write speeds during test. Doing a speedtest-cli from both the server(pi zero 2w) and client(windows) get pretty good speeds +150Mbs and low jitter. Might just have to have a dedicated computer connected to the falcon at that point it might be better to just remote desktop.
.
I dont understand why people use the pi0w for this sort of thing. The wifi on the pi is not very good. Is it because of price or something?
Go wild and spend 20 more dollars and get a pi4, they are much more performant and you have an ethernet connection which i recommend if your usb devices are latency sensitive. The crappy usb <->Serial adapters they use in the falcon etc are not very good and have small buffers so thats why ethernet is basically mandatory.
Why Pi Zero 2W
On paper the platform , Pi Zero, matches the need to create a bridge. Real life you are correct WIFI performance is an issue as you state; but I think the bigger issue is the serial interference and how fast/slow the falcon processes the data it receives. Transfer speeds are now network bound and are affected by networks speeds, jitter(quality) and the load of the application. Having a "software buffer" might help to keep a steady data flow only if network speed/quality can keep data flowing to keep the buffer healthy. I have a support request into Creality to see what speed of data that needs to be sustained to the device since USB standards are a ranges and can go beyond network speeds. Not 100% confident that Pi 4b would not have similar issues in some situations since test transfer speeds only increased by 5x vs Pi Zero. Not accounting for network jitter. Pi 4b transfer speed was 160/80Mbs(hard wired network) on the lower side of USB 2 speeds vs direct connect at 864/240Mbs. (R/W tests to USB Thumb Drive)
.
Yes im happy for Creality to contact me mail [at] virtualhere.com (mail[at]virtualhere[dot]com) if they need more information
Good info! Barfunkle and…
Good info! Barfunkle and Michael, could you please share any info you get from Creality.
When I originally posted this, I was just interested in using VirtualHere with an RPi zero 2W to connect my camera to LightBurn, and it worked flawlessly. When I was doing my initial research, I noticed others trying to connect their laser engraver to LightBurn using VirtualHere with no success. Since I had an extra RPi zero 2W and an RPi 5, I wanted to do some testing to see if I could make it work to help them out. For simple things it worked fine, but the stress test that used when my VH/LB link failed was engraving an image using Jarvis as my image mode. This created gcode with bunch of very small moves with power changes to represent each Jarvis dot. I’d see stuttering and eventually, and eventually the engraver would stop.