st-one-io / node-red-contrib-open-protocol Goto Github PK

Hi,

I am currently working with MT Focus 6000 from Atlas Copco using this library in NodeRed. However, no matter how hard I tried, I can't get what I need by using the default MID provided or custom MID. Below are few tests that works and does not work (Each Connected means unplugged and plugged again as there is no respond anymore).

1. Connected, inject default MID 81 REV Auto, reply current time. Then, inject MID 0001 REV 6, reply MID 0002 REV 6. Then, inject back any of them or others, no respond.
2. Connected, inject MID 0001 REV 6, reply MID 0002 REV 6. Then, inject others no respond even default MID 81 REV Auto.

All I need is just to get the latest data (Peak (cNm), Step (degree), OK/NOK).

Urgently needs help on this issue. Hope to get reply.

Thank you.

Best regards,
Wing

Set revision default on change Mid Group.

When will send a custom mid, this node return the error error on send MID.

• Currently this list not have separators.
• Develop a list with separators of category Subscribes, Requests, Commands and Control.

Does this node automatically close the device connection and/or unsubscribe from subscribed MID's when you deploy the project?

I ask because, I am developing a flow that subscribes (last torque result) to a PF4000.
That PF4000 has another server connected to it with subscriptions.
Whenever I deploy my flow's, which is constantly as I am in development, it seems to affect the other connection.
I believe the PF4000 only allows 2 or 3 clients to subscribe, based on what I have seen so far.

To work around the issue I am seeing, I have to manually inject an unsubscribe, then I deploy my flow. I can give further details if needed.
Also, I use the auto subscribe property in the node.

• check the outputs of nodes on start
  

Hi,
Atlas is telling me that problems with their 6000 series tools losing subscriptions are down to the comms not being full-duplex. can you confirm if the comms are half or full duplex, so I can eliminate this as the problem?
Regards
Damian

• on Mid Group
  

• on Revisions
  

Setting a custom MID parameter: { "mid": 40 } returns a proper MID 0041 from controller, but inhibits the ability to send any (e.g. 7414, 2505, 150, 60, etc.) subsequent MIDs to a controller directly after receiving a MID 41 back.
It is almost like the controller "hangs" waiting for some information.
Repeatable on both Atlas Copco and Desoutter controllers.

"error on send MID - Error: service unavailable".
MID 0041 returns properly:

{
   "payload":"01C8380676      020000000852031990-01-01:01:17:340400479178  ",
   "mid":41,
   "revision":1,
   "noAck":false,
   "stationID":1,
   "spindleID":1,
   "sequenceNumber":0,
   "messageParts":0,
   "messageNumber":0,
   "_msgid":"c8...6f21",
}

Secondly, the serializer does not recognize the return from the MID 0040 when an error is returned: MID 004 with Error Code - 29 (Tool does not exist).

The built-in MID 0041 (should be titled MID - 40, not, 41) request midGroup works properly, with the ability to send more MIDs after MID 0041 is returned.

Define revision default auto or 1.

Define port 4545.