In the UDT, the data type wasn't linked to anything such as a physical input. For example, you created a start button that was BOOL but it wasn't linked to a local or memory bit so if you use it in a program, it won't do anything as far as I can tell. Maybe I am missing something. Is there another step to the process?
I have question for you. In the example you used instruction are motor1.start,motor 1.stop. I understood that for start and stop you made a udt but from where did you take that motor1 tag?
He created it @6:30 when he right clicked the and chose New "motor". Because he chose the Data Type: UDT_ExamplePLCClass This class has subtypes (.STart, .Stop, .Running, .Speed_RPM) So now Motor1 also has these subtypes. the same way that "Timer1" has subtypes .DN or .EN
I have a question. I have been working on a project. We are using analog lasers to measure a surface as a periodic task. We look at an analog input, scale the input, fill an array using a FFU,FFL, average the array, then push to a parameter. Currently we were using one but now we are looking at multiple on one machine. Should I create a UDT, or an AOI?I was thinking then when we have a piece of equipment that needs, say 2 lasers we import package, enable those input/outputs. But if another machine has 1 or N lasers, we could easily implement. The laser logic periodic task is 10 lines of ladder for one laser. The logic is the same for the others but would fill a different part of the array elements. Any suggestions is helpful. Thanks
That's a great question. The way to think about UDTs and AOIs is that their purpose is completely separate. Some applications require neither, one, the other or both. The UDT is used to contain data. If you have multiple machines of the same type, I would definitely create a UDT that would contain each element of that machine. For example, you could have measurement1, measurement2, the array into which you use the FFU and FFL as well as other parameters of that machine. The AOI on the other hand is used to encapsulate logic. In other words, if you need to create 10 rungs of logic that will do the calculations of your averages, arrays, etc, AND will use them multiple times (for each machine), it's a good idea to create an AOI. The advantage of that is that you can easily copy/paste this logic and only change the call on the AOI. The drawback is that you need to download to the PLC if you want to make changes as well as most technicians and mechanics not wanting to troubleshoot AOIs. In conclusion, I would say to keep things simple, but do experiment with an AOI when you commission the units and see how it goes. On the same note, if there's an opportunity to help you with this install or the PLC code, reach out to me directly @ v.romanov@solisplc.com
Definitely. I've worked on multiple recipe handling systems and in every case, the recipe was a UDT that would contain ingredients, parameters settings for instrumentation, tank levels, temperatures, etc. It's a great way to combine all the tags into a single structure and make the code much more streamlined.
oh man I literally watched all the videos on UA-cam. I still have no clue how to port my function blocks from Tia Portal and Codesys. Inputs, Outputs, Statics, Routines.. addressing way different. I had a colleauge moving back from USA, he said RSlogix was way different than European counterparts. Back then I called him bs sob...Now I see what he really meant..
Thank you for the great content!
Glad you enjoy it!
Motor1.Running laching on rung zero should be XIC. I love watching your videos I would have more contact with you sir.
In the UDT, the data type wasn't linked to anything such as a physical input. For example, you created a start button that was BOOL but it wasn't linked to a local or memory bit so if you use it in a program, it won't do anything as far as I can tell. Maybe I am missing something. Is there another step to the process?
I am very thankful to you..
rockwell structured text error in String UDT is invalid data type: argument must match parameter
I have question for you. In the example you used instruction are motor1.start,motor 1.stop. I understood that for start and stop you made a udt but from where did you take that motor1 tag?
He created it @6:30 when he right clicked the and chose New "motor".
Because he chose the Data Type: UDT_ExamplePLCClass
This class has subtypes (.STart, .Stop, .Running, .Speed_RPM) So now Motor1 also has these subtypes. the same way that "Timer1" has subtypes .DN or .EN
I have a question. I have been working on a project. We are using analog lasers to measure a surface as a periodic task. We look at an analog input, scale the input, fill an array using a FFU,FFL, average the array, then push to a parameter. Currently we were using one but now we are looking at multiple on one machine. Should I create a UDT, or an AOI?I was thinking then when we have a piece of equipment that needs, say 2 lasers we import package, enable those input/outputs. But if another machine has 1 or N lasers, we could easily implement. The laser logic periodic task is 10 lines of ladder for one laser. The logic is the same for the others but would fill a different part of the array elements. Any suggestions is helpful. Thanks
That's a great question. The way to think about UDTs and AOIs is that their purpose is completely separate. Some applications require neither, one, the other or both. The UDT is used to contain data. If you have multiple machines of the same type, I would definitely create a UDT that would contain each element of that machine. For example, you could have measurement1, measurement2, the array into which you use the FFU and FFL as well as other parameters of that machine. The AOI on the other hand is used to encapsulate logic. In other words, if you need to create 10 rungs of logic that will do the calculations of your averages, arrays, etc, AND will use them multiple times (for each machine), it's a good idea to create an AOI. The advantage of that is that you can easily copy/paste this logic and only change the call on the AOI. The drawback is that you need to download to the PLC if you want to make changes as well as most technicians and mechanics not wanting to troubleshoot AOIs. In conclusion, I would say to keep things simple, but do experiment with an AOI when you commission the units and see how it goes.
On the same note, if there's an opportunity to help you with this install or the PLC code, reach out to me directly @ v.romanov@solisplc.com
@@SolisPLC I sent you an email, hope you have some time to look over it.
Is a UDT a good way to go for recipe/variety setup.
Definitely. I've worked on multiple recipe handling systems and in every case, the recipe was a UDT that would contain ingredients, parameters settings for instrumentation, tank levels, temperatures, etc. It's a great way to combine all the tags into a single structure and make the code much more streamlined.
Thank you!
THANK YOU!!!!!!
Did i miss the part where the UDT is tied to a real world IO?
In this example, when Motor1.Timer[0].DN bit is energized, it can be used to control a coil that is tied to an output.
What is the difference between the following:
DDT - Derived Data Type
DFB - Derived Function Block
UDT - User-defined Type
oh man I literally watched all the videos on UA-cam. I still have no clue how to port my function blocks from Tia Portal and Codesys. Inputs, Outputs, Statics, Routines.. addressing way different. I had a colleauge moving back from USA, he said RSlogix was way different than European counterparts. Back then I called him bs sob...Now I see what he really meant..