DeviceNet GET_SET_ATT over DPM
Hi again,
I'm now trying to get the DeviceNet-Stack to work.
Cyclic data exchange works fine, but the GET_SET_ATT commands are not yet processed properly.
What I do now is the following:
CIFX_PACKET tRecvPkt;
cRet = xChannelGetPacket(hChannel, sizeof(tRecvPkt), &tRecvPkt, TIMEOUT);
if(cRet == CIFX_NO_ERROR) { /* got a packet */
if(READ_REQUEST(&tRecvPkt)) {
handle_read_req(&config_data, &tRecvPkt);
cRet = xChannelPutPacket(hChannel, &tRecvPkt, TIMEOUT);
}
else if(WRITE_REQUEST(&tRecvPkt)) {
handle_write_req(&config_data, &tRecvPkt);
cRet = xChannelPutPacket(hChannel, &tRecvPkt, TIMEOUT);
}
}
Where READ_REQUEST and WRITE_REQUEST check if it is indeed a DNS_FAL_GET_SET_ATT packet and determine whether it is a READ or WRITE request and handle_{read,write}_req do some data processing and store the corresponding data in the provided CIFX_PACKET (on READ) or in the device's memory (on WRITE).
Now this all works ok, but I always get Error 17: "No Response from the Device!" when trying to read/write attributes via the dialog in SyCon.
Can you point out where I do something wrong? I suspect it is an issue with not properly acknowledging the packets but I don't see my error.
FYI: the same code works fine for PROFIBUS (handle_{read,write}_req and {READ,WRITE}_REQUEST are defined differently according to a compiler switch which determines the fieldbus type), and I always seem to get the packets twice when using DeviceNet. I also checked the manual which is provided with the DeviceNet-Stack (Section 5.2.6 and 5.2.7 of "DeviceNet_Slave_Protocol_API.pdf" Revision 4), but this doesn't give any clues to what could be wrong.
I hope someone can explain ;)
simon
First tRecvPkt:
tHead:
ulDest = 0
ulSrc = 0x8006E610
ulDestId = 0
ulSrcId = 0
ulLen = 12
ulId = 0x7DABFBFE
ulSta = 0
ulCmd = 0x2D16
ulExt = 0
ulRout = 0xE61F7E33
tData:
usClassId = 100
usInstId = 0
usAttId = 0
usDataCnt = 0
bFunction = 2
bGenErrCode = 0
bAddErrCode = 0
bReserved = 0
reply to that:
tHead:
ulDest = 32 // set in my handler -- i also tried to fill this field with the ulSrc value of the request but the behavior doesn't change.
ulSrc = 0 // set in my handler
ulDestId = 0
ulSrcId = 0
ulLen = 252 // set in my handler according to the manual
ulId = 0x7DABFBFE
ulSta = 0
ulCmd = 0x2D14
ulExt = 0
ulRout = 0xE61F7E33
tData:
usClassId = 100
usInstId = 0
usAttId = 0
usDataCnt = 3
bFunction = 2
bGenErrCode = 0
bAddErrCode = 0
bReserved = 0
abData = "abc" // what I set before...
cRet after xChannelPutPacket: 0x0
Hi Simon,
Several things we will need to look at.
First: After you send the 0x2D14 there should be a response packet of ulCmd = 0x2D15 from sending your response packet to the packet interface. Look to the response packet and see if the ulSta or Status contains 0x0000. The cRet after xChannelPutPacket: 0x0 only indicates that your packet has been sent successfully. The ulCmd = 0x2D15 response should contain, if any, error information in the ulSta. Let us know if you do get an error here and we will help figure out what is going on.
Second:I noticed the ulLen = 252 // set in my handler according to the manual is not the correct length. Please let me know which manual you are referring to. The ulLen should be set to length of tData: in your example it should = 15.
Third: I noticed that the ulRout is filled in. I don't think this value should be filled in by your application.
Lastly: I don't know what kind of platform you are using to test the DPM. If you are using our windows driver then you can test your messages using the cifX Test application included with the install. You have to recreate your process manually Register Your App then respond to the get/set.
Let us know if this helps
T2
Hi Simon,Several things we will need to look at.
First: After you send the 0x2D14 there should be a response packet of ulCmd = 0x2D15 from sending your response packet to the packet interface. Look to the response packet and see if the ulSta or Status contains 0x0000. The cRet after xChannelPutPacket: 0x0 only indicates that your packet has been sent successfully. The ulCmd = 0x2D15 response should contain, if any, error information in the ulSta. Let us know if you do get an error here and we will help figure out what is going on.
I get a 0x2D15 for each 0x2D14 I send. All these contain ulSta = 0xC0000007.
Second:I noticed the ulLen = 252 // set in my handler according to the manual is not the correct length. Please let me know which manual you are referring to. The ulLen should be set to length of tData: in your example it should = 15.
I have this working on a netSTICK, so it can't be totally wrong! I have the information from "DeviceNet Slave Protocol API.pdf" delivered with the DNS Firmware. On page 79:
Field | Value ------------- ulLen | 252
Third: I noticed that the ulRout is filled in. I don't think this value should be filled in by your application.
I didn't fill that in, I just reused the packet I got for the reply. I also tried with ulRout = 0 which didn't change anything.
Lastly: I don't know what kind of platform you are using to test the DPM. If you are using our windows driver then you can test your messages using the cifX Test application included with the install. You have to recreate your process manually Register Your App then respond to the get/set.
I have a NXHX-500 RE board and a NEC microprocessor. I do send a DNS_FAL_CMD_REG_APP_REQ packet on communication startup which is answered correctly.
Hi Simon,
I get a 0x2D15 for each 0x2D14 I send. All these contain ulSta = 0xC0000007. This error is TLR_E_INVALID_PACKET_LEN please adjust ulLen to 15 for the example you sent. The ulLen should match the number of bytes in the tdata package. The manual is incorrect with the value of 252. I will have it corrected. I don't know why this would work on the netStick. Maybe the range checking has an issue with this library. ulRout should be 0. Don't reuse the value sent to you. Let me know how you make out.
BR
Terry
read requests work now (with the adjusted length.)
write requests still don't work. I'm now using a length of 12 when there is no data to send. Is this correct?
write requests work too. I had to set the field tData.usDataCnt to zero when reusing the request packet for the confirmation.
Hi Simon,
Looks like you are up and running. I apologize for the length error in the manual. I will make sure it is fixed.
Terry
Andreas Jacob
Hilscher Gesellschaft fuer Systemautomation mbH
Hi Simon,
your code looks ok.
But can you please post the contents of the first tRecvPkt and the according answer.
cRet = xChannelGetPacket(hChannel, sizeof(tRecvPkt), &tRecvPkt, TIMEOUT);Did you get any error return codes in cRet at any call?