![laserdrw 3 cutting out of order laserdrw 3 cutting out of order](https://uclalemur.com/user/pages/05.blog/58.tutorial-for-laser-cutter/Laserdrw_change2.png)
So it sits there pretending to be grbl server, I am doing the same thing for RDWorks and pretending to be a ruida device and. One of my current side projects within MeerK40t is to get Lightburn working through it. It's only like 4 packets ahead, If I stop sending packets it stops in a couple seconds. But, with the way Visicut's front end is setup, I can't even just suspend packet sending because there's no hook for that. In MeerK40t when you hit escape it launches an adjustments window but also, instantly pauses the job in progress. Like there's a realtime pause command for the M2 board.
![laserdrw 3 cutting out of order laserdrw 3 cutting out of order](https://content.instructables.com/ORIG/FPR/7MZV/IE7J82MI/FPR7MZVIE7J82MI.png)
But, since Visicut is made for send it to the laser like operations, and do no monitoring of the job or control of the job. Yeah, that lack of cancel is annoying too. Though Scorch took a shot at duplicating that and messed up the states and produced a faulty version of Whisperer. Good command efficiency lets you shove like 50% more commands in there. Since its constantly just streaming the data at the machine which uses 128 bytes of local buffer, and can burn through those ~4 packets pretty quickly if it's doing some commands like a bunch of turn laser off, move by 1, turn laser on, move by 1, running at a fast speed it can finish all those commands very quickly, and be forced to decelerate. The underbuffer causes a stutter in the machine. The end result is you get rasters that don't underbuffer nearly as easily. You can save the state of the stepper direction forward/back toggle on the x-stepper and y-stepper chips and the state of the last executed direction to skip some of these superfluous mode switches. I've since mapped out the better way to do it, based on LaserDrw's methods and analysis of the hardware. That said, looking at this rastering code I might consider taking another swing at it. Would look a lot weird, but would ensure whatever the first job is, it started correctly at (0,0). In theory, I could make the driver home the device, draw the part where visicut tells me it is, then make the driver home the device again when done. The homing only serves to fixed things between objects. Whisperer returns to the upper left hand corner of the part completed (or tries, it's actually off by 2 mils after a raster).
![laserdrw 3 cutting out of order laserdrw 3 cutting out of order](https://i.ytimg.com/vi/t8csFQTgGMw/maxresdefault.jpg)
MeerK40t for example just stops exactly where it finished and stays there, or goes to the next part exactly from that location. The issue of homing is that the first engrave operation is assumed to be 0,0 and you might have the head moved, either manually or from something else. So saving the driver state wasn't an option. Visicut seemed pretty geared towards sending all the data to the device and be done with that device. In the lcode file the command "IPP" at the end tells it to home the machine. If I left the laser head at (500,1000) and the it sent the next job as a different event it would think it was at 0,0, and would be off by half and inch and an inch respectively. But, this left an issue that between jobs it wouldn't know where the laser head was actually located. The visicut system would work really well for protocols like Moshiboard, and GCode systems without any realtime controls.Äesignwise, I didn't want to move the laser head when it wasn't needed since I tracked the exact expected position within the driver itself at all times. It's one of the reasons I coded up MeerK40t since I could add such things. Visicut didn't have any jogging or positioning controls or realtime command systems. (Any initial position is considered to be 0,0 and may not be).