Don't comment the topic if you have a new question.
You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.
By lubi123, 22 September, 2010
Hi,
We tried to use GXDLMSDirector with Iscraemeco ME371 (with LN referencing), in direct connection with PC via serial port.
We managed to set ClientID, ServerID, password and application sucessfully connected to the device.
We checked PDUs as SNRM, AARQ, AARE and they seemed all right (also, InterfaceType was "General", UseLN was set to true, SupportNetworkSpecificSettings was set to false).
Now, when we tried to get registers with "Refresh" command, we got message that says: "Failed to receive reply in given time".
Further analyses showed that first byte array, returned by the function
m_Cosem.GetObjects(RegisterObjectType.LogicalDeviceName);
was OK, and device successfully replied to it.
However, the function:
m_Cosem.ReceiverReady();
returns byte array of length 27 or so. It containes LLC bytes and some additional data, but that is not what device expects.
We also had the chance to observe communication and PDUs between this device and concentrator, and we saw that all other PDUs (except first of course, which contained LLC, attributeID, InvokeId, priority...) sent from the client/concentrator to the device looked like this:
flag len addr segment HCS flag
--------------------------------------
7E A008 0223C9 51 FAA6 7E
7E A008 0223C9 71 F887 7E
7E A008 0223C9 91 F660 7E
7E A008 0223C9 B1 F441 7E
7E A008 0223C9 D1 F222 7E
7E A008 0223C9 F1 F003 7E
7E A008 0223C9 11 FEE4 7E
As it can be seen, this segmentation frames are 10 bytes in length, they don't contain LLC or any other additional bytes, and it seems that this is what device expects.
So we hope you could help us understand what's the problem, and tell us what we are doing wrong and maybe missing during initial settings.
Thanks!
Thank You, Lubi, for your message!
All the feedback we get, helps us improve our products.
Our developers are working on this, so please, check the Forum later for an answer.
Hi lubi123,
I'll have to say that this is my mistake. I made some changes to DLMS/COSEM component because it did not work with some other device.
Changes that I made, cause that it is not work with Iscraemecon devices.
I will fix this ASAP.
We will release new version in the next Wednesday.
Hi,
I see that now collecting registers works well, I tried it with Landis+Gyr zmd310 and it went well, and almost went well with above mentioned Iskra me371.
I got message that says: "GetAttributeType failed. Unknown data type." Then I saw that this is exception message from function GetAttributeType() in GxDlmsDevice class.
There's this check in code:
if (att.Index == attributeIndex)
but "attributeIndex" was always 0. So I just bypassed this condition like this:
if (/*att.Index == attributeIndex*/ true)
and retrieving registers went OK. After that it was possible to read selected register normally. I really don't what is this for, but there, just to inform you.
Cheers.
Hello Strahinja,
Thanks for letting us know that the collecting succeeded with L+G ZMD310, nice to hear.
But the error message You got with Iskra ME371, certainly needs attention. Thank You for reporting it! We'll see to it first thing Monday morning.
Have a nice weekend,
Gurux Ltd
Hi,
We found and fixed Iskra bug. Reason for this bug was that in Profile Generic, we ask what Interface's attribute is joined to Profile Generig's column. Iskra returns Zero if default attribute is joined.
There is new version available.
Happy Coding. :-)
Mikko
Thank You, Lubi, for your
Thank You, Lubi, for your message!
All the feedback we get, helps us improve our products.
Our developers are working on this, so please, check the Forum later for an answer.
Kindest regards, and thanks,
MerjaS
Hi lubi123,I'll have to say
More problems with Iskra...
Additional problems
Iskra bug fixed