ps.: I have still the question about the PID Autotune (Temperature) VI, why it sets the output value to be equal to the step amplitude, since the step amplitude (+-) should be added to the setpoint during the auto tuning?
And the D term is always zero...
Can't help with this, sorry - I've never used the Autotuning feature. I've always done the tuning calculations myself. I'm usually tuning either very slow systems using a Cohen-Coon (or Ziegler-Nichols) open-loop approach, in which case I make sure it's safe to set up and walk away for a few hours while it collects data, or fast systems in which I can do the Z-N closed-loop approach quickly. In either case it's not much of my time to calculate good initial gains.
The update rate is 1Hz always. This oscillation is stable, and always there, with constant amplitude and period time.
Right now, I am not sure how I could check the REAL output of the Keithley, I mean, I can read it from the screen of the device, but I do not know, how I could record it via GPIB without disturbing the 1Hz output update... (NI Vision + webcam could maybe do the trick 😄 , sorry this was the joke part 🙂 )
Beside, just a note: about 2 years ago, I have run into a funny error: I just used the "official" Keithley 2400 NI labview driver, and I needed to use the Keithley current source in the +- 1 mAmpere range. After several days, I have realized, the screen shows a really bad resolution, not what my PID wants to send out! I just looked into the official LabView driver, and I just started to laugh:
the programmer used float instead of double!!! 😄 Of course, in this small range, this caused trouble.
Anyway, since then I use my own modifed LabView drivers (with double values inside) for the Keithley 2400...
if I remember well, there is a kind of rule-of-thumb to set the rate of the PID control: the rate should be 4 times faster compared to the dead-time. The dead time here I think is when we use open-loop tuning approach, and this is the time when the system reacts to a step change in the manual output value what drives the heat pump. In my case this water loop is fast: I guess the dead time is around 0.5 -1 second. So the optimal rate should be like 4 Hz? For certain reasons, my labview project was easier to make with an overall 1Hz update rate in the controls.
Maybe I should speed it up?
I do not think that changing the update rate from 1hz to 4hz will have any effect on an oscillation that's 30-40 minutes long.
Right now, I am not sure how I could check the REAL output of the Keithley, I mean, I can read it from the screen of the device, but I do not know, how I could record it via GPIB without disturbing the 1Hz output update...
I'm not too familiar with the Keithley command set, but is there a command that lets you query the current setpoint? If there is, that would do it, and I can't see why it would disturb the 1hz update rate - you could just read back the setpoint immediately after you set it.
just for the reference, we are going to try the following to get a more precise water temp. control system:
Due to the heat load, the usual current requirement of the Peltier heat exchanger is between 0.13 - 0.2 Ampere.
The PID control loop cannot perform its best since the Keithley 2400 sourcemeter is used in the highest, +-1 Ampere range.
We will connect the outputs of two Keithley 2400 sourcemeters in series, the LabView program will calculate the required current, and set one Keithley to that value. The second Keithley will be used in the finest, +- 1 mA range, and this will be driven by the PID output. (the system is quite static: after equilibrium is reached, the heat load does not vary too much in time, so the +-1 mA range should be sufficient)
I will report on the results later.
I'm not an electrical engineer so I may be completely wrong, but... are you sure this will work? It would be fine if you were dealing with voltage, but current stays the same all the way around the loop - you can't add to it. I think the Keithley that you're using for fine control will do nothing, because the current will already be more than what is requested.
After a bit more research... current sources in series are definitely a bad idea; putting the current sources in parallel might work.