Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: RBPLC on March 15, 2021, 09:48:42 AM
-
Can a EIP Get instruction be mapped directly to a UDT heap item? It doesn't appear that it can be and I was just wondering if I was missing something. Currently I'm having to copying incoming data from the EIP Get to V memory and then map it to the UDT.
-
RBPLC, as you've already experienced, structures cannot be used for the response in the EIPMSG. A User Memory Block can be used, but not structures or structure members.
-
Can a EIP Get instruction be mapped directly to a UDT heap item? It doesn't appear that it can be and I was just wondering if I was missing something. Currently I'm having to copying incoming data from the EIP Get to V memory and then map it to the UDT.
The controller doesn't really care, but it's a little more nuanced at DmD than you might think. We see the need and are trying to support UDTs better in the future.
-
After I asked this question, I believe I remember having the same issues with the MRX and MWX commands. It's unfortunate that this isn't currently supported. UDT's are nice to use but their inability to be used everywhere causes issues when you have to remember when/where they can/can't be used. In this instance I had created a UDT with approximately 30 members that I had planned to directly map. I go to use the EIPMSG just to find out I have to map my UDT to V memory used with the MSG. If I had known/remembered this initially I wouldn't have created my UDT to start with. The UDT's are much less attractive when you have to use intermediate steps or combine them with other currently unsupported structures (timers especially) :(. Improvements in this area would be much appreciated.
-
We hear you. The new Modbus I/O Scanner makes great use of UDTs.
-
Modbus Scanner? When would this feature be available?
-
Modbus Scanner? When would this feature be available?
Late this year.
It probably wasn't clear from the picture, but everything you see was read from a device profile and took only seconds to configure.
-
If I had known/remembered this initially I wouldn't have created my UDT to start with. The UDT's are much less attractive when you have to use intermediate steps or combine them with other currently unsupported structures (timers especially)
I agree that it's less clean this way, but I think using a UDT is still worth it. The V-UDT move can be layout-agnostic with MEMCOPY (just byte shuffling). if you can get the data from the EIP get to the Vs in a value-agnostic way, then it's not much extra effort to be able to use the UDT.
-
Every time I try to use MEMCOPY, I can't get the errors to clear (I can't seem to get it set up properly). I assume this has to do with saving to V memory and UDT's being comprised of dw blocks? For example, from EIPMSG Get I'm reading in 32 bytes and placing them in V900. I'm trying to move 8 bytes into into dw 0:W0 - dw 1:W1 (4 unsigned words) in my UDT. I can't seem to get this to work using MEMCOPY.
-
Hmmm.....I think you can't memcopy to partial UDT instances, you have to hit the entire variable, IIRC. I had forgotten about that, if true. I think that was slated to change but probably has not yet.
-
:) I like that Modbus Scanner!
-
I like what I see here! Will it be able to easily read from multiple devices into multiple UDTs? Drive1, Drive2.. Drive9? How about read and writing seperately? I like to read at an interval, and only write if read value doesn't match desired value.
-
Hmmm.....I think you can't memcopy to partial UDT instances, you have to hit the entire variable, IIRC. I had forgotten about that, if true. I think that was slated to change but probably has not yet.
dw 0:W0 - dw 1:W1 is the entire scope of my UDT. The UDT consists of 4 unsigned Words. Should this be possible with MEMCOPY?
-
Currently limited to 32 devices.
Each device rests on top of a Modbus Client, which can be any valid client...serial or Ethernet.
A device has a scanner config that contains one or more Modbus comms, and then one or more fields per comm. This allows you to do bulk reads/writes, and then multiple field copies/conversions per comm.
Scanner reads and writes can be individually enabled/disabled. Scanner reads and writes have different time intervals, which can be changed at runtime.
A device can also have MSREGRD/MSREGWR instructions that allow you to do event based reads and writes.
A device can be created from a profile. A profile contains all of the scanner definitions, an associated UDT, and registers definitions for MSREGRD/MSREGWR instructions.
We will be providing profiles for ADC's Modbus capable equipment, but users can create their own profiles. We would like to have a public repository of profiles.
-
dw 0:W0 - dw 1:W1 is the entire scope of my UDT. The UDT consists of 4 unsigned Words. Should this be possible with MEMCOPY?
I think so, let me set it up and try it, unless one of the Host guys jumps in first.
-
Seems to work OK. I just MEMCOPYed 4 consecutive V-registers to a UDT instance consisting of two signed DWORDS.
Only caveat being that the MEMCOPY insisted I specify the data size in destination elements (1 in this case).
STR C77
MEMCOPY V0 TestUDTInstance0 0x30000 1
#BEGIN UDT_CONFIG
TestUDT
// Field Name, Data Type, Memory Layout, Read/Write, Display Format, Data View Detail
dw0, SDWORD, 0:0, Read-Write, Native, Short
dw1, SDWORD, 1:0, Read-Write, Native, Short
#END
#BEGIN MEM_CONFIG
TestUDTInstance TestUDT decimal 16
#END
-
You're right, it does seem to work. Like you said you have to specify the destination elements. I was taking the MEMCOPY validation warnings as it wouldn't work. You just have to ignore the warnings. Being able to use MEMCOPY does make it much easier to deal with transferring Words to UDT's for use in messaging instructions.