We are using the Labview DNP3 library to test our DNP3 slave. When the DNP3 master (Labview) sends group 0 variation 248, to get the serial number (using the Send Poll
Device attribute Vi), LabView is using qualifier code 6, instead of 0, which is incorrect. See DNP3 spec (IEEE 1815-2012) page 364.
Is there a problem with the Vi or anything we can do the make it to send qualifier code 0?
I tried to reproduce it with two kinds of masters available by my side - TMW's DNP3 master and VI master, using the first to poll all attributes and using the latter to poll two attributes (product name and serial number) from a VI client, and with both TWM's built-in packet capturer and Wireshark, I found the the qualifier code for serial number is 0x0, instead of 0x6, as shown in the attached screenshots. So I think there is no error in this.
I use DNP2.1 for the test.
Sorry I misunderstood it as that the response has 0x06 as qualifier code. Now I see that indeed our master has 0x06 in the read request as qualifier code.
There's no interface in the VI to modify this value currently.
We are investigating this issue (we haven't got access to the spec you mentioned but we are working on it; the specs we have seems not sufficient to conclude that 0x06 is wrong.) and we'll see whether to expose the interface to better solve the problem, etc.
I'll update later.
Sorry for the trouble and thanks.
Yes, the labview master is using the wrong qualifier. With version 2.1, there is still a problem. I'll wait for your update.
Would you share your use case? How you use DNP3 toolkit in your application, etc.? We need prioritization.
I've attached the block diagram. As we can see, we are using the Poll Device Attribute Vi with "Serial number".
We are considering fixing Group 0 Variation 248 (Serial Number) and adding what is now meaning - Group 0 Variation 245 (all attributes), but not adding Gr.0 Var.255 (supported attribute list), based on the limited time frame in our current project schedule. Do you think this is acceptable? If not, we'll try to fix it, even this may cause delay. So if you have strong need of Gr.0 Var.255, please tell us. If not, we plan to delay the fix of this particular attribute.
Product Support Engineer,
I don't understand why you are referring to variation 245 as "All attributes". It's variation 254 that reports them. Maybe a typo?
I don't need any fix for variation 255. So, it would be OK if you fix variation 248 and the other variations of the same kind that our DNP3 slave is using and that we may have to use in the LabView DNP3 master. Those are 242 - Software version, 243 - Hardware version, 246 - User assigned ID, 250 - Product name model and 252 - Manufacturer name. I guess that if you fix variation 248, variations from 242 to 252 will also be fixed, because they are using the same pattern.