Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: ATU on April 04, 2018, 12:40:46 PM
-
For some reason, I keep wanting to right click to get a menu to insert a line. Probably decades of Excel use. Could that be something easily added? Have Insert, Delete on a right click menu? If its a lot of trouble, I would not mess with it.
-
Definitely. We have a whole bunch of right click (context) menus many other places.
I can add a context menu the top level UDT dialog to Add/Edit/Delete UDTs (or View built-in structs), and also a context menu at the Edit UDT Definition dialog to AddToEnd/Insert/Duplicate/Delete/Edit fields.
-
Thanks, I created a user defined data type for the GS4 drives Modbus registers and created a user structure for all the drives. I could not figure out a way to put the data there directly in the MRX instruction, but the Memcopy was easy enough. Worked well. Thank you for that.
-
If you utilize the UDT Editor's View Memory Layout button, you can see how the fields line up in memory, corresponding directly with how you might be reading the data into your "raw" data via the MRX instruction (MEMCOPY does a blind byte-by-byte copy)
-
Be able to mix data types helped, but the MRX instruction won't accept it.
"GS4_RD" Structure Memory Layout (8 total DWORDs in length, DWORD Offset 0..7)
+------++----------------------------------------------------------------------------------------------------------------------------------++
| || Most Significant Least Significant ||
| ++----------------------------------------------------------------------------------------------------------------------------------++
| || DWORD ||
| ++----------------------------------------------------------------++----------------------------------------------------------------++
| || WORD 1 || WORD 0 ||
| ++-------------------------------++-------------------------------++-------------------------------++-------------------------------++
| || BYTE 3 || BYTE 2 || BYTE 1 || BYTE 0 ||
|DWORD ++---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---++
|Offset||b31|b30|b29|b28|b27|b26|b25|b24||b23|b22|b21|b20|b19|b18|b17|b16||b15|b14|b13|b12|b11|b10| b9| b8|| b7| b6| b5| b4| b3| b2| b1| b0||
+------++---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---++
Note: Every Bit Field layout only shows the Field # (no name). See the list of Bit Field Names listed by Field # at the end.
+------++---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---++----------------------------------------------------------------++
| 0 || 17| 16| 15| 14| 13| 12| 11| 10|| 9| 8| 7| 6| 5| 4| 3| 2|| 1 .WarningCode1 UWORD ||
+------++---+---+---+---+---+---+---+---++---+---+---+---+---+---+---+---++----------------------------------------------------------------++
| 1 || 19 .OutputFreq UWORD || 18 .CmdFreq UWORD ||
+------++----------------------------------------------------------------++----------------------------------------------------------------++
| 2 || 21 .DC_BussVoltage UWORD || 20 .OutputCurrent UWORD ||
+------++----------------------------------------------------------------++----------------------------------------------------------------++
| 3 || 23 .MultiSpeedStep UWORD || 22 .OutputVoltage UWORD ||
+------++----------------------------------------------------------------++----------------------------------------------------------------++
| 4 || 25 .InputCounter UWORD || 24 .WarningCode UWORD ||
+------++----------------------------------------------------------------++----------------------------------------------------------------++
| 5 || 27 .Reserved1 UWORD || 26 .PowerFactor UWORD ||
+------++----------------------------------------------------------------++----------------------------------------------------------------++
| 6 || 29 .Reserved2 UWORD || 28 .ActualMotorSpeed UWORD ||
+------++----------------------------------------------------------------++----------------------------------------------------------------++
| 7 || 31 .PowerOutput UWORD || 30 .Reserverd3 UWORD ||
+------++----------------------------------------------------------------++----------------------------------------------------------------++
List of Bit Fields by Field #
#2 (dw 0:16) .MotionStateBit0
#3 (dw 0:17) .MotionStateBit1
#4 (dw 0:18) .JogActive
#5 (dw 0:19) .DirStatusBit0
#6 (dw 0:20) .DirStatusBit1
#7 (dw 0:21) .StatusRsrvBit0
#8 (dw 0:22) .StatusRsrvBit1
#9 (dw 0:23) .StatusRsrvBit2
#10 (dw 0:24) .FreqSrcComms
#11 (dw 0:25) .FreqSrcAnalog
#12 (dw 0:26) .FreqSrcKeyPad
#13 (dw 0:27) .ParametersLocked
#14 (dw 0:28) .Running
#15 (dw 0:29) .StatusRsrvBit3
#16 (dw 0:30) .StatusRsrvBit4
#17 (dw 0:31) .StatusRsrvBit5
-
No, but you can use V as your raw IN buffer for the MRX, then utilize specific V addresses for Modbus HR, then use MEMCOPY from V to YOUR struct WITH properly named numeric and bit fields, and using MyDrive.OutputFreq and MyDrive.Running instead of V101 and V105:12.
This gets REALLY helpful when you have multiple drives
-
We have discussed updating MRX/MWX to be able to take a struct for the Do-more side parm. Probably should revisit that.
-
No, but you can use V as your raw IN buffer for the MRX, then utilize specific V addresses for Modbus HR, then use MEMCOPY from V to YOUR struct WITH properly named numeric and bit fields, and using MyDrive.OutputFreq and MyDrive.Running instead of V101 and V105:12.
This gets REALLY helpful when you have multiple drives
That is exactly what I did and yes very helpful.
-
We have discussed updating MRX/MWX to be able to take a struct for the Do-more side parm. Probably should revisit that.
It doesn't seem to be very efficient to have to use that intermediary memory area. Maybe the direct route would be the next evolutionary step?
-
It doesn't seem to be very efficient to have to use that intermediary memory area. Maybe the direct route would be the next evolutionary step?
When these instructions were developed, there were no structures that made sense to do it with. UDTs completely change that.
-
Don't forget EIP. That's my next project.
-
Definitely. We have a whole bunch of right click (context) menus many other places.
I can add a context menu the top level UDT dialog to Add/Edit/Delete UDTs (or View built-in structs), and also a context menu at the Edit UDT Definition dialog to AddToEnd/Insert/Duplicate/Delete/Edit fields.
I think UDT's (Hey look, ATU, we've converted BobO to using AB nomenclature for user types!) are something it would be useful to be able to store in external libraries as well,when you could get to that.
-
I think UDT's (Hey look, ATU, we've converted BobO to using AB nomenclature for user types!) are something it would be useful to be able to store in external libraries as well,when you could get to that.
For now, we have an import/export mechanism in the UDT dialog for sharing between projects.
We have always planned to develop a Library for UDTs and code-blocks, especially Subroutines.
-
...(Hey look, ATU, we've converted BobO to using AB nomenclature for user types!)...
Good lord, man, we aren't savages!
In truth we are starting to recognize the importance of terminology to intuitiveness. If 50% of the market know a certain thing by a certain name, it's kinda dumb to try to retrain them. There is a distinct possibility that someday DmD might even support tags. ;)
-
Actually, I like having both predefined memory locations and tag generation. It saves time not having to define tags for the simplest of things and simplified communications with other devices. Tags are great when working with data. Why throw the baby out with the bathwater? I knew they would come around someday.
-
Actually, I like having both predefined memory locations and tag generation. It saves time not having to define tags for the simplest of things and simplified communications with other devices. Tags are great when working with data. Why throw the baby out with the bathwater? I knew they would come around someday.
At the least there will be two modes, conventional and tag, but I suspect that our tag-based implementation will be more of a hybrid. You will lose nothing.
-
At the least there will be two modes, conventional and tag, but I suspect that our tag-based implementation will be more of a hybrid. You will lose nothing.
I'm with ATU on this one. Both is best, and memory architecture matters a lot to me. This is the way Siemens S7 works, and this is a part of why S7 and Do-More are my go-to controllers right now. Some preallocated table memory (though not expandable or shrinkable like Do-More), but most memory free for user defined "Data Blocks". It's kind of like a one-off UDT. The Data Block gets a name, and then you can put tags/heap items of internally defined typed or UDTs in it, even in arrays. So you create a DB called "Burner", and you might have a bit inside called "Enabled", which is then "Burner.Enabled" in logic. So they're better than AB tags, because you can get layers of hierarchy in the naming. AB is better on scoping. The only way with Siemens to scope a variable is to put it in a "Function" or "Function Block", which then must be called from logic. A regular logic file is called an OB or "Organization Block", and if it has the right number, will get called automagically without having to clutter up the ladder with calling it explicitly.
Oh, and S7 is smart enough to know that a 25-character tag name needs to be wrapped to a normal column width. Who knew? Control Logix, even after 20 years, still thinks it needs to be written out horizontally on one VERRRRRY long line.
One place S7 stinks is all the byte-based addressing (only on the predefined memory) and the goofy-butt endianness.
-
Good lord, man, we aren't savages!
In truth we are starting to recognize the importance of terminology to intuitiveness. If 50% of the market know a certain thing by a certain name, it's kinda dumb to try to retrain them. There is a distinct possibility that someday DmD might even support tags. ;)
Gee Brain. If we change everyone's name, won't they get confused about who they are?
-
Another suggestion is to provide default descriptions for the User Defined Data fields. When the Heap items are created, then the description fields are preloaded by those specified in the definition, but can be changed for individual instances.
-
Gee Brain. If we change everyone's name, won't they get confused about who they are?
Yes, Pinky. But that is a key part of my plan to take over the world.
-
Good lord, man, we aren't savages!
In truth we are starting to recognize the importance of terminology to intuitiveness. If 50% of the market know a certain thing by a certain name, it's kinda dumb to try to retrain them. There is a distinct possibility that someday DmD might even support tags. ;)
Yeah, I know what you mean. Interestingly, the effect varies varies from term to term. UDT seems to be burned into my lexicon, even though "Struct" would make just as much sense, whereas tags vs. heap I don't much care (though tags is more likely to work without explanation when the conversation has to include someone of undetermined background).
I kinda went off on a tangent with that post above. The basic intent was to concur with ATU that controllers with both classic table memory (presumably at least partially predefined), as well as tag/heap capability are the best of both worlds and make our lives easier, and to give kudos to Do-More and Siemens as the only two controllers I know of that have that. Then of course instead I go off into a long winded comparison of the merits of the memory structure of every PLC known to man! ;D
-
Concerning the use of UDT's. I tried to do a memcopy from the Standard V memory area to a UDT. Is this possible? If so what are the rules?
-
Concerning the use of UDT's. I tried to do a memcopy from the Standard V memory area to a UDT. Is this possible? If so what are the rules?
MEMCOPY size MUST be in terms of the # of UDT elements (NOT the # of V elements). If it is a Heap Item, the count (obviously) must be 1.
MEMCOPY Definitely useful for mapping MHR to/from a "Device" that are actually mapped to a bunch of "struct fields" (bits, floats, etc.).
-
For some reason, I keep wanting to right click to get a menu to insert a line. Probably decades of Excel use. Could that be something easily added? Have Insert, Delete on a right click menu? If its a lot of trouble, I would not mess with it.
Take 2 - this will be in the next release...
Added a context menu for the Edit UDT Definition dialog to Add/Insert/Edit/Delete... fields
(see UDTFieldEditContext2.png attachment)
Added a context menu for the SysConfig/MemConfig/UDT sub-dialog to Add/Edit/Delete... UDTs
(see StructListContext1.png attachment)