Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Mike Nash on October 20, 2017, 10:34:02 AM
-
Is there a simple, quick way to initially copy PID_01's element values to PID_02 thru PID-40?
MEMCOPY would require 39 instances which is not simple or quick.
COPY doesn't want to allow me to do just the elements I want 39 times.
Memory View doesn't allow the structures at all.
I realize this is not something I would want to do normally as the loops will most likely not tune the same. But initially, I thought it would be a reasonable starting point.
-
Rather than create the PIDs as heap-items, make a block of 40 PIDs (say MyPID).
Now you have MyPID0..MyPID39.
Then just do
FOR V0 1 to 40
MEMCOPY MyPID0 to MyPID[V0]
NEXT
-
And use Nicknames on your MyPID elements for good "tag" names ;)
Tie ChillerXYZ nickname to MyPID5, HeaterABC to MyPID39
then just use
ChillerXYZ.PV
HeaterABC.SP
in your instructions, data views, etc.
-
Or use the new COPY instruction, which could have 39 rows of heap-item copies.
-
Thanks!
I had convinced myself I couldn't do the PIDs as an array structure :-[ without actually checking.
I also don't know that I will want to keep the names as PID_01, etc., which is why I didn't look last night. And of course you answered this also as I was typing!
The problem for me with the COPY, was all that typing in could be done just as well in the PID elements themselves. I was just trying to stuff values initially to get a starting point.
At this stage, I was more wondering what the impact was going to be on scan time for so many loops. I am seeing about 5-6 mS adder for all 40. (This H2 already has code in it I have been playing with so the 40 add'l PIDs took the scan from 1.7 to 7 mS.
To be fair, I have been programming AB stuff the last couple weeks and the transition back and forth at times confuses me. (Like, what really happens in AB land when I keep hitting F8 to accept?)
-
At this stage, I was more wondering what the impact was going to be on scan time for so many loops. I am seeing about 5-6 mS adder for all 40. (This H2 already has code in it I have been playing with so the 40 add'l PIDs took the scan from 1.7 to 7 mS.
You realize with Do-more you have COMPLETE CONTROL of that if you stick the FOR/NEXT loop in a TASK and use the task's .TimeSlice field (MICROseconds) to adjust the "bump" per scan. Just use the task's .Done bit to know when it gets done (might take 2, 3, 4 scans).
-
No, I think he's talking about the scam tine impact of actually running 40 loops. Even so, if they're process loops, time slicing should still be fine (or even a 7ms scan time).
-
No, I think he's talking about the scam tine impact of actually running 40 loops. Even so, if they're process loops, time slicing should still be fine (or even a 7ms scan time).
Oops. My bad.
PID is a time-based instruction, so it needs to run every scan (so it can track time). Hence, trying to utilize yielding would NOT work as desired. :-\
-
On the yielding, yes I have used that feature previously.
Yes on the PID "loops" impact being reasonable. Hopefully I won't need 40, but over 30 for sure.
And I did stick a PID in a TASK just to see if it would work. It didn't mind (no warnings) as long as the ENTASK was continuous at 0 mS. I get warnings with the other choices. I'm going to just put them in a Program.
-
That whole timing by totalling scan times still seems weird to me.
-
That whole timing by totalling scan times still seems weird to me.
There's a reason it's called an "accumulator".
-
PID is a time-based instruction, so it needs to run every scan (so it can track time). Hence, trying to utilize yielding would NOT work as desired. :-\
I think the best way to write a PID, and what I do when I write one, is to have it be aware of its time base, whether as an input parameter, or by automagically checking the elapsed time since the previous execution. Proportional doesn't care anyway, but integral and derivative can then just use that time in their calcs. Then, if you have an application for which evaluating the PID every 30 seconds is often enough, knock yourself out. You're not required to scan it 100000 times more often than required by the process.
-
That's exactly how it runs internally. It needs to run every scan to check time, just like you are proposing.
-
That's not what I meant to suggest, but OK.
-
You said to evaluate the loop at an interval that fit the application. How are you planning to specify that internal and test whether it has passed? A timer and a comparison. That is exactly what the SampleTime parameter is and exactly what happens internally.
-
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.
-
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.
-
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.
-
How many devices are you talking to? If more than one, are you using a client per connection?
How fast is your process?
-
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.
-
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.
-
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.
-
Are you using the PID instruction's internal scaling?
-
Are you using the PID instruction's internal scaling?
Yes. Is that better or worse? I could easily enough skip that.
-
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.
-
Now that is interesting information. I may have to do it on the weekend, but I definitely want to play with that. Thank you.
-
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.
-
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).
-
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.
-
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.
-
Then, of course, remember
Remember... that word looks familiar. I wonder where I, I, what were we talking about?
Thanks. It actually crossed my mind something like that might work, especially at the HMI side. But I am really leaning towards discrete logic after all. Anything using real I/O has a tendency to need addresses swapped around at some point and doing that when I have a FOR-NEXT doing the scaling (never mind PID) suddenly becomes nightmarish.
-
Sounds like a case for MAPIO!