search

mz-automation / libiec61850

Official repository for libIEC61850, the open-source library for the IEC 61850 protocols
http://libiec61850.com/libiec61850
GNU General Public License v3.0
863 stars 461 forks source link

TYPE_CONFLICT in control object #472

Open koohestani opened 1 year ago

koohestani commented 1 year ago

We are trying to perform control object on a reference, but the command is rejected with TYPE_CONFLICT error. However, when executing the same command with other clients, such as Axon AT61 or IEDScout, it works without any issues. We suspect that the issue might be related to the sequence of MMS_Value in the request.

here is the sniffed request of mine: conflict

and here is the result perfomed by clients (like Axon AT61 or IEDScout) true

Regards.

mzillgith commented 1 year ago

You have to send the command with the correct type. You sent a boolean (single-point) but it seems a double point is expected for this command.

koohestani commented 1 year ago

You have to send the command with the correct type. You sent a boolean (single-point) but it seems a double point is expected for this command.

@mzillgith Thank you for your prompt reply. While the content of the requests appears to be the same, the sequence of the content differs. For instance, in my request, "bitString" appears first, but in the client's request, "bitString" is at the end.

startompiz12 commented 8 months ago

I just had the same issue, and after several days of trying to figure out what was wrong, it seems that in the config file (the converted ICD), the DAs order matters for the DO that contains the operate.

For instance, here is a declaration order that works for me: do_operate

I had another config file with the DAs being ordered differently, and I had the same issue as you with that config.

Hope that helps!

darkjhesus commented 8 months ago

I had the same problem but I could solve it adding the line command: control.SetOrigin("Texto Arbitrario", com.OrCat.STATION_CONTROL)