Request for User Data Type Editor

[ATU]

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.

[franji1]

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.

[ATU]

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.

[franji1]

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)

[ATU]

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)

Code: [Select]

+------++----------------------------------------------------------------------------------------------------------------------------------++
|      || 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

[franji1]

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

[BobO]

We have discussed updating MRX/MWX to be able to take a struct for the Do-more side parm. Probably should revisit that.

[ATU]

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.

[ATU]

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?

[BobO]

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.

[ATU]

Don't forget EIP. That's my next project.

[Controls Guy]

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.

[franji1]

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.

[BobO]

...(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. 

[ATU]

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.