Forum Replies Created
-
AuthorPosts
-
in reply to: Setpoint Profiles (for Reflow et al) #3799
Is there a simple thermocouple test that I have missed?
can you confirm that you have set the osPID to read from the thermocouple input rather than the thermistor input? when connected, this setting will be visible on the front-end config tab
in reply to: Setpoint Profiles (for Reflow et al) #3794@dchris I’m glad you posted that first picture. it’s very revealing about the nature of your oven’s heating. similar to the cooling thing, I can see that the output is fixed at 100% during the entire heating portion. the heaters can’t give any more. so this is as fast as your oven can heat up. no PID in the world can make it go faster.
in reply to: Setpoint Profiles (for Reflow et al) #3792@dchris that second picture looks great! (the first one had been removed)
it looks like your temperature is tracking pretty well with the setpoint. I’m not sure how much you would gain by changing the tuning parameters. I know that the cool-down looks slow, but if you look at the output you can see that the PID (correctly) dropped the output to 0 early on. the slow rate of cooling is due to the nature of your system. no set of tuning parameters will make that cool-down happen more quickly.
you must MUST post pictures once you start reflowing!
also, just as a side note, if you could comment on the challenges you had getting to this point I think that would be really helpful. I’ve been doing this for a long time, and I do my best to make thing accessible to the beginner, but sometimes it’s hard to forget what I know. there’s no substitute for someone saying “yeah, I was really confused by ____. if you had said ___ it would have made things much easier.”
in reply to: Autotuning #3843@dchris01 wrote:
So is Autotuning better activated before any profiles are implied on the ospid
correct. if I did the internal logic correctly you shouldn’t even be able to run both at the same time.
what I would recommend is, separate from the profile, get your system to the most critical area. for a reflow oven, this would be up in the reflow region (~235 if I’m not mistaken.) if the existing tunings are somewhat good, you may be able to do this by just adjusting the pid setpoint and letting the pid get you there. if the existing tunings are god-awful, you can put the pid in manual mode and adjust the output directly.
once you’re in your target region, execute the autotuner. running the tuner in your critical region will ensure that the values you get are optimized for that section.
in reply to: Autotuning #3841@Petterson wrote:
Wondering if I set a temp of 100 for Autotuning how long does the Autotuning take to complete the process
there isn’t a set time. the autotuner will induce oscillations in the process. depending on the type of process you’re connected to this oscillations may be slow or fast. the autotuner will generate between 3 and 10 peaks. it’s “i’m done” criterion is if the last 3 peaks were within 5% of eachother. you can find more information on the autotune here.
in reply to: Setpoint Profiles (for Reflow et al) #3790if you would like those hard steps, then the profile file would contain the following:
[profile name, 7 chars max]
3, 100, 30 //step (3) setpoint to (100) and wait (30) seconds
3, 150, 30 //step (3) setpoint to (150) and wait (30) seconds
3, 170, 30 //step (3) setpoint to (170) and wait (30) seconds
3, 200, 30 //step (3) setpoint to (200) and wait (30) seconds
3, 217, 10 //step (3) setpoint to (217) and wait (10) seconds
3, 245, 20 //step (3) setpoint to (245) and wait (20) seconds
3, 255, 30 //step (3) setpoint to (255) and wait (30) seconds
3, 210, 20 //step (3) setpoint to (210) and wait (20) seconds
3, 75, 10 //step (3) setpoint to (75) and wait (10) secondsjust so we’re clear, this will adjust the setpoint of the oven (the green line on the front-end.) the actual oven temperature (the red line) will lag behind and will respond to these changes based on your specific oven, and your tuning parameter values (Kp, Ki, Kd). for a smoother profile, it might be more advantageous to use the available Ramp command instead of so many step commands:
[profile name, 7 chars max]
3, 100, 0 //step (3) setpoint to (100) and immediately go so the next step
2, 0, 0 //we have no idea where the oven temperature was at the start, so wait (2) until it crosses the setpoint from the previous command (100)
1, 217, 100 //ramp (1) the setpoint to 217 over the next 100 seconds
2,0,0 //because the oven temperature is likely lagging behind the setpoint ramp from the previous step, wait (2) until it actually GETS to 217 before proceeding the next step
1, 245, 20 //ramp (1) the setpoint to 245 over the next 20 seconds
3, 255, 30 //step (3) setpoint to 255 and wait 30 seconds
1, 210, 20 //ramp (1) the setpoint to 210 over the next 20 seconds
3, 75, 30 //step (3) setpoint to 75 and immediately go so the next step
2, 5, 3 //wait (2) for input to be within (5) degrees of the of the last setpoint (75) for (3) seconds before proceeding to the next step (END)
Again, this is specifying the REQUESTED temperature (the PID Setpoint,) not the actual temperature. how well the actual temperature tracks with these request will be based on the oven & tuning parameters.
hope this helps
(updated: when I first wrote this, I accidentally got the red/green designation backwards. whoops)
in reply to: Wiring help #3840but with the SSR on either the live or neutral wires.
it’s safer to put the SSR on the live wire. this way the flow of electricity is interrupted BEFORE it goes out into the hot plate. if you have it on the neutral wire, the hot plate has the ability to shock/short-circuit even when the SSR is off.
in reply to: updating firmware #3774Hi guys, I believe I have fixed this issue. from the commit note:
the problem:
– github adds a hash to the end of the download zip (e.g. “-da74de9”)
– when unzipped this hash is now part of the folder name, so it doesn’t match the .ino name
– a new folder is created without the hash, and for some reason the analogbutton files are not copied
– the newly moved .ino throws an error.the solution:
– I created a osPID_firmware sub-folder and moved the program there. this way, when un-zipped the hash will be added to the outer folder, not the actual program folderin reply to: Double PID for Temp Control #3781Hi John, using 2 pid loops would ensure that you were getting the most precise control possible, as the best tuning parameters for heating may be different than the best tuning parameters for cooling. that being said, having 2 separate pid controllers makes it likely that they will fight eachother.
the common industrial solution is to use what is known as a “split range controller.” in this scenario, one pid controller is used, but if the output is <50%, the signal is sent to the cooling system, and if it's above 50% it's sent to the heating system. most split-range controllers also provision for a different set of tuning parameters for heating vs cooling.
this isn’t currently supported by the osPID, but all the pieces are there for a nice hack.
in reply to: Proportional control calculation #3784Hi Ian, when the pid is turned on (Manual -> Automatic) the current value of the Output is remembered as the baseline value. moving forward all output corrections are based off this value. so in your trend, you started pid with an output of 50. when the input crosses setpoint the proportional term is indeed 0, as you expected, it’s just being added to this starting value.
this is standard pid behavior, and it exists to allow for a “bumpless transfer” from manual to automatic.
in reply to: Ramp Soak and stuff #3742I’m also eagerly awaiting this update
the wait is over! new firmware went up today.
http://www.ospid.com/blog/the-long-awaited-firmware-update/in reply to: I lighted a bulb! (want to cook some meat next…) #3787That was easy!
AWESOME! great to see the video as well. keep ’em coming!
in reply to: Ramp Soak and stuff #3740did you find it harder to tune with profiling?
operating at different temperatures does make it more difficult to tune. often you’re left with a situation where you there simply isn’t a perfect set of tuning parameters, just based on the nature of the system. everyone’s mileage will certainly vary, depending on the equipment they use.
in reply to: Ramp Soak and stuff #3736The firmware is coming along nicely. I’d say profile functionality should be available within a week. Here’s a little teaser: https://twitter.com/#!/rocketscream/status/188990752435617792/photo/1
in reply to: Serial connection cuts out randomly #3779I’d put my money on it being a RAM issue. the new firmware (currently in progress) is far better in that area. hopefully that will take care of it.
-
AuthorPosts
