Yep, I've seen that, not figured out what exactly the issue is, but in my fresh installed win8 64bit system then it did that. Created the props file, but did nothing else. I assume any errors are being swallowed up inside the javaw / processing app process.

It started working with my unbranded webcams when I put quicktime and WinVDIG 1.0.5 on. But with my logitech webcams, nothing works.

The new features in the controller are the webcam stuff and the pen lift height setting. Either version of firmware or controller should work with pretty much any other version of firmware or controller.

It's clear to me that the webcam functionality built in in the standard libraries in processing aren't up to scratch, so I've just committed a couple of changes to the git repo (https://github.com/euphy/polargraphcontroller) that remove those libraries, and I'll work on getting it to use the loaded bitmap image as the source instead of the webcam. So it will still do vector tracing (because that bit is kinda neat), but not live stuff. It should be reasonably easy to revert if anybody wants webcam back, and in time I'll figure out a better way of doing it. I'm pretty keen not to start branching.

In the meantime, the non-webcam code is in the repo, check it out and have a look if you want to. It's a bit untidy, but it'll run at least.

Wrt your custom mods - I'm not sure what changes you have exactly, but if you come up with a way of bundling your changes up into a separate file (like a config), I am happy to look at changing the structure to make it more open to adaptation.

sn

It must have been the compiled version that I tried (32 bit because of 32 bit java installed), because otherwise I would have been able to look at the errors as they happened.

I'd never bothered putting logging stuff in because I'd assumed everyone would be running from source, and would therefore have the processing console available to them, but most people seem to run the app externally now.

I'm a bit disappointed in win8 - I was very much on board, I think it looks cool and everything, but it's just been a bit flakey. I just reinstalled this week it on my desktop machine, and that's only four months after replacing my win7 installation that had been running solidly for the last two years. Github completely stopped working, chrome was misbehaving, and wouldn't work from one user account. Just weird, unexpected stuff. The unsigned drivers thing is slightly comical.

Re SD, I think there might be a smarter way of doing the SD stuff, like a different library. I'm leaning back towards the idea of using a GRBL-based firmware to get lookahead and command buffering, and so I'll look at how the 3d printer firmwares (sprinter or marlin) do SD re-initialisation. However, I've been here before, and recoiled at the complexity of grbl then too.

Speed fix - there's a delay in the serial comms receiver, and it was long. Now it's short! I tried to get rid of it entirely, but that caused big problems corrupting the incoming messages. I might be imagining it, but it seems fast on some setups, but not on others. On my little DRBO at home, it's lightning, on the big machine at the studio, I don't notice much improvement. Must be weaker electricity there....

sn

Hello, welcome 🙂 What was the properties file called if not default.properties.txt? The time I got this, I eventually concluded that I was running a wrong bit-sized executable. So I was running a 32bit executable on a system with 64 bit java, or (more likely) a 64 bit executable on a system with 32 bit java installed. That still happens, even now. I didn't ever put 64bit java on because I heard it was still pretty flakey (when this thread started), and learned that the executable has to match the bitness of the target JRE rather than the bitness of the computer or the OS.

sn