• State Not Answered
  • Replies 1 reply
  • Subscribers 20 subscribers
  • Views 725 views
  • Users 0 members are here
Options
Related

What is the best practice to create an object that reflects an array of Rockwell UDT's

Andrew Drane

I have had multiple projects recently where I am tasked with creating system platform objects that reflect an array of UDT's in a Control Logix. Arrays are easy, UDT's are easy, but an array of UDT's is always the biggest pain. Hoping someone here has come up with a good solution. 

Example basic UDT for some recipe data:

IgredientData[50]

  • Ingredient Number:(Int)
  • Quantiy Required:(Real)
  • Quantity Actual:(Real)

Values are being pulled out of a client's custom database and being passed down to the PLC to be auto weighed and transferred.

Data is variable in length and occasionally up to 30 ingredients, PLC team has it in array of 50. There will be over a hundred instances of this for my current project, so creating Templates, with child object templates for so many items seems like a ridiculous and unorganized mess to me. This is like one line of code in C# so I feel like there has to be a better way to do this.

Any experiences appreciated, thanks!

  • 0

    I guess the question I'd have here is - what is the actual workflow here?  Are you selecting, then passing to the PLC, and "transferring" (would need definition here - is this transferring in the process, storing back to the DB, what) all in one step?  Do different ingredients in the array get transferred at different times? 

    There are different ways of handling this depending on how the actual process workflow works. 

    Things off the top of my head:

    1) Setting up scripting to cycle through the PLC array addressing indirectly (not thrilled about it and more of a next to worst case scenario)

    2) Reusing the IngredientData object for multiple PLC "instances" so that you don't need 100 of them.

    3) building that template.  Not thrilled about that option either but I've seen worse.

    Object Wizards may be the way to go because you could add/remove the extraneous attributes, but the concept of a max of 150 attributes in a single object, while I KNOW people have made way larger objects, is a little bigger than I typically aim at (I try to keep it under 80 IO attributes max if I can't make it modular) 

    (Sidebar -The main thing I've always gotten a little annoyed at is that while App Server handles it's own arrays well, tying arrays to IO arrays has always been a bit of a chore, as you can't just assign the array DIO.Topic.Array[] and be on your way. )

    I wouldn't necessarily say that it's unorganized, but having 5100 objects for a hundred of these ingredientdata arrays is certainly a lot.  

    Is RMP an option here? The custom database would say no, unless they're only using it for that specific purpose.