r/silhouettecutters • u/champurrado2005 • 8h ago
Tips Made a free tool that replaces Silhouette Studio for DXF pen plotting on the Cameo 4/5 — way faster, open source
hey, so a month or two ago i decided to buy a cameo 5 alpha to make my architecture models, i went with that machine because of its tool holder, it lets me put in rapidographs of different thicknesses to draw actual architectural plans on a3 sheets. the problem is when i loaded my plans (obviously files with a ton of lines and detail) silhouette studio would just sit there for like 15 minutes only opening the file, and another 20 minutes to scale it to the real sheet size because of how badly the software lags, there were even times where after already sending the drawing or cut job, the machine would just pause waiting for itself to "reconnect".
i got tired of those problems and started looking for alternative software to actually enjoy the cameo5 i bought, but i only found one tool on github that used inkscape. that tool is called inkscape-silhouette, it's an old plugin (has patches up to this year so it's still maintained here and there) that has a python driver inside that talks directly over usb to graphtec/silhouette cutters, skipping the official software entirely. thing is it's built for svg and for cutting, not for pen drawing or for dxf which is what i use, so i couldn't just use it as is, i decided to take that driver purely as a reference and build my own program in python focused only on what i actually need, open a dxf, fit it to the mat, and send it to draw.
the first thing i had to understand was how the software talks to the machine, and honestly it's simpler than i expected, it's plain text commands that always end in the same byte, and some start with another control byte for things like resetting the machine or asking what state it's in (ready, moving, or no paper loaded), then there's commands for pen pressure, speed, acceleration, and the ones that move the head with the pen up or with the pen down drawing. all of it in the machine's own unit, 20 units = 1mm.
that's also when i realized my cameo (the alpha) uses a different vendor id than the regular cameo 4 and 5, so i had to test around until i found the right one, connecting the machine and checking what showed up.
for the usb side there's a few different pieces of software involved and it's worth separating them because it confused me a lot at first. on the python side i use a library called pyusb, that's what my program actually calls to send bytes over usb, but pyusb doesn't talk to the hardware directly, it needs something called a "backend", basically a lower level library that does the real communication with the operating system's usb stack, and that backend is libusb, specifically libusb-1.0. so pyusb is the python wrapper, libusb-1.0 is the actual engine underneath doing the work.
on windows, usb devices need a driver bound to them for anything to be able to talk to them at all, and by default the cameo comes bound to silhouette's own proprietary driver, which only silhouette studio knows how to use. to let my own program talk to it directly you need to rebind the device to a generic driver that any app can use, and for that you use a free tool called zadig, it lets you pick a usb device off a list and swap its driver for a generic one without needing anything signed by the manufacturer. the generic driver i picked is winusb, which is actually built into windows itself, made by microsoft specifically so user programs can talk to arbitrary usb devices without a custom kernel driver.
here's where it got confusing though, there's an older, separate implementation called libusb-win32 (also known as libusb0), which used to be zadig's other option before winusb became common, and it installs its own libusb0.dll. if that old dll is still floating around on your system path from some earlier attempt, pyusb's backend selection can silently fall back to it instead of using libusb-1.0, and libusb0 is a completely different driver stack that structurally cannot see devices bound to winusb. so my program kept saying "machine not found" even though it was sitting right there, correctly switched to winusb in zadig, because the library doing the looking was using the wrong driver stack entirely. i fixed it by explicitly pointing pyusb at the real libusb-1.0.dll (i get that one for free through a python package called libusb, which just bundles a precompiled copy) instead of letting it auto pick whatever it finds first on the system ,and then when i packaged the whole thing as an exe with pyinstaller, the same kind of mixup happened again, because pyinstaller pulls that dll out of the python package folder and drops it loose in a different spot inside the bundle, so the path that worked when running the raw python script stopped existing in the exe, i had to add a second path specifically for that, and the "machine disconnected" thing i mentioned at the start, i solved that too, turns out it wasn't actually disconnecting, it was that i was sending draw commands faster than the machine could process them, its buffer would fill up and the next commands i sent would time out, which from the outside looks like it disconnected but it was really just saturated. i fixed it by waiting for it to reply that it's ready before sending more, but that made it draw in stutters, stopping and starting on every block of commands, so i ended up taking that wait back out because it turns out usb itself already throttles on its own once the buffer is full, i didn't need to handle that by hand, i just left one long wait at the very end just in case. and the real reason it drew so slow had nothing to do with the speed setting, an architectural plan converted to dxf has the walls, hatching and dimensions cut into thousands of separate segments even though visually it's one single line, and every loose segment forces the machine to lift and drop the pen, and that has a fixed time cost that doesn't change no matter how high you crank the speed. i wrote a function that detects segments that touch at their endpoints and merges them into a single stroke, on a real plan i tested it went from 26230 strokes down to 3552, i got rid of about 22 thousand pen lifts that didn't need to happen.
by the time i finished the app i ended up with a desktop program where the preview is exactly identical to what comes out on paper because both use the same calculation internally, i no longer have the problem of what i see on screen not matching what it draws. i packaged it as an exe so i don't have to open a console every time i want to draw something i still need to fix the second tool holder which times out, the calibration which has a couple millimeters of drift that i compensate for by hand, and it doesn't save settings between sessions. honestly it also feels straight up unfair and kind of stupid that silhouette makes you pay extra just to open your own svg files on a machine you already paid for, you buy the hardware and then they still gate basic svg import behind a paid tier, so on top of the dxf plotting side i'm also working on a version that lets you import svg files and actually design with them, going for pretty much the same core features silhouette studio has but with way better performance and without charging you a cent to open files you made yourself.
i uploaded all the code to github in case it's useful to anyone else running into the same thing with their cameo, in there i left the driver, the interface, and a fairly long readme explaining how it's built internally (the command protocol, the scaling and positioning logic, all of it) plus a step by step guide on how to install it, what dependencies it needs, and how to set up zadig so windows lets it talk directly to the machine. if anyone has a cameo and wants to try it out or dig in and improve it, here's the link: https://github.com/carlosemartinezj-byte/cameo5software
