Controls Guy, Are you speaking of a Multidimensional Array? I have been told that what I am currently working on would be much simpler if the software supported multidimensional arrays, but, the whole concept is pushing the edge of my understanding...
You could liken a multidimensional array to a spreadsheet, in that it takes more than one index to specify the location of a given piece of data in the array, like cell B9 say in a spreadsheet that has only one page. A 3-dimensional array takes 3 indices to locate a point, like a spreadsheet with multiple pages, but arrays can have more than three dimensions, it's just hard to come up with an analogy.
What the last few posts have been about are user-defined data types (UDT's), which unlike arrays, aren't necessarily lists of data points of the same type, like 100 integers or 1200 floating points or whatever, although there's no reason they can't be. For instance, say you want to write a program to control an electric heater in a chemical bath. You might define a type modeled on the data needed to control that heater, such as current tank temperature, setpoint, which are floating point values, as well as safety thermostat boolean status, liquid level boolean status (also for safety), and heater boolean on/off status or output percent, whether the loop can also cool, etc.
Now when you program, all the data necessary for controlling that heater stays together in a compact bundle, and your ladder will reference it as Activator.CurrentTemp or Activator.Setpoint, etc., all of which makes for cleaner, more readable, more reusable programming, so this is helpful mostly if you have objects that occur more than once in your program, or if you expect them to recur in future programs, because you can typically cut and paste these type definitions from one program to another.
Now imagine that in addition to a heater, your tank has a pump. You could just add the pump variables to the heater type and change the name to something more generic like "Tank", but maybe all the tanks don't have pumps, or maybe some of them have two. So by making pumps and heaters separate types, you're more flexible; you can then easily assemble types to fit whatever situation you run into. That was where I was talking about nesting UDT's. You could create a type called "Tank" that includes as members one or an array of the Heater type, one or an array of the Pump type and so on.
Real life example: I needed to maintain a fault history database in the PLC, which would include the fault code, time stamps for the initial acquisition of the fault as well as the acknowledge time, and some other data. AND the time stamps had to be stored in a format different than the time format standard for that PLC. So I created a custom UDT for recording a time in the desired format, then defined a type that would hold an entire fault record, including two instances of that custom time UDT as well as the other stuff. Then I created an array (so this is a specific data block, not a type) named FaultLog, which was an array of 1000 elements of type FaultRecord.
Topic: Deeper nesting for indirect addressing (Read 47037 times)