Receiving Mid0004 INVALID_DATA for tightening subscription through Mid0008

[lonheijnen]

Hi,

First of all I would like to express my appreciation of this library. When I first read up on the documentation I was imagining having some kind of collection in Mid classes to cover the specific data for different revisions of the messages. This library really does a great job of covering that.

Now as for my issue.

I am trying to subscribe to the tightening results for a client I am developing for a MTF6000.
At first I was trying to do this by directly sending out a Mid0060, but this results in a Mid0004 containing error code UNKNOWN_MID.
Next I tried subscribing to a different event, the Alarms, again I received an UNKNOWN_MID.

After some Googling I found some documentation on interfacing with a MTF0600, this states that for this device you need to send a Mid0008 with the required subscription Mid + revision.

After finding this I was quite hopeful, however when I tried this I received a Mid0004 with error code INVALID_DATA.
From this I take that the message is probably missing some data, however I cannot find any documentation on Mid0008.

Does anybody have any experience in subscribing to events through the Mid0008 message?

Below an excerpt of my Subscribe method, which is determining which Mid to pass to Mid0008 to setup a subscription.

The mid being generated: "00290008001 006000700"

 public bool Subscribe(ACEventSubscription eventSubscription)
    {
      bool subscribeResult = false;
      Mid midResponse = null;

      Mid subscriptionMid = null;
      switch (eventSubscription)
      {
        case ACEventSubscription.TighteningResultData:
          subscriptionMid = new Mid0060();
          break;

        case ACEventSubscription.Alarm:
          subscriptionMid = new Mid0070();
          break;

        case ACEventSubscription.ParameterSetSelected:
          subscriptionMid = new Mid0014();
          break;

        default:
          throw new NotImplementedException($"Event subscription {eventSubscription} not supported.");
      }

      Trace.WriteInformation($"Subscribing to {eventSubscription}", nameof(Subscribe), CLASSNAME);
      midResponse = SendAndWaitForResponse(new Mid0008(subscriptionMid.Header.Mid.ToString(), subscriptionMid.Header.Revision, null).Pack(), TimeSpan.FromSeconds(2));
      if (midResponse != null)
      {
        if (midResponse.Header.Mid == Mid0004.MID)
        {
          subscribeResult = false;
          var mid0004 = midResponse as Mid0004;
          Trace.WriteWarning($"Failed to subscribe to {eventSubscription}", nameof(Subscribe), CLASSNAME);
          HandleDefaultCommmandError(mid0004);
        }
        else
        {
          Trace.WriteInformation($"Subscribed to {eventSubscription} events", nameof(Subscribe), CLASSNAME);
          subscribeResult = true;
        }
      }

      return subscribeResult;
    }

Any help is greatly appreciated :)

Thanks in advance,

Lon Heijnen

[roberto-guerzoni]

Hi, you could try subscribing to the service by specifying a lower revision. The library tries to subscribe to the service with LAST_REVISION = 7 but the screwdriver does not necessarily support that revision....

[lonheijnen]

Hi, you could try subscribing to the service by specifying a lower revision. The library tries to subscribe to the service with LAST_REVISION = 7 but the screwdriver does not necessarily support that revision....

Thanks for your response.

I have tried that already, actually I've tried all revisions. No matter which I choose, I get the INVALID_DATA. Does the INVALID_DATA message imply the message is not supported? I would expect SUBSCRIBED_MID_UNSUPPORTED for that, or SUBSCRIBED_MID_REVISION_UNSUPPORTED if the revision is not supported.

Edit: it seems to be the mid0008 message is malformed, hence the INVALID_DATA. But I cannot find documentation or examples on mid0008

Regards,
Lon

[roberto-guerzoni]

Hi Lon, for ATLAS screwdrivers it happened that with a too advanced revision the INVALID_DATA error was returned, for other brands I don't know sorry. Regards , Roberto Il giorno lun 29 mag 2023 alle ore 10:43 Lon Heijnen < ***@***.***> ha scritto:

…

Hi, you could try subscribing to the service by specifying a lower revision. The library tries to subscribe to the service with LAST_REVISION = 7 but the screwdriver does not necessarily support that revision.... Thanks for your response. I have tried that already, actually I've tried all revisions. No matter which I choose, I get the INVALID_DATA. Does the INVALID_DATA message imply the message is not supported? I would expected SUBSCRIBED_MID_UNSUPPORTED for that, or SUBSCRIBED_MID_REVISION_UNSUPPORTED if the revision is not supported. Regards, Lon — Reply to this email directly, view it on GitHub <#101 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACT7RNGMY4K3KNRSPBRVWTLXIROUNANCNFSM6AAAAAAYQWAOBY> . You are receiving this because you commented.Message ID: ***@***.***>

[Rickedb]

Hello @lonheijnen ! I appreciate that and it's always rewarding knowing that the lib is helping more people.

About your problem, the lack of information and documentation of Atlas Copco devices are always the major problem while developing. Well, since you've tested all revisions already, I believe it's something with Extra Data Length or Extra Data.

Some controllers are a bit weird while parsing and the do not follow the same behaviour of the documentation as it is described, so, I would recommend you if you can try sending it without adding the extra data length like: "00270008001 0060001" or "00290008001 0060001 "

You must do it without using de NuGet package, since now it will always add 00 when ExtraDataLength property is not filled.

Give us any feedback if you find something else!

[lonheijnen]

@Rickedb I actually already tried ommitting the extradata (length). But I did not yet try with the spaces rather than the zeros at the end. I will give this a try.
Thanks!

[lonheijnen]

Leaving out the zeroes at the end or replacing by spaces does not help either.
I've tried to subscribe to some other event, the 0900, and this time the message was actually accepted (include the extra data length in the message)

So this INVALID_DATA does not seem to imply that the message format is incorrect.
I think that either the device does not support this Mid0060 or something in the configuration is not setup correctly.

[Rickedb]

It's a bit weird btw, Mid 0060 is one of the most common subscriptions to subscribe.

However, since you could subscribe to 0900, it might be a problem with the controller itself, is it in the latest available firmware?
I remember asking Atlas Copco to update the firmware sometimes due to some open protocol bugs

[lonheijnen]

We have upgraded the software but that did not help.

It turns out, for the MTF6000 the 0061 is not supported. Instead there is a different event to subscribe to: "1201 operation result overall data". Once subscribed you will receive a 1201 back. And once the device is used for tightening 1202 messages will come containing tightening details.

(The 1201 that you receive back is not being parsed properly by the way, but I don't think it contains valuable information anyway)

Thanks for all the help.

And again, kudos on creating such a nice library.

Regards,
Lon

[Rickedb]

But is there any solution to retrieve the tightenings from MTF6000?

Also, if it's parsing wrong, if you could please provide an ASCII example so we can fix it at the library it would be good!

[lonheijnen]

I don't think so.
https://www.flexibleassembly.com/core/media/media.nl?id=2246365&c=337772&h=h298qTMU439xmKBXNmNY4w9qaNS9qZGpz9mwFtODA8gkZj9I

The only way to get tightening details seems to be the 1201/1202 messages.

This is the full string:
"006912010010 00 00200100000090692023-05-31:16:29:2110000100001000"

As a byte array System.Text.ASCIIEncoding.ASCII.GetBytes(response.MessageString):

{byte[69]}
    [0]: 48
    [1]: 48
    [2]: 54
    [3]: 57
    [4]: 49
    [5]: 50
    [6]: 48
    [7]: 49
    [8]: 48
    [9]: 48
    [10]: 49
    [11]: 48
    [12]: 32
    [13]: 32
    [14]: 32
    [15]: 32
    [16]: 48
    [17]: 48
    [18]: 32
    [19]: 32
    [20]: 48
    [21]: 48
    [22]: 50
    [23]: 48
    [24]: 48
    [25]: 49
    [26]: 48
    [27]: 48
    [28]: 48
    [29]: 48
    [30]: 48
    [31]: 48
    [32]: 57
    [33]: 48
    [34]: 54
    [35]: 57
    [36]: 50
    [37]: 48
    [38]: 50
    [39]: 51
    [40]: 45
    [41]: 48
    [42]: 53
    [43]: 45
    [44]: 51
    [45]: 49
    [46]: 58
    [47]: 49
    [48]: 54
    [49]: 58
    [50]: 50
    [51]: 57
    [52]: 58
    [53]: 50
    [54]: 49
    [55]: 49
    [56]: 48
    [57]: 48
    [58]: 48
    [59]: 48
    [60]: 49
    [61]: 48
    [62]: 48
    [63]: 48
    [64]: 48
    [65]: 49
    [66]: 48
    [67]: 48
    [68]: 48

P.s. I noticed the Mid0009 is not implemented to unsubscribe from events.
I guess that is fine though, if the connection is lost the event subscription will expire anyway.

[AndreasReitberger]

I'm facing the same issue.
I tried to send 006000080010 1201001310000000000000000000000000000001 which seems to work for subcription, however I cannot parse the result.

Could not found a message parser for mid 1201, please register it before using

The result looks like
006912010010 00 00200100000003732023-07-07:07:00:4810000100001000

I couldn't find any infos how to register the message parser for the MID1201. Any suggestions?
Thanks !

Edit: Nevermind, just needed to add typeof(Mid1201) to the interpreter. Is there a way to generate the
006000080010 1201001310000000000000000000000000000001
with new Midxxxx().Pack()? At the moment, I just send it as plain text.

Thank you!

[Rickedb]

Hi @AndreasReitberger, there is still no way of providing the desired subscription mid to Mid0008 for generating the extra data by itself.
Btw it would be a good feature to be added, since it would solve many issues of how Mid0008 works.

I will keep it at the backlog.