SoftwareJanitor
Member
OP
Wow! This AOI stuff is *great* ! Object-oriented design in a PLC ! Didn't think they had that capability! Yeah, I can see now how my 'enhancement' looked foolish to you guys.
This stuff reminds me of startup at a Pharma Plant years ago. Arrived from my conventional software development job (procedural structured text in real-time environment with multi CPUs and multi-threading) to work on a proprietary DCS which used wired Function Blocks running top to bottom in 1 of 3 scan windows. My group had never seen anything like it. Part way through development, noticed we were all coding similar logic across modules for things like Mode Decoding and Alarming. Making things worse, other common logic (Dosing, Networked Transfers) was simply imported in macro "trees". Combination of these two things caused many of these Controller apps to start getting very low on spare resources (equivalent of tags in PLCs). Realized we could drastically reduce signal usage with new Function Blocks for this common code. However, system didn't allow for making your own Function Blocks, so the owner had to do it and add them to the library for us. That was the first and last time they agreed to make changes to the library.
But with AOI's you can make changes anytime you want! Can't wait to make use of this!
==========
daba:
Thank you! Noticed you even have the "Cleaned" output turned green ! LOL! That's really cool - and pretty much what I'm going to implement now ... except I'll be clipping the values at the MIN and MAX of the engineering span and the 1% will be the amount *above* and *below* those limits which will indicate "Calibration Suggested". Already copied the existing alias tags to new alias tags (so the existing tag references throughout the code stayed the same ... those are the company-standard I/O tagnames).
So I'll still have the raw I/O value for display, the raw I/O value trimmed to the engineering range for the program, and the Calibration indicator for outside the 1% tolerance (which is the standard here).
Just have to reference these ranges from the I/O Card now, so that those configuration numbers are only entered in *one* place.
Thanks again! Really appreciate your 'extra credit' work !
==========
ASF:
Well-written micro tutorial you did there! I opened that document and couldn't believe the size of it (for just AOI's)! I got through about 30 pages this morning before I got out of bed (LOL!). Think I actually saw some "disadvantages" to AOI's listed in there somewhere, but can't remember them offhand. Need to read through it again. I don't think it was anything significant, though ...
This stuff reminds me of startup at a Pharma Plant years ago. Arrived from my conventional software development job (procedural structured text in real-time environment with multi CPUs and multi-threading) to work on a proprietary DCS which used wired Function Blocks running top to bottom in 1 of 3 scan windows. My group had never seen anything like it. Part way through development, noticed we were all coding similar logic across modules for things like Mode Decoding and Alarming. Making things worse, other common logic (Dosing, Networked Transfers) was simply imported in macro "trees". Combination of these two things caused many of these Controller apps to start getting very low on spare resources (equivalent of tags in PLCs). Realized we could drastically reduce signal usage with new Function Blocks for this common code. However, system didn't allow for making your own Function Blocks, so the owner had to do it and add them to the library for us. That was the first and last time they agreed to make changes to the library.
But with AOI's you can make changes anytime you want! Can't wait to make use of this!
==========
daba:
Thank you! Noticed you even have the "Cleaned" output turned green ! LOL! That's really cool - and pretty much what I'm going to implement now ... except I'll be clipping the values at the MIN and MAX of the engineering span and the 1% will be the amount *above* and *below* those limits which will indicate "Calibration Suggested". Already copied the existing alias tags to new alias tags (so the existing tag references throughout the code stayed the same ... those are the company-standard I/O tagnames).
So I'll still have the raw I/O value for display, the raw I/O value trimmed to the engineering range for the program, and the Calibration indicator for outside the 1% tolerance (which is the standard here).
Just have to reference these ranges from the I/O Card now, so that those configuration numbers are only entered in *one* place.
Thanks again! Really appreciate your 'extra credit' work !
==========
ASF:
Well-written micro tutorial you did there! I opened that document and couldn't believe the size of it (for just AOI's)! I got through about 30 pages this morning before I got out of bed (LOL!). Think I actually saw some "disadvantages" to AOI's listed in there somewhere, but can't remember them offhand. Need to read through it again. I don't think it was anything significant, though ...