cardosocea
Member
Couple of small benefits of both AOI's and UDT's
- An AOI is a way of creating reusable code. Imagine you have an AOI that controls and monitors a valve and you have 100 valves connected to your PLC. Before AOI's, this would either be done with pointer (which isn't great for monitoring or troubleshooting) or rungs upon rungs (or subroutines) of the same exact code and you'd have to modify it 100 times. With an AOI, you modify once. It's a huge time saver and it could be even better if they were editable online or possible to download just the AOI. Yes, there is a certain loss of flexibility doing it this way, but it can easily be overcome by configuration bits. If you want a taste of it, download the PlantPAX library to understand how Rockwell does this to overcome this "issue".
- UDTs group data together to be easier to find, and there's some benefits to them when programming. Imagine a UDT with 10 variables, if you used a subroutine with parameters to process the data in it, you'd have to link 10 parameters and there would be a possibility of placing them in the wrong order and giving you a headache trying to find the issue. If you group them into a UDT, you can pass that UDT as a single parameter into the sub routine. It's much simpler to do, faster and less error prone. This is a benefit with AOI's too... much less work.
Another "minor" benefit is when you program in FBD, those 10 variables would be 10 lines between blocks that would clog up the space. A UDT will be a single line, effectivily allowing you to represent a lot more logic in that space. The downside with UDTs is that for them to be the most effective, you have to think them through before implementing which isn't how a lot of programs are created. Although it's a short lived problem as most people have a library of code somewhere that gets refined as projects pass.
- An AOI is a way of creating reusable code. Imagine you have an AOI that controls and monitors a valve and you have 100 valves connected to your PLC. Before AOI's, this would either be done with pointer (which isn't great for monitoring or troubleshooting) or rungs upon rungs (or subroutines) of the same exact code and you'd have to modify it 100 times. With an AOI, you modify once. It's a huge time saver and it could be even better if they were editable online or possible to download just the AOI. Yes, there is a certain loss of flexibility doing it this way, but it can easily be overcome by configuration bits. If you want a taste of it, download the PlantPAX library to understand how Rockwell does this to overcome this "issue".
- UDTs group data together to be easier to find, and there's some benefits to them when programming. Imagine a UDT with 10 variables, if you used a subroutine with parameters to process the data in it, you'd have to link 10 parameters and there would be a possibility of placing them in the wrong order and giving you a headache trying to find the issue. If you group them into a UDT, you can pass that UDT as a single parameter into the sub routine. It's much simpler to do, faster and less error prone. This is a benefit with AOI's too... much less work.
Another "minor" benefit is when you program in FBD, those 10 variables would be 10 lines between blocks that would clog up the space. A UDT will be a single line, effectivily allowing you to represent a lot more logic in that space. The downside with UDTs is that for them to be the most effective, you have to think them through before implementing which isn't how a lot of programs are created. Although it's a short lived problem as most people have a library of code somewhere that gets refined as projects pass.
