DNS_GET_SET_ATT_IND: READ -> usDataCnt always zero
Hi,
I'm working on a configuration/verification tool for our products which should work over both Profibus and DeviceNet. I've got a problem when using DeviceNet: no matter what I put into the field data_cnt of the struct RCS_MESSAGETELEGRAM_10 I always receive a zero in the field usDataCnt of DNS_PACKET_GET_SET_ATT_IND when trying to read from the device. All works as it should when writing.
I assume there's a bug in the DeviceNet-Stack which garbles the data somehow.
Well, I built a host application based on the DRVPRG\...\DEMO\C\ example on the CD which is enclosed with the CIF cards, which connects to the network over a CIF50-PB/CIF50-DN card.
I then send messages of the type RCS_MESSAGETELEGRAM_10 to the network (as demonstrated in the example).
On the device side (netSTICK) I then get DNS_GET_SET_ATT packets (if connected over DeviceNet) or PROFIBUS_FSPMS_C1_READ/WRITE packets (if connected over Profibus).
Now, if a DNS_GET_SET_ATT_IND packet is of type DNS_FAL_GET_SET_ATT_READ (pkt->tData.bFunction) the field pkt->tData.usDataCnt is invariably zero.
In case of a DNS_FAL_GET_SET_ATT_WRITE packet, everything is ok.
If I'm doing exactly the same over a Profibus connection, everything is ok as well.
RCS_MESSAGETELEGRAM_10 parameters for DeviceNet:
rx = 3, tx = 255, nr=
device_adr = 32 -- address of the netSTICK
data_area = 100 -- first user class
data_adr = 0 -- instance
data_idx =
data_cnt =
data_type = 10 -- doesn't seem to make any difference what stands here
function = 1 -- for DNS_FAL_GET_SET_ATT_READ
the values in <> are different with messages.
The values I (my host app) supply for data_cnt in the RCS_MESSAGETELEGRAM_10 don't survive until the netSTICK user task sees the messages if b = 0x4a and function = 1 in the RCS_MESSAGETELEGRAM_10
----
RCS_MESSAGETELEGRAM_10 parameters for the other messages (only what differs from the ones above):
b = 0x4a, function = 2 for DNS_GET_SET_ATT_IND with DNS_FAL_GET_SET_ATT_WRITE
b = 17, function = 1 for PROFIBUS_FSPMS_C1_READ_IND
b = 17, function = 2 for PROFIBUS_FSPMS_C1_WRITE_IND.
Conclusion:
I don't get any value for pkt->tData.usDataCnt except zero, when sending DeviceNet GET_ATTRIBUTE messages.
I get my supplied values for pkt->tData.usDataCnt when sending DeviceNet SET_ATTRIBUTE, Profibus C1_WRITE or Profibus C1_READ messages.
Hope this clarifies my issue.
Hi Simon,
When using the RCS message to read an attribute you set the
function = 1<-Read
data_cnt = 3
The data count value will never be reflected in the telegram sent to the slave. It will always be zero. Please look to the section 5.2.10 of the dnm_pie.pdf manual. This should not be a bug in the stack. The stack will ignore the value you put in data_cnt. It will always be zero on the other end when using DeviceNet.
Doc section
msg.data_cnt =
0 unused in read access
1-240 length of attribute data in write access
It is up to the user application on the netX side to fill in the length of this data associated with the particular Class, Instance, and attribute requested during a read.
Once you receive the DNS_GET_SET_ATT_IND you should respond with a DNS_FAL_CMD_GET_SET_ATT_RES command filling in the DNS_FAL_GET_SET_ATT_RES_T usDataCnt with the size of the buffer your application decides to return.
The master is not aware of the size ahead of time.
Please let me know if this clarifies the issue for you.
Oh ok, I actually solved it that way in my application, but thought of it as a workaround because with PROFIBUS the value gets sent.
simon
PS: In my case (a configuration app for in-house use only) the master (well the programmer who writes the app) is actually aware of the different sizes. ;)
Hi Simon,
I am glad you have things working OK. I have seen that you are making good use of our board. In the case of DeviceNet the reads/writes are a little different. Profibus requires a length during the read.
BR
Terry
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi Simon,
I am a little bit confused :?
RCS_MESSAGETELEGRAM_10 is a message from the chip EC1.
DNS_PACKET_GET_SET_ATT_IND comes from a netX stack.
Can you please give me some more explanations.