Just updated to the v0.9.22 and was sending a file to the laser (I upload first, then run from the laser after). It’s a standard size 5x7 that I make on a regular basis which is a BMP image and a cut.
Seems like it took much longer to ‘send’ to the laser than with the previous version. Has anyone else noticed it taking longer? Maybe its my imagination… but it really seems to be taking longer now.
UPDATE:
I used a stopwatch when sending the file on the new 9.22 version. 50.99 seconds
Installed the old 9.20 and sent the exact same file… 9.86 seconds!
It is taking 5x longer to send the exact same file in the new 9.22 version.
Well its the SAME file and settings as before. I open the file, change the BMP (already sized to 5x7) and then send to the laser. So no change in ramp length (which is zero anyways). And being the same size image over and over for the past 3 years, I’m pretty used to knowing how quickly the file is sent to the laser for storage.
Boss 1416 laser, Rudia controller.
I used a stopwatch when sending the file on the new 9.22 version. 50.99 seconds
Installed the old 9.20 and sent the exact same file… 9.86 seconds!
So yeah, there is a problem for sure somewhere! I can’t imagine how long it will take to send a 9x12 bmp image over! I’m sticking with 9.20 for now.
Si effettivamente succede anche a me che quando mando in stampa il file spesso impiega molto più tempo di prima con la vers 9.20 ma da quando l’ho aggiornato fa questo problema ma non solo con l’avvio dellastampa anche per aprire qualche impostazioni oppure x fare il frame, all’inizio pensavo che era il pc ma poi ho capito che era la nuova versione il mio controller e un RUIDA 644XS LASER DA 50W
La 9.20 funziona per me, quindi per ora rimarrò con quella versione. Ma spero che riescano a risolvere il problema perché vorrei utilizzare le nuove funzionalità.
The 9.20 works for me, so I will stay with that version for now. But I hope they can figure out the problem because I would like to use the new features.
Same laser, same file. I updated to the new version and it took 5x longer to send files. So I changed it back to the old version of LB and it’s back to normal.
If so, I’m pretty sure I know what’s doing this, and why. A simple change that you can do on your end is this:
Click ‘Devices’
Double click your controller
Click Next on the first page (Ruida)
Change from ‘Serial/USB’ to ‘Packet/USB’
Click Next until you get to the end
This is to do with the new temporary connection system, and is probably the underlying serial device system “holding” data, waiting for it to be a little bit full before it starts to send. The packet system works differently and doesn’t have that wait.
I’ll do a bunch of testing with larger files here and see if I can figure out why that delay is happening. How large (in kb) is the total size of the file you’re sending?
Looks like I don’t have a “Rudia” controller showing in the windows device manager at all. It is a USB Serial Port connection. Its a BOSS 1416 which originally came with RDworks. I still have files in RDworks that I use on rare occasion, so I don’t want to screw things up. It IS connected with a USB wire from the computer. Not sure why the “serial” designation unless it had something to do with the original software.
Not sure what to do here because the 0.9.20 version and previous versions work perfectly fine.
Did you do the Packet/USB thing I suggested above and that didn’t work?
The FTDI device is a virtual serial port, but it can work in either “direct / packet mode” or just like a serial port. The packet thing uses the same physical hardware and drivers, just through a different code path than the OS serial system. FTDI’s serial side has a bunch of stuff in it to try not to waste bandwidth by “clustering” data up. With the packet mode, it’s LightBurn itself that controls that clustering, so it’s much more direct.
I have figured out why this is happening, and I have a fix for it, but because this is in the communication system we’re going to have to put this through a bunch of testing - we’ve already had a few issues with the temporary connections, and I don’t want to cause people more issues.
Having said that, the packet method above is not affected by this (I verified) so that will bypass the problem.