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.
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.
To Everyone who pre-ordered: Thank you, your unit is in the mail.
There are a few extra units that are being assembled as I write this. we’ll announce on twitter when orders are open.
We’re also working on our 2nd (larger) batch. hopefully this will remove availability as an issue.
Things are finally rolling at osPID HQ. All of our parts are either on site or in transit, and production will being as soon as everything arrives.
That’s the good news. The less-good news is that we’ve had to push back our planned ship date. Originally we were planning on shipping this week. Unfortunately we’ve had to push that back to the week of 2/19.
With every delay it’s good to have a scapegoat, and we’ve got one! Maxim Electronics. On the prototype temperature card, we used their MAX6675 thermocouple chip. For the production model, we decided to use their newer (and less expensive) MAX31855 chip.
When we went to order the MAX31855 however, instead of the initially advertised January delivery date, the date had been revised to July. JULY! We checked various suppliers, but this seems to be an issue with Maxim itself.
So, faced with a choice between a 6 month delay and a more expensive chip, we decided to eat the cost and revert the board back to the MAX6675 configuration we had used in the prototype.
During this whole debacle we lost our place in line with the PCB manufacturer and had to re-submit our order. Unfortunately this put us on the other side of Chinese New Year.
And that brings us to today. We want to apologize for both the delay and the chip swap. If you had your heart set on the MAX31855, know that from a financial perspective so did we. We have a board designed and ready for that chip. Once supplies of the are more reliable we will transition to it.
In the midst of this there is one recurring concern that I wanted to address. Many people seem to be comparing this thing to the $30 PID controllers you can get on ebay. I want to take this opportunity to highlight some of the features that set the osPID apart from the low-end competition.
More Sensor Interfaces
By default, the osPID can read either a K-Type thermocouple or a Thermistor. With more input cards on the way (RTD, Voltage, etc..) this allows you to use the osPID in more situations.
Desktop Configuration / Graphing Application
When configuring and monitoring a PID controller, having a graph in front of you is indispensable. The osPID comes with a free (and Open) java application that allows you to interact with the controller from the desktop. You’ll be hard-pressed to find this with any PID controller, and if you do it’ll cost you.
Settling on the correct P, I, and D parameters can be time consuming. Most expensive PID controllers provide an “autotune” which automatically determines good values. The osPID has this. Many cheap controllers do not.
Open Hardware / Software
If your $30 PID controller breaks, or it doesn’t do something you’d like it to, you’re stuck. The osPID is completely open. All software, hardware plans, and firmware code is freely available to download and modify. If you want it do something different, go for it! If a bug is discovered, it can be fixed and downloaded by everyone.
Initially from me, but ultimately (hopefully) from a community of people that have been there, with this specific controller.
So yes. It costs $85
What we have here isn’t an open knock-off of a $30 PID controller. The osPID has, in many cases, better functionality than even a $200 PID controller. Combine this with an unprecedented level of hackability and community, and I’d say that makes this a pretty good buy. (OF COURSE I would say that, but hopefully you agree.)
The website is still a little rough around the edges, but the product is ready for initial release, so here goes! Let me introduce you to the osPID:
We’ve been working hard over the last several months to build a fully-featured, open source PID controller that’s every bit as capable as its closed brethren.
(If you’re so inclined, there’s also a post on my personal blog with some introductory videos)