Here is what I’ve done to use the output or “result” of a PID loop to control a digital output on any standard digital output module:
When you define the I/O point in the output module that you’re going to use, in the “Features” dialog box, select TPO. The brain on the rack for this output module must be a type that supports TPO, but I’m guessing that you’re going to have this module mounted to the same rack as your R1, and R1s support TPO, so you should be good to go there.
Now, you need to set up the time period for this TPO to use. What this means is the total time for each “cycle” of this output. I often do this in an action block at the very start of the strategy, and usually just hard-code it in since I won’t likely be needing to adjust this value programmatically, or as a user selection later. But you could set up a variable for this and allow the program or user to adjust it if you need to do so.
This is done with the “Set TPO Period” command. I just use a “Float Literal” for this value and choose how many seconds I want for the cycle time.
When selecting the time period, consider some things:
A shorter cycle time will potentially produce less up and down cycling of the temperature being controlled. But if the mass being heated is high, that might not be much of a problem anyhow. And a fast cycle time means more on-off switching in your output module.
As Philip pointed out, a mechanical relay module is not what I’d choose to drive a solid state relay in a TPO situation. I’d use a solid state output module so I wouldn’t need to worry about wearing out a relay. Mechanical relays often have an operational lifetime of around 10 million cycles. That sounds like a lot until you do the math on a TPO running 24/7 with a cycle time of, say, 1 second.
But if you DO end up using a mechanical relay output module to drive your SSR, you may want to consider using a rather long cycle time to reduce the wear on the mechanical relay and get a longer life out of it. That assumes that your heat load is large, and you can put up with more cycling of the temperature up and down.
Now, in the PID loop setup, choose “Host” as the PID loop’s output. That sets the stage for how you’ll transfer the PID loop’s output to your TPO-enabled output point. I set the Lower Clamp to 0, and the Upper Clamp to 100.
Next, define a floating point numeric variable to use to transfer the PID loop’s output to the TPO output’s Duty Cycle setting.
What I then do in the chart, in an action block, is use the “Get PID Output” command to read the PID’s output into that “transfer variable” that I set up. Choose the PID loop you want, and then for “Output”, choose “Float Variable” as the type, and choose your “transfer variable” as the name.
When that command executes, it reads the PID’s output value into that variable. And this is a value between 0 and 100 (percent).
The next thing I do in that same action block is to use the “Set TPO Percent” command. In the “To (Percent)”, I set the Type to “Float Variable”, and the Name to the name of that transfer variable that just had its value loaded with the PID Loop’s output value a moment ago. In the “On Point” Type, I select TPO, and for the Name, I use the name of the output point in the module we set up earlier to be the TPO output.
The fact that in a PID loop, you can’t directly select an output point that has been set up as a TPO doesn’t stop you from doing what you want. You just have to use a couple of extra steps, but it works like a charm.
Realize that I have these operations running in charts that run continuously in a loop. So the new PID output value is being transferred to the digital output point over and over. This means that these PID loops, running on an I/O brain, CANNOT operate independently from the controller or its strategy. The whole thing depends on the controller’s strategy reading the PID loop’s output and transferring it to the digital output constantly. I always have a delay command in these looping charts to slow them down somewhat so they don’t hammer the communications too badly and so they’ll give up time slices to other charts in the same strategy. But most things just don’t need to happen all that fast when it comes to heating, etc.
I often use a 500 millisecond delay in a looping chart. For most of what I’m doing, a half second delay in the response is insignificant, but of course, you need to make those decisions on a case-by-case basis.
You can also do some math, and only send a new duty-cycle percentage to a TPO output point when the PID’s output changes by an amount you consider to be significant.
Edit to add:
Another fine point to consider is that the TPOs are being executed on the Brain for the rack containing the output module in question. And the TPOs seem, in my experience to work this way:
The TPO uses the percentage that it last received prior to the start of each cycle, and does not change percentage during the cycle. In other words, it peeks at what it has for a percentage at the beginning of each cycle, and uses the appropriate “on-time” for that complete cycle. Then it peeks at the percentage it most recently received and uses that time for the next cycle, usv.
So when you’ve got a cycle time set up for, as an example, 10 seconds, the fastest that your output can update will be 10 seconds anyhow. So hammering that TPO’s percent value faster than that will not speed up response anyhow.
So when tuning PIDs that use TPOs, you must take into account the delay introduced by the TPO’s period when guessing (err… calculating ) your PID parameters.