PID Wholesale Parameter Copying

[Controls Guy]

Yeah, but what I was talking about was a way of doing it that doesn't require a check every scan.  More interrupt-ish.  Wall clock based, for example.  (Although, I wasn't aware that you do allow the sample time to be set)

So, doing it the way it is now, if you set SampleTime to 1 second or whatever, then you do the PID calcs at that frequency, and there is no or minimal impact on scan time?  If so, then we're 99% on the same page.

[BobO]

Time has to be evaluated somehow. Either it is hardware via interrupt, or software via comparison to a preset. In a PLC, at least every one I've been involved with, they are the software variety. BRX also has a few hardware timers, but that isn't super common in PLCs.

And yes, the heavy lifting is only done at the SampleTime interval. The time base is actually significant and is one of the parameters produced by the auto-tune equations. If you are doing your own tuning, you can set the sample time to whatever you like.

[Mike Nash]

Turns out that 7mS scan time has a huge impact on MRX, MWX and EIPMSG usage. Using either ModbusTCP or EIP, I was getting only 15 read/write pairs per second with a 7mS scan time. When I suspended the 40 PID program, dropping the scan time to 1.7-1.8mS, these jumped to 45-48 R/W pairs per second. This was to a single device. I don't have all the devices to test with. Note, I was NOT using both protocols simultaneously. I will also create Modbus TCP Client devices for each physical device.

Just FYI. I did try yielding, continuous on non-zero interval and a few other things that improved the scan time and comms rate, but wasn't sure how badly that was going to affect the PIDs (played with sampletime vs interval for each PID also). These are not fast PIDs.

Splitting the PIDs to another Do-more is a win-win for multiple reasons, so it's not going to be an issue.

BTW, I would really like to see the counters in the EIPMSG instruction available in the MWX and MRX. That is informative, handy, and clean.

[BobO]

How many devices are you talking to? If more than one, are you using a client per connection?

How fast is your process?

[Mike Nash]

How many devices are you talking to? If more than one, are you using a client per connection?

How fast is your process?

I don't have the total count on devices yet. Let's say 10 or less. Yes, a client per connection though the numbers mentioned previously are for a single connection/client desk test (only one device).

Let's say 250 FPM. I'm not too concerned on this job that speed is critical, but I want to take every opportunity to optimize so I will know where the fine line might be on a faster process.

This is about to go on the back burner for a couple weeks at least while I work on another project. I had a window of opportunity to do some testing with real devices ahead of time. I have access to real numbers, but the scope of the job just got bumped up some and I haven't seen them yet.

[BobO]

Scan time makes a huge difference in comm throughput, just wanted to make sure there weren't other issues.

If your process isn't fast, PID definitely can have a long-ish sample time. The auto-tune algorithm spits out an optimal sample time, and it is generally longer than you would think. Make sure the sample times of the loops are different, or if they are the same, stagger the enables to spread them out over time. The key to maximizing comm is obviously to minimize scan time, but also to keep the scan as granular as possible. Solve the PID no more often than required by increasing sample time, and try to make the timers expire on different scans.

[Mike Nash]

I'll probably try that with the staggered sample times. Increasing them all (to the same value) even up to 250mS did not appear to have much effect on the scan time, but they were mostly all the same value.

Since I'll be offloading the PID and TIMEPROP to another Do-more it's not a show-stopper. Still, I don't have a feel for how much other logic I will be adding that may impact the scan time. It's the instructions that need to be updated every scan that put a kink in trying to alternate logic to lower the scan time.

All these interesting challenges. I've rolled my own PI-onlys a few times in DirectLogic because I needed to be able to tweak them on the fly. I wasn't confident in the built-in, mostly because of the way it had to be handled (they are easy to lose if you do the wrong thing.) But I really don't want to do that again.

But, it would be nice if the PIDs could be put in periodic tasks or programs when the update rate doesn't need to be fast.

[BobO]

Are you using the PID instruction's internal scaling?

[Mike Nash]

Are you using the PID instruction's internal scaling?

Yes. Is that better or worse? I could easily enough skip that.

[BobO]

We treat the scales like I/O and do the math every scan when enabled, regardless of the PID calc. If you do the scaling externally at an interval equal to the sample time, that will greatly reduce what the PID instruction is doing between calcs.

[Mike Nash]

Now that is interesting information. I may have to do it on the weekend, but I definitely want to play with that. Thank you.

[Mike Nash]

Still toying around with PID handling. I have only tried this in DmSIM so far, so I have no idea how it would do in the real world. My gut feel is that it can't fly because it isn't intended to be used this way. Unfortunately, it does appear to function, therefor I have climbed on in...

The premise is 30 PID loops simply because we are zero based, but I am just trying 29 here. No For-Next so no warnings presented. I am just incrementing each scan and running each PID one scan of 29. Note I have done a very crude thermal mass delay using an Integrator. Interestingly, it also seems OK with incrementing the index every scan. I don't know how all this affects the values for gain, reset, rate and sample time.

My question is, where is the pitfall? I have a slow process with lots of lag. Autotune with PID View can't happen because it says there are no PID loops active at this time.

[franji1]

Because PID uses TIME, you DO need to utilize a FOR/NEXT loop to let EVERY PID instruction's PID structure run EVERY scan.

We did 1000 PID loops using a FOR/NEXT loop.  It runs fine.  Since your process is slow, the bump in scan time by a few milliseconds should not cause any issues.

Note that the bump in actual PLC CPU hardware will be greater than the simulator running on a multi-gigahertz class processor on your PC.  30 PID Loops in actual hardware may bump it a few milliseconds on your PLC hardware, which is minimal for most applications (but BRX PLC's high speed I/O can get around this scan time issue).

[Mike Nash]

Thank you franji1.

I was merely looking into options. The FOR-NEXT does give a warning, which is OK, but it also does not provide for the PID View to work. I don't see that it would gain much advantage speed-wise over individual PID instructions. The one PID per scan kludge is a bit quicker at about 0.3mS versus 3.0mS for the FOR-NEXT. This is testing on a real H2-DM1E. The MATH and INTEGRAT to emulate the PV is part of those scan times. Individual PIDs are about the same scan time as the FOR-NEXT from what I can tell. Since I need to have TIMEPROP for all of these outputs, I think the effort has just been a way to pass the time. 

It is a lot more clutter to have individual instructions, but easier to troubleshoot later. My reason for looking at minimizing the scan has been mentioned before, Ethernet comms suffer a large hit with scan time jumping even 3mS. It's not an issue now since we will have 2 processors.

I do like the arrays for the PID along with nicknames. It's way more easy to do the mass changes with the arrays. Data Views are way more powerful/friendly with the array also.

BTW, I was able to get the kludge I posted earlier to work more cleanly by using the PIDs' RanThisScan bit (indexed) to increment the index. It increments more slowly, but more stably. It does want the SampleTime to be the same in all PIDs. Not really ideal perhaps if all the zones are not identical.

[Controls Guy]

What I've done for visualizing multiplexed code is have a second code block, in your case a second PID, and the one you want to troubleshoot designate to run in that block.   Then, of course, remember to omit running that loop on the normal PID.