Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: plcnut on December 17, 2012, 03:19:52 PM
-
I don't know how much trouble it would be, but I could sure use another layer of indirect addressing in the result field for the MATH instruction. For now I am using a MOVE instruction before the MATH instruction. It is part of a FIFO.
-
Please provide example. Do you mean
R[N[V10]]
or do you want to index the various tables indirectly, and the index (see REFWRITE for this capability)
-
My guess is he wants the first thing. I know in the Control Logix for example you can't do ThisArray[ThatArray[5]], so you have to do it in two steps and preload a scratch variable and it's an ugly kludge and it's very annoying.
-
I was looking for: MATH Result ArrayOne[MyIndex[V1]]
Right now I had to: MOVE from MyIndex[V1] to V2
Then I could do: MATH result ArrayOne[V2]
It is a little clunky but it works.
-
Don't know if it is helpful or relevant, but remember that we can do displaced references: array[index + displacement] where displacement can be 1 to 31.
-
Don't know if it is helpful or relevant, but remember that we can do displaced references: array[index + displacement] where displacement can be 1 to 31.
1..63, e.g. R[V10 + 63] as ANY input or output parameter whenever it takes an element reference, e.g. contact, coil, TMR preset, etc., not just inside MATH.
-
On a similar note, will you be able use arrays for user defined Data types? If so can you have Arrays defined in the data type?
-
Don't know if it is helpful or relevant, but remember that we can do displaced references: array[index + displacement] where displacement can be 1 to 31.
Can the "displacement" be a variable?
(I'm not where I can try it in the software right now)
-
On a similar note, will you be able use arrays for user defined Data types? If so can you have Arrays defined in the data type?
ALL data-blocks are available to be arrays. This includes user defined data-blocks.
So basically, if there is a number suffix as the ID, you can replace the ID with [Vnnnn] Vnnn register is the array index.
X[V11] // if V11 equals 32, then this would reference X32
R[V22+17] // if V22 is 3, then this would reference R20 (3 + 17)
T[V10].Acc // yes, structure field reference (e.g. V10 is 99, this would reference T99.Acc)
D[V8+4]:0 // even casts (e.g. V8 is 42, this would reference the LSBit of D46 (42+4)
The one limitation on the array index is that it MUST be a V data type, which is an UNSIGNED INT with a range of 0..65535. You cannot declare something else to be an array index EXCEPT in a MATH expression, which allows for ANY mathematical expression to be an array index (e.g. Y[SQRT(R2)], so when R2 is 81, this would reference Y9).
-
Can the "displacement" be a variable?
Only inside a MATH expression, where it can be ANY math expression like R[CT6.Acc + WX[CT[V22+5].Acc]]
-
Don't know if it is helpful or relevant, but remember that we can do displaced references: array[index + displacement] where displacement can be 1 to 31.
1..63, e.g. R[V10 + 63] as ANY input or output parameter whenever it takes an element reference, e.g. contact, coil, TMR preset, etc., not just inside MATH.
I have 5 bits stuck in the brain...this is probably the 3rd time I've done this...:sigh: Yes, 1 to 63.
-
Can the "displacement" be a variable?
Only inside a MATH expression, where it can be ANY math expression like R[CT6.Acc + WX[CT[V22+5].Acc]]
I don't think that will help me then. But I will look things over again this afternoon.
-
Sorry, I didn't ask the right question.
When you have the capability to add user defined structures, will you have the ability to have arrays in the structures and make arrays of the structures and be able to specify variables for both the indices of the main array and the elements in the arrays located in structure?
For instance. A user defined data structure called PN consisting of:
strName string
bSwitchData[128] Boolean
intRecipe[100] integer
so create an array of type PN called PartNumber[1000]
Would you be able to access the element in this way: PartNumber[V200].intRecipe[V35]
-
No. Our data structures will just allow simple data types (e.g. BIT, UNSIGNED BYTE, REAL, etc.)
-
No. Our data structures will just allow simple data types (e.g. BIT, UNSIGNED BYTE, REAL, etc.)
In that case let me put in a strong request for that capability in some future revision. I definitely use arrays inside user defined types.
I also frequently create fundamental low level UDT's and nest them inside higher level ones, sometimes up to three levels deep, which sounds like it's out of bounds for the current concept as well. It's a very useful ability to have, if you guys would be willing to do it.
-
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...
-
No. Our data structures will just allow simple data types (e.g. BIT, UNSIGNED BYTE, REAL, etc.)
In that case let me put in a strong request for that capability in some future revision. I definitely use arrays inside user defined types.
I also frequently create fundamental low level UDT's and nest them inside higher level ones, sometimes up to three levels deep, which sounds like it's out of bounds for the current concept as well. It's a very useful ability to have, if you guys would be willing to do it.
We well understand the power and value of complex data types...a product like Do-more could never be created without them. So our reluctance to attack it is not a lack of willingness or understanding, it is the bounds of the design. Do-more is a conventional PLC borne of a conventional 'Type:ID' view of memory. To extend memory types beyond what we currently have would require a significant re-architecting of memory addressing...something that is not likely for the immediate future. We are intimately aware of the current limitations, and it is something that we will eventually be forced to address...but...right now we are working on features that will be far more significant than this to our current customer base. As rudimentary as our current data types are, they are still well ahead of where the bulk of ADC's customer base is right now.
-
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.
-
We well understand the power and value of complex data types...a product like Do-more could never be created without them. So our reluctance to attack it is not a lack of willingness or understanding, it is the bounds of the design. Do-more is a conventional PLC borne of a conventional 'Type:ID' view of memory. To extend memory types beyond what we currently have would require a significant re-architecting of memory addressing...something that is not likely for the immediate future. We are intimately aware of the current limitations, and it is something that we will eventually be forced to address...but...right now we are working on features that will be far more significant than this to our current customer base. As rudimentary as our current data types are, they are still well ahead of where the bulk of ADC's customer base is right now.
Understood -- you guys are doing a great job despite having a lot on your plate. That's why I assumed this would have to be an addition to some possibly distant future release. Just wanted to put in a word so that when the manpower IS available you might consider doing it.