Forum Replies Created
-
AuthorPosts
-
in reply to: Front end serial error #4030
interesting. this code here:
osPID v1.50 IID2 OID1
DASH 20.00 24.25 0.00 1 0
TUNE 46.00 0.00 0.00 1 0 10.00 1.00 10 0
IPT 0 0.00 1.00 293.15 0.00is the ID chunk that first comes back from the osPID when serial comm is opened. it is followed by the osPID runtime values.
one thing I would suggest, to narrow down the cause of the issue, is to try connecting to the osPID with the Ardunio IDE.
in reply to: Hardware schematics #4029Are they available somewhere?
of course! it’s the open source pid controller after all. everything can be found at github.com/ospid
if you’re starting the profile with the standard “step to a low temp->wait for it to get there before continuing” you should be fine. the output will get to about the same starting point every time. I really think the main issue on the OP is the non-linearity. in both cases (0% start and 100% start) the output is instantly at 100% after the setpoint change. while there is more heat in the system before the 100% start, this is a far bigger issue when you have a conservative controller (output starts at 0%, steps up to 0.1%, etc.)
it definitely matters, but it may not be the only thing going on. first the 0-100 thing. the pid output will start adjusting from whatever output value is in place before it turns on. if you start at 100% there’s a lot more heat going in to the system initially, and the pid will need to back off. if you start at 0%, there isn’t that initial heating and the rise is more gentle.
that being said, you aren’t necessarily comparing apples to apples in your graph. it’s likely that your system behaves differently at 40C vs 80C. since heat transfer is based on the difference in temp between your heater and the liquid, the same amount of juice at 40C will yield a larger temperature change. most processes are like this; behaving differently at different operating ranges. it’s important therefor to decide with region is most important to you, and get the tunings that work best there.
in reply to: Autotuning #3850@deejay. the last point on that blog post is probably the most important. autotune is about getting to a starting point. with the relay method specifically, you’re going to need to do some after-the-fact tweaking. there are better autotune methods, but none of them are perfect. as mentioned in other places, the reason this is the method that was used is because I was able to copy another open-source project. due to an agreement with my employer, I’m barred from writing any original pid tuning code.
so i just said that the desired performance that comes out of the relay method has some overshoot (10% overshoot, 25% decay ratio I believe,) but be forewarned! there are certain types of processes for which there will ALWAYS be overshoot. known as “Integrating” or “non self-regulating” processes, these can be maddening to tune if you aren’t aware of what’s happening. heating a tank of water may very well fall into this category. in this situation you may need a little more than just PID. perhaps using a setpoint profile. you could set the setpoint below the target value, and let the overshoot carry you to the correct value. then use a ramp or step to get the setpoint up to where you really want it. just a thought.
in reply to: SSR Behaviour #3991Have you confirmed that this isn’t part of the inherent physics of the system? I would suggest physically disconnecting the SSR from the osPID at the step down phase, leaving everything else intact. if the behavior is different than when the osPID is connected, then we’ve got some work to do. if it’s about the same, you may need to look into changing how your system is configured.
in reply to: Ramp Soak and stuff #3750Having the option to specify a ramp rate and a ramp duration (i.e. as distint from a setpoint temperature and ramp duration) would be a nice to have.
this is essentially how it’s done. you specify the target temperature and how long you want it to take to get there. that’s what gets stored on the unit. it then calculates at runtime what the setpoint should be. take a look at this thread. the values stored on the unit are the same as the values in the profile file.
in reply to: Autotuning #3849John I replied to your other thread. Basically, the osPID doesn’t currently support “split range control,” but it could. I’ve added an issue to the github. if there’s interest I’ll see what I can do about adding it. keep in mind that my time is a bit short lately.
in reply to: Panasonic IR Reflow Oven #3984God I love seeing graphs like this. thanks for posting!
in reply to: Mods to control a fan with the second relay? #3971John, what you’re referring to is known as “Split range control.” where there is a cooling output and a heating output. the 0-100% pid output is then split, with 0-50% becoming 100%-0% cooling, and 50-100% becoming 0-100% heating. the output card on the osPID does provision for 2 outputs, but currently the firmware doesn’t suppose split-range control. I’ve added an issue to the github. if there’s enough interest I’ll see what I can do about adding it.
in reply to: Ramp Soak and stuff #3748originally the plan was to allow multiple profiles on the unit, but we started running into ram issues (the profile info is all stored in arrays)
in reply to: Wierd Input error and hard to get no overshoot. #3954depending on the system, it may actually be impossible to completely eliminate overshoot. the thing that strikes me the most about your image however, is the “wall of red” the input value should be a fairly smooth line. what I’m seeing in your image makes me suspicous that you have a loose connection somewhere.
in reply to: Design of PID Controller for helicopter #3968try asking over at the diy-pid-control google group. this forum is more for osPID-specific questions.
in reply to: osPID -> AVR Studio #3982all of the osPID code was compiled in the arduino ide. the library files are in the c++ language, but it’s the arduino ide that does the compiling.
in reply to: Input signals #3929even using the PID library on the arduino may not be an option: http://brettbeauregard.com/blog/2011/04/how-fast-is-the-arduino-pid-library/
because it uses floating point math, it’s not terribly fast. if your program did NOTHING but pid (no analogRead, no analogWrite) the fastest you could get would be ~12kHz.
-
AuthorPosts
