I’m happy to announce that the osPID is now officially back in stock at Rocket Scream. There have been some improvements to the hardware (usb micro instead of mini, louder buzzer, etc,) but mostly this was about getting a more reliable supply chain in place.
Thanks to everyone for being so patient during this dry spell. The changes we’ve made should insure that moving forward, when you want an osPID you won’t have to wait.
A fantastic project has been making the rounds over the last two days: Hakerbot Labs put together a monster laser that pierced the sky at Toorcamp. Continue reading
The osPID Kit is back in stock and ready to ship. Continue reading
We have just picked up our batch of assembled osPID Kit boards from the factory. They all come in panels and it feels so much relaxed to have handed the assembly task to the factory. We are currently checking and testing all the boards. Continue reading
It has been months since the last osPID kits went out the door. We have been working hard to make the necessary changes to the design in order to adapt it to automated factory assembly. Continue reading
We now have our very own documentation wiki! It is still needs a lot of work, but the basic structure is there. Over time we hope this grows into a powerful resource for the osPID user-base.
Anyone is free to create an account and edit, so feel free to add content. Be advised however, that this is a moderated wiki; all edits are subject to moderator approval. We felt this was the best way to allow for user-modification, while protecting against spam.
I’ve just uploaded both firmware and front-end updates to github. There have been numerous tweaks and improvements, be here are the high points:
Rather than hard-coding a reflow profile, we went with a more flexible approach. Using 3 different commands (setpoint STEP, setpoint RAMP, input WAIT) you can piece together a sequence that gives you your desired result.
Different profiles are stored as files on the desktop side. One profile at a time may be loaded onto the osPID and executed. The profile is stored on the osPID EEPROM, so loading is only necessary when you wish to change the profile.
IO Card support
The previous version of the firmware was pretty much hard-coded for the digital output card and temperature input card. This firmware breaks out all the IO code into a separate file, where pre-compiler flags let you specify which cards are being used. This should simplify card-swaps and prototype-card usage.
The previous version of the firmware made awful use of the osPID’s resources. It used WAY more RAM than necessary, and only left 5k of free program space. In addition to adding a bunch of new features, the new firmware is much better on RAM usage, and leaves over 9k of free program space. This means that if you have the itch to hack the osPID, there’s actually some room for you to do so.
There’s always more work to be done, but I’m pretty happy with what we’ve managed to accomplish with this revision. As always, let us know if we messed up; everyone will benefit.
With actual osPID units being spotted in the wild, we felt is was time to create a forum.
The goal here is a create a central place where people can get information, show off their awesome projects, and help to improve the osPID for everyone’s benefit.
So stop by when you get a chance. Help us leverage the power of open source to turn the osPID into the best PID Controller it can be.
Huge thanks go out to Phil, who apart from identifying some early bugs has presented us with our first “in the wild” pictures!
He spent an hour or two the last couple of nights setting up a sous-vide rig: Two immersion heaters, a circulation pump, and a k-type thermocouple.
It’s hard to argue with results my friends. Being an engineer, there’s always a part of me that’s waiting for that huge flaw that I missed, the thing that will make what I did a complete failure. But it has not come to pass. osPID = tasty results. I’m over the moon.
With the first osPIDs making their way to customers, we’ve started receiving our first feedback emails.
The most obvious point made so far is that we were lacking a quick-start guide. I’ve since created a preliminary page for this here. This is a work in progress, but should give you everything you need to get up and running.
The second prominent issue was that the input card wasn’t reading correctly. This is strictly a firmware issue related to the switch from the MAX31855 back to the MAX6675. What this means is that everyone will need to update their firmware. DOH! The quick-start explains how to do this.
There will undoubtedly be more issues as the days go by. PLEASE complain to us. We will fix it and everyone will benefit. The only way we will be great is if we are told when we suck.