[Brett]

in reply to: Alternatives to proportional time control for output? #4082

I haven’t heard of something like this being done. Aside from the coolness factor, what would be the advantage over just using a smaller window?

For the record, if you’re using an SSR you can safely make that window size FAR smaller. 500mS should be fine. When designing the firmware we had to assume that people would be using relays (onboard or otherwise.) The 5sec window was chosen to maximize relay life while still getting decent control in most situations.

I will also say that in my experience you can’t make the window TOO small with an SSR. It may have just been the design of the $5 SSR I was using, but it would latch on until the next 0-cross of the 60Hz power wave. I tried using the arduino PWM (50mS window I believe) and it was a disaster. the SSR just stayed full on the whole time.

[Brett]

in reply to: Interfacing with Python #4067

let me start by acknowledging that this comm protocol is a bit of a hack. it works, but it’s not something I’m particularly proud of.

the main hints I would give for reverse engineering are the following:
1. commands are always initiated by an identifier byte being sent (this corresponds to the case structure in serialreceive)
2. after that, all bets are off. each command has a different sequence of information that comes after it. both the front-end and firmware know the rules though, so it winds up working ok.
3. everything is sent as bytes. floating-point values are converted on the frontend using the floatArrayToByteArray function, and are converted back to float using a union structure. (everything you need to look at is in this file)

with the float thing. a float is 4 bytes long (same as an int on the PC side) and was the most flexible option considering that I might need to send really small tuning values (0.0001? no problem) and really large profile values (30000 seconds, etc.)

lastly, remember I wrote this two years ago, and that my specialty is pid control, not communication protocols. At this point, the arduino serial library may have advanced to the point where something far better can be written.

Cheers!

[Brett]

in reply to: Adjusting Thermocouple Reading #4047

in the firmware, the thermocouple reading is pulled in in io.h. here’s a link to the exact line. you can add a shift there.

[Brett]

in reply to: osPID as a composite bonder #4045

I think you could probably cram all the hardware in there, but a decent amount of custom work would need to be done for the osPID to fit your application. because the application is slow, you could probably use 2 digital pins to cycle through the termocouples, having them share a single input. that would leave room for your pressure sensor. from a form-factor perspective though, I’m not sure if everything would fit. 4 sensors= 8 terminal connections. the standard osPID terminal block only has 6, so you’d need to find a 8 screw block that would fit in the same space.

this says nothing about the firmware / software changes that would be needed. on the firmware, you’d need to add the thermocouple switching code, as well as some alarming stuff, and on the software side there would need to be input fields for the alarm points, as well as more trends added for the multiple inputs.

My assessment is that the current osPID can’t do it. if you’re looking for a one-off, the amount of time it would take to make would make it more expensive than a professional unit. IF, however, there was a big enough market for this, there might be economic justification for someone to run with this and make/sell a custom solution. as long as that’s open source, we’d have no issues with that.

[Brett]

in reply to: Input and Output Extension #4044

If I hack the input card, can I have it receive input from three different components?

right. those available pins are ones we didn’t use (with the exception of vref, 5V and ground. you’d be using those in parallel with the other inputs.) provided you don’t draw a ton of current, and there isn’t a large amount of extra code on the firmware side, you should be ok.

[Brett]

in reply to: Wierd Input error and hard to get no overshoot. #3957

generally , if the signal coming from the thermocouple isn’t good, the input value on the onboard display will flash “Error.”

[Brett]

in reply to: Input and Output Extension #4042

the input card has some hackable inputs (3 analog, 2 digital.) Maybe those would suit your needs?

[Brett]

in reply to: Detailed performance specifications? #4041

the Sample Time of the osPID is limited to 250mS. we were able to push it a little faster than that, but the chip has a lot of duties to perform. 250mS ensures that there’s time for everything (PID, display, serial) to get done.

[Brett]

in reply to: Dual output relay and SSR at same time #4038

to control two outputs at the same time you would need to modify the firmware a bit. definitely the output card code in io.h, and then presumably some stuff in the main program to make the outputs fire when you want them.

as far as relay/SSR for the second output. by default the output goes to the SSR terminals out the output card, but by changing a jumper you can have the output trigger a second onboard relay (not included)

[Brett]

in reply to: PID Temperature Controller and Interface #4036

after setting all PIDs is it possible to have some sort of interface such as HMI or software to control (change values, programs, …) all my osPIDs?

it’s possible, but not without some work. you could, for example, run usb back from every unit, then individually talk to each one over serial, but I haven’t gotten around to explaining the comm protocol (it’s open, but still kind of confusing) so you’d be in for some work there.

My second question is, could I use osPID as a proportional 4-20ma pressure and temperature controller?

it’s in the pipeline, at the moment no.

It sound like what you really need is a low-end PLC. the amount of work connecting that to your system would likely be far less than using multiple osPIDs.

[Brett]

in reply to: Tuning For Sous-Vide Control #3695

So the PID algorithm is linear. that means that it works best with the process behaves the same going up as it does going down. if it’s not the same it’s not usually a big issue, but if rising and falling are REALLY different (as they are in your case) then you have a problem.

put another way, the pid is adding heat to the process assuming that as it gets closer to setpoint it will be able to push the process downward as fast as it could push it upward. from a control perspective, you’d be better off getting rid of that insulation!

with the process you have, you’ll probably have the most luck with a controller that just drops the output to 0 the moment it gets anywhere above setpoint, and that means having a big Kp. If I had to re-phrase the “max limit” thing from that post, I’d say that Kp needs to be bigger than the output span (max-min) which is 100 by default.

[Brett]

in reply to: Setpoint Profiles (for Reflow et al) #3816

Dominic, I’m sorry to hear you had profile issues. you’re right. the documentation there is pretty bad. if you attach your profile code, I might be able to spot something.

as far as your suggestions, I think they’re excellent. I’ve gone ahead and added them as an issue on the github

[Brett]

in reply to: Why osPID vs Arduino with PID Library? #4035

I’d say the main benefits would be integration, both of hardware and software. on the hardware getting everything together like this can take a while. (the thermocouple chip can be a particular pain in the butt.)

on the software side, we’re looking at a fairly slick onboard ui (I’m biased of course,) autotune / setpoint profile integration, and a java (ok, processing, but still) front-end.

ultimately you can make something like this on your own, and it would probably be a fun learning experience. the goal here (other than just seeing if we could pull it off,) was to remove most of the pid work from the customer’s hands, while leaving it open so they could add anything else they wanted.

[Brett]

in reply to: Overshooting Incubator #4033

Sorry to hear you’re having problems, a couple of things to note:

• on the pid display, take a look at the value of the Output. (“O:….”) even if the output value is really low, the relay can make quite a racket. by default it has a 5 second window that it uses, so even if the output is 1%, you’ll hear a little blip every 5 seconds as the output turns on and off for 50ms.
• It’s common for the process to behave differently when under load then when empty; the rules are different. It’s sort of like taking a driver who’s used to driving a truck and putting him in a racecar, or vice-versa.
• Super-insulated processes are actually very hard to heat with pid. The pid algorithm is linear, which means that it thinks that the process behaves the same way going up as it does going down. Your set-up is not like this at all. This would explain your crazy overshooting. The pid is expecting that it can back off on the output and the temperature will come right back down as fast as it was going up.

some possible solutions:

• Intentionally remove some of the insulation. Counter-intuative I know, but this will allow the controller to truly be able to back off.
• Whatever your values of Kp, Ki, Kd, divide them by 10. This will make the controller way more conservative, and should let you rise up more slowly, although there will still probably be some overshoot if it’s still well-insulated
• A little more complicated but the most likely to give you what you want: ramp the set-point. Either by hand, or using the built-in setpoint profile feature. slowly raising the setpoint from room temp to 99.5 will keep the PID from getting too crazy, and will ensure that you get smoothly from point A to point B

[Brett]

in reply to: Setting Integral value of >100 #4032

the quickest work-around I can think of would be to set the value from the front-end, but I notice that you also say, in a different thread, that you seem to be having issues there as well.

[Author]

Posts