Hey Dave,
I just read this thread and there were some suggestions towards RAM (random access memory) limitation. As you maybe know, RAM is the only memory that a CPU can access directly, the CPU computes and changes the contents of the RAM directly. So when you load a file, usually it’s good when the RAM on your computer is large enough to hold the file entirely. If it can’t, it will try to swap out parts of its memory into a swap file or a swap partition. This is called memory paging. On the Onefinity Controller that contains a Raspberry Pi 3B, which is a single-board microcomputer mainly for embedded or experimental purposes, the RAM is not extremely big (1 GB) and there is a swap file on the operating system’s SD card of 1 GB too. The problem is, when the swap file is on the SD card, and the RAM is full, it starts to swap out memory contents to the SD card and that is rather slow. That are permanent storage I/O operations. The CPU may then encounter “Wait for I/O” states. Swapping always strongly reduces the speed of operation of a computer, and here it is even slower since on Raspberry Pis <=3, the mass storage device is no fast hard disk or SSD attached to PCIe, but a SD card, which is a flash memory that is attached to an Arasan External Mass Media Controller.
I don’t know if this is the case with your file that it is too big to prevent swapping, but how big is your laser toolpath file before you upload it to the controller, when you try to laser a picture file (which one can expect to be big, MUCH bigger than a vector graphics file) and/or increase the dpi – I mean a file where the “stuttering” issue appears?
By the way on the Onefinity Controller, you can show memory and swap usage with the commands ‘free’ or ‘htop’ (shown below) on the command line interface (e.g. via ssh login). You could load a file and see if memory gets rather full and swap usage starts to grow when opening the file and while it is processed.
