Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Controls Guy on February 05, 2015, 12:42:48 PM
-
1) I assume MEMCLEAR/COPY is significantly more efficient than MOVE when applicable?
2) Is there a way to reorder user data blocks in the list if they'll be accessed with REFx functions?
-
1) I assume MEMCLEAR/COPY is significantly more efficient than MOVE when applicable?
Yes.
2) Is there a way to reorder user data blocks in the list if they'll be accessed with REFx functions?
No.
-
Need them 2D arrays then. Can't store the memory block numbers in an array and nest the array refs I don't think.
-
The array reference can be a full expression in MATH. Is that not enough?
-
Need them 2D arrays then. Can't store the memory block numbers in an array and nest the array refs I don't think.
Not really 2D arrays, you just need a slightly smarter calculation for the extra level of indirection utilized by your REF/REFWRITE instructions.
Say you were using D100 as your "Reference Type" value (aka Block #) in your REFWRITE/REF instructions.
You were probably doing something like a FOR loop for your D100 value, hoping you had a "contiguous" range of block #'s.
Say you had 5 blocks 40..44 nice and neat for your D100 values
FOR D100 40 to 44
// use D100 in REF/REFWRITE instructions
NEXT
But now you need 10 ADDITIONAL blocks, but those are now 50..59.
All you need to do now is store these block #'s in a range of V, or even better, a new block called MyRefType.
Define MyRefType to be 15 words long (for the 15 now non-contiguous block #'s 40..44, and 50..59).
Initialize that to
MyRefType0 = 40
MyRefType1 = 41
...
MyRefType4 = 44 // last of 1st contiguous block
MyRefType5 = 50 // first of next contiguous block
MyRefType6 = 51
...
MyRefType14 = 59
So each MyRefType ID now stores the unique block # value.
Now your FOR loop iterates through the simple 0..14 indexes of MyRefType:
FOR V0 0 TO 14
MOVE MyRefType[V0] D100 // D100 now contains the V0th block # in your "non-contiguous" set of blocks!
// use D100 just like you did before in your REFWRITE/REF instructions!
NEXT
Sure, it's a little extra overhead compared to what you were probably doing, but it's just as powerful!
-
I know -- I was just hoping to do MyBigArray[BlockList[V101]]
I'm lazy plus I like it clean. Whatever, it works.
-
I know -- I was just hoping to do MyBigArray[BlockList[V101]]
I'm lazy plus I like it clean. Whatever, it works.
I'm confused. That's legal.
-
I guess I should have tried it. I thought nesting array refs was taboo.
Part of the issue is that I haven't used REFx very much so I don't know when I'm pushing the envelope.
Now is that nomenclature valid for assignment as well as use in an expression? That would be part of the task.
-
Now is that nomenclature valid for assignment as well as use in an expression? That would be part of the task.
No, sorry. Only as part of the expression itself, so it would require a two-part computation.
-
I guess if you were really intent on reordering the user data blocks, and if you had a reasonable number, say 20 or so, you could start a new empty program, recreate all the blocks in the order you want them, then cut and paste the logic from the program with the blocks in the undesirable order into the new one. A lot of effort, but it's something you'd hardly ever do.
-
I really despise that extra MATH instruction to get the deeper nesting for indexes. I know we had an older thread about it in the past... What was the issue that makes the deeper nesting 'non-doable'?
I guess one thing I don't like about the extra step, is the readability/documentation. I have not figured out how to use meaningful names for the large number of indexes that I use in my programs using only 15 characters. Especially when many of my indexes require two v-mem's per index because of nesting. One thing that would help, is instruction level comments. Or maybe even a new instruction that would allow deeper nesting for inputs and outputs (a supercharged MATH box!).
What would the chances be of adding a new instruction that would allow expressions in the Destination field of 'MATHREF'?
-
I really despise that extra MATH instruction to get the deeper nesting for indexes. I know we had an older thread about it in the past... What was the issue that makes the deeper nesting 'non-doable'?
Everything is do-able, the question is ROI. I have spent a bit of time thinking about this though, and I know how to do it pretty easily in the PLC. Whether I can talk Franj into the the Designer side work remains to be seen.
I have not figured out how to use meaningful names for the large number of indexes that I use in my programs using only 15 characters.
An unfortunate decision on our part to stick with 16 character nicknames. That decision was made early in the development, when we thought it was going to be a quick-n-dirty effort. We are planning to increase that in a future rev, maybe 2.0.
Or maybe even a new instruction that would allow deeper nesting for inputs and outputs (a supercharged MATH box!). What would the chances be of adding a new instruction that would allow expressions in the Destination field of 'MATHREF'?
Right side of the equal should be effectively unlimited now, at least in MATH. I'm pretty sure we could do an expression in a simple output reference. Meaning "D[V0 + V1*10 + V2*100] = Expression" would be legal.
-
So would the enhanced ability on assignment include array references in the expressions? Even array-less expressions would be very powerful and address many of the cases.
-
Everything is do-able, the question is ROI. I have spent a bit of time thinking about this though, and I know how to do it pretty easily in the PLC. Whether I can talk Franj into the the Designer side work remains to be seen.
If you can, Do-More would be industry-leading in this respect. This (lack of nested array refs) has been a thorn in my side with Control Logix since the inception. Such a cool vision, and then they leave out critical parts.
-
So would the enhanced ability on assignment include array references in the expressions? Even array-less expressions would be very powerful and address many of the cases.
Like this: "D[D[V0] + D[V1]] = Expression"? Yes.
-
Like this: "D[D[V0] + D[V1]] = Expression"
This would be very cool. 8)
-
Like this: "D[D[V0] + D[V1]] = Expression"
This would be very cool. 8)
Even more rope!!! Yes? ;)
-
After some study, it will support this too: "Struct[Exp].Field = Exp", or "Block[Exp]:Cast = Exp".
The DmD side will take a bit of time...but once I figured out how to do it...the controller literally took *5 minutes*. :bows head in shame:
-
Everything is do-able, the question is ROI. I have spent a bit of time thinking about this though, and I know how to do it pretty easily in the PLC. Whether I can talk Franj into the the Designer side work remains to be seen.
Cool! Woo hoo! (If you can talk Franj into it, that is!) 8)
-
All of the pieces already exist, just have to assemble them. Franj is pretty reasonable in cases like that. ;)
-
Cool beans!
Sometimes the value/expression is the simple part; where to put it is the hard part. Once you get Franj on board, we'll be set ;D ...what does he really like?
-
I think the "hard" part is going to be changing the "Result" parameter from a simple element type to a "blob",
e.g. from an element like D42 to an ASCII expression "D[N5*10 + MAX(V3, 9) + 0x4)]:R",
and handling old projects that do NOT have the "blob" parameter. It's not hard, just gotta think it through.
It doesn't have to be backward compatible (i.e. Designer 1.0, 1.1, 1.2, and 1.3 cannot open 1.4 project files, but 1.4 must open 1.0, 1.1, 1.2, and 1.3 projects), so that's why it should not be that hard.
-
Even more rope!!! Yes? ;)
I'm planning on opening a rope emporium. I'll take all you got! :D
-
After some study, it will support this too: "Struct[Exp].Field = Exp", or "Block[Exp]:Cast = Exp".
The coolness is almost too much to bear! :)
The DmD side will take a bit of time...but once I figured out how to do it...the controller literally took *5 minutes*. :bows head in shame:
That's a sign of previous good design! I made a functionally fairly major improvement to a DM app the other day, and it took about an hour. The change was significant enough that the customer assumed it would take days if not a week or more.
-
I exported logic from two versions of a program to difference them with an external program. They're two forks of the same original program. I notice in one version only, extra NOPs after a program exit that don't show in the alternate version. On screen of course, there are nothing but NOPs after the EXIT. Why would one get exported in one program version but not the other? Puzzling.
-
We keep an extra NOP at the end of each code block as an insert point, or some such thing...I barely remember, and it turns out that the management of said NOP is not...um...optimally consistent. I think there might have been some effort to fix it a bunch of years ago, but it proved harder than one would expect, so we left it. It's mostly harmless... ::)
-
I exported logic from two versions of a program to difference them with an external program. They're two forks of the same original program. I notice in one version only, extra NOPs after a program exit that don't show in the alternate version. On screen of course, there are nothing but NOPs after the EXIT. Why would one get exported in one program version but not the other? Puzzling.
There is no extra NOP in the PLC's code-blocks, but there are in your project in Designer.
Also, if you ever cursor beyond the bottom of your program and begin editing, that will add another extra NOP. But all of this is at the Designer level. It's just "pad" to allow you to cursor beyond the last instruction in your program.
Adding new stuff beyond the end of existing logic needs to "just work", hence why the NOPs beyond the end "just show up". This is just on the Designer side. Trailing NOPs are never downloaded to the PLC. Although it appears as though every code-block is "filled with NOPs", that is just a façade to make it easy to add logic sequentially, which is how most logic is written.
-
That all makes sense, and it wouldn't even bother me if an extra NOP or two were downloaded to the PLC. My question was the inconsistency, as well as it creating apparent differences when comparing, making real differences hard to find in show-only-differences mode or when skipping difference to difference. Not a big deal unless it does that a lot, creating a lot of clutter.
IIRC, I believe I've seen similar behavior in the internal DMD compare (telling me there's a difference, but when I go look, I can't see any). Perhaps that stems from the same issue.
-
There is no extra NOP in the PLC's code-blocks, but there are in your project in Designer.
Does that imply that I can manually fix it (for easier compares) by deleting the rung where the extra, explicit NOP is? Won't make any difference on screen of course, but would that then synch the exported files?
-
I misunderstood. The issue is with Exported .TXT files? Those are not guaranteed to match the source project code exactly. In addition to the extra NOPs, there are hidden parameters called Edge Bits and Instruction IDs that will also be different.
Can you describe the situation(s) you are dealing with?
-
Like this: "D[D[V0] + D[V1]] = Expression"? Yes.
In a related/overlapping vein, would it be feasible to open up indices to other than V-Memory? The 0-65K UINT range of V's aligns nicely with max array sizes, but it would have been nice today to be able to do MyUserDB[MyNamedConstant]. Don't know how much grief that would cause y'all, or if it's even possible.
-
Well...if a named constant is jus a super simple expression, I would expect it to work as requested.
-
In a related/overlapping vein, would it be feasible to open up indices to other than V-Memory? The 0-65K UINT range of V's aligns nicely with max array sizes, but it would have been nice today to be able to do MyUserDB[MyNamedConstant]. Don't know how much grief that would cause y'all, or if it's even possible.
In MATH expressions, anything/everything should work. However, most other instructions require "simple" array accesses using V array index or V + offset array index (where offset is decimal range 1..63). This "limitation" (it's actually a powerful feature) also applies to Ladder Status, Data View status, and Trend View from within Designer (yes, Virginia, you can monitor R[V42+63] on your Trend View, and as V42 changes, your realtime plot of that array reference will work seamlessly ;D)
-
Well...if a named constant is jus a super simple expression, I would expect it to work as requested.
Right, I figured that it would in the context of that post, which was the destination field of MATH boxes. Why I said "overlapping" was my request was broader but less deep than that specific scenario: the feasibility of expanding indirect addressing throughout Do-More, though not to the complexity we've been discussing re: the MATH box arguments (unless you really wanna! :) )
-
In simple parameters, no. The encoding can't support it. We envision an expanded encoding in the future that might.
But we do eventually see the current expressions supported for most input parameters.
-
In simple parameters, no. The encoding can't support it. We envision an expanded encoding in the future that might.
But we do eventually see the current expressions supported for most input parameters.
Can you define for me "simple parameters" vs. "most input parameters". Sounds like category 2 gets enhanced parameters before category 1. Am I reading that correctly?