search

byte-motion / RNL_RAPIDLibrary

A standard library of functionality for the RAPID programming language
MIT License
0 stars 1 forks source link

RMQ to be implemented #35

Closed RobotSigmund closed 3 years ago

RobotSigmund commented 3 years ago

More research.

TheHarvard commented 3 years ago

Capture

Interesting note:

RQM ca work across:

TheHarvard commented 3 years ago

seems like RMQ is built to harmonize with the Windows implementation of "Interprocess Communications" or "IPC".

TheHarvard commented 3 years ago

There seems to be the following restrictions:

RobotSigmund commented 3 years ago

Agreement on RMQ to be used as preferred protocol where applicable.

RobotSigmund commented 3 years ago

Verify if RMQ can be used to communicate between two controllers.

RobotSigmund commented 3 years ago

Further discussions between @RobotSigmund / @TheHarvard on how to implement RQM.

TheHarvard commented 3 years ago

Adding some correspondence between @TheHarvard @RobotSigmund and Tommy here for completeness:

image

image

image

(Clikcable hyperlink from mail above:)

https://developercenter.robotstudio.com/api/rwsApi/dipc_main_page.html

TheHarvard commented 3 years ago

To summarize current information:

TheHarvard commented 3 years ago

Current understanding of RMQ, IPC, and DIPC:

TheHarvard commented 3 years ago

Additional note: RMQ does not require mastership like manipulating data does. It is more akin to an IO signal

Note: SYS.cfg must be manually adjusted to expand queue to length 10, and max message size from 400 bytes to 3000 bytes

Note: Webservices queue is limited to 6 length and 425 bytes

TheHarvard commented 3 years ago

Created #53 To investigate how to handle Robot to robot messaging.

TheHarvard commented 3 years ago

Wokring with BM to implement Node-red RMQ support.

We are observing the following:

Curl command for creating Queue

 curl --digest -u "Default User":robotics -d "dipc-queue-name=RMQ_PS_TEST_QUEUE&dipc-queue-size=6&dipc-max-msg-size=425" -X POST "http://192.168.91.169/rw/dipc?action=dipc-create"

Curl command for sending a message with a command. 

curl --digest -u "Default User":robotics --data-ascii "dipc-src-queue-name=RMQ_T&dipc-cmd="1"&dipc-userdef=8192&dipc-msgtype=1&dipc-data=command;[[\"\",\"\",0,\"\",\"\",0,\"\"],\"comTest2\",[\"pose\",\"\",0,\"0123456789012345678901234\",\"\",0,\"\"],[\"\",\"\",0,\"\",\"\",0,\"\"],[\"\",\"\",0,\"\",\"\",0,\"\"],[\"\",\"\",0,\"\",\"\",0,\"\"],[\"\",\"\",0,\"\",\"\",0,\"\"]]" -X POST "http://192.168.91.169/rw/dipc/RMQ_T_PLC?action=dipc-send" -v -H "Content-Type: application/x-www-form-urlencoded; charset=ISO-8859-1"

It seems that there is a limit in size.

dipc-src-queue-name does not contribute to this size limit, indicating that the header in general does not contribute.

This does contribute to the size limit: command;[[\"\",\"\",0,\"\",\"\",0,\"\"],\"comTest2\",[\"pose\",\"\",0,\"0123456789012345678901234\",\"\",0,\"\"],[\"\",\"\",0,\"\",\"\",0,\"\"],[\"\",\"\",0,\"\",\"\",0,\"\"],[\"\",\"\",0,\"\",\"\",0,\"\"],[\"\",\"\",0,\"\",\"\",0,\"\"]]

counting the number of bytes, this would indicate a size limit of: 175 bytes 62 " While I would expect 444 bytes based on what the queue reports

command;[["","",0,"","",0,""],"comTest2",["pose","",0,"0123456789012345678901234","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]]

This size limit does not seem to exist when sending data from one RAPID task to another, but when sending data from Webservices to a task

The size limit seems to be 175 Bytes, and i have been unable to determine any way to increase it.

i will create an alternative data structure for "command" called "cmd" that has reduced overhead and less arguments.

The overhead of command is: command;[["","",0,"","",0,""],"",["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]] Which is 138 bytes.

The ovehead of cmd will be: cmd;["","","","","","","","","","","","",""] Which is 44 bytes

TheHarvard commented 3 years ago

The following command gave system fialure state, should probably flag this for ABB:

curl --digest -u "Default User":robotics --data-urlencode "dipc-src-queue-name=RMQ_PS_TEST_QUEUE" --data-urlencode "dipc-cmd=1" --data-urlencode "dipc-userdef=8192" --data-urlencode "dipc-msgtype=1" --data-urlencode "dipc-data=cmd%3B%5B%22%22%2C%22%22%2C%22comTest2%22%2C%22pose%22%2C%22%5B%5B115.995%2C-1.875%2C227.847%5D%2C%5B0.47315%2C-0.86893%2C0.12753%2C0.06944%5D%5D%22%2C%22%22%2C%22%22%2C%22%22%2C%22%22%2C%22%22%2C%22%22%2C%22%22%2C%22%22%5D" -X POST "http://192.168.91.169/rw/dipc/RMQ_T_PLC?action=dipc-send" -v -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8"
TheHarvard commented 3 years ago

Harris has been able to locate the following RobotStudio forum posts on the issues:

https://forums.robotstudio.com/discussion/9630/rmq-error-invalide-message

https://forums.robotstudio.com/discussion/9477/maxing-out-rmq-message-size

https://forums.robotstudio.com/discussion/12367/rmq-getmessage-fails-randomly

These posts seem to indicate that there exists an issue with RMQ/DIPC (through webservices or PC SDK) that causes failures when a message is sent that is shorter than the longest message sent thus far.

It is unclear whether or not "sent thus far" is reset at:

We should test this today, and determine if this is the source of our already very strange findings.

TheHarvard commented 3 years ago

Testing:

Setup

The robot is running with the following configuration:

      -Name "T_PLC" -Entry "RNL_main" -TrustLevel "None" -RmqType "Remote"\
      -RmqMode "Synchronous" -RmqMaxMsgSize 3000 -RmqMaxNoOfMsg 10

The robot uses the following program to receive RMQ messages

    RECORD cmd
        string object_type;
        string object_value_name_id;
        string method;
        string argument1_type;
        string argument1_value_name_id;
        string argument2_type;
        string argument2_value_name_id;
        string argument3_type;
        string argument3_value_name_id;
        string argument4_type;
        string argument4_value_name_id;
        string argument5_type;
        string argument5_value_name_id;
    ENDRECORD

            ...

    PROC debug()
        VAR cmd cmdData:=["","","","","","","","","","","","",""];
        VAR rmqmessage message;

        RMQReadWait message \TimeOut:=99999999999;
        RMQGetMsgData message,cmdData;

            ...

    ENDPROC

It is the RAPID instruction RMQGetMsgData that gives the error message "RMQ Error - Invalid message". This instruction is responsible for taking the data provided in ASCII form in the message, and load it into RAPID memory as normal data of the type given in the message.

Test 1

NOTE: The small, medium, and large messages are the same, with the exception of the X value beeing 1, 10 and 100.

Test 1 - Observations

For some reason, the string "[[10,2,3],[1,0,0,0]]" is not able to be converted into a string as part of the cmd record, while "[[1,2,3],[1,0,0,0]]" and "[[100,2,3],[1,0,0,0]]" has no issue.

The order of the messages (first smaller then larger VS firs larger then smaller) has no effect on whether the robot managed to convert the data into the cmd type.

Test 2

Skip to 30

Skip to 40

NOTE: CURL RETURNED THE FLLOWING WHEN TRYING 40 AND GETTING NO RESPONSE ... <?xml version="1.0" encoding="UTF-8"?><html xmlns="http://www.w3.org/1999/xhtml"><head><title>rw</title><base href="http://192.168.91.169:80/"/></head><body><div class="status"><span class="code">-1073445879</span><span class="msg">rws_resource_dipc.cpp[683] Message size is more than destination queue max message size limit code:-1073445879 icode:-1</span></div></body></html>

NOTE: CURL RETURNED THE FLLOWING WHEN GETTING NO RESPONSE ... <?xml version="1.0" encoding="UTF-8"?><html xmlns="http://www.w3.org/1999/xhtml"><head><title>rw</title><base href="http://192.168.91.169:80/"/></head><body><div class="status"><span class="code">-1073445879</span><span class="msg">rws_resource_dipc.cpp[683] Message size is more than destination queue max message size limit code:-1073445879 icode:-1</span></div></body></html>

Test 2 - Observations

Invalid messages

The RAPID command for converting text into RAPID data fails at seemingly random lenghts. It does not seem to be affected by what order you send the messages, but it might be affected by the content.

Max message size

There seems to be a cut of limit where 

curl --digest -u "Default User":robotics --data-ascii "dipc-src-queue-name=RMQ_PS_TEST_QUEUE&dipc-cmd="1"&dipc-userdef=8192&dipc-msgtype=1&dipc-data=cmd;[\"\",\"\",\"comTest2\",\"1234567890123456789012345678901234567890\",\"1234567890123456789012345678901234567890\",\"1234567890123456789012345678901234567890\",\"1234567890123456789012345678901234567890\",\"1234567890123456789012345678901234567890\",\"1234567890123456789012345678901234567890\",\"1234567890123456789012345678901234567890\",\"1234567890123456789012345678901234567890\",\"1234567890123456789012345678901234567890\",\"123456789012345678901234567890123\"]" -X POST "http://192.168.91.169/rw/dipc/RMQ_T_PLC?action=dipc-send" -v -H "Content-Type: application/x-www-form-urlencoded; charset=ISO-8859-1"

is the longest message can be sent. This message has a data size of:

cmd;["","","comTest2","1234567890123456789012345678901234567890","1234567890123456789012345678901234567890","1234567890123456789012345678901234567890","1234567890123456789012345678901234567890","1234567890123456789012345678901234567890","1234567890123456789012345678901234567890","1234567890123456789012345678901234567890","1234567890123456789012345678901234567890","1234567890123456789012345678901234567890","123456789012345678901234567890123"]

446 characters, which is very close to the limit specified when you use web services to examine the queue on the robot (444).

TheHarvard commented 3 years ago

Test 3

Test 3 - Observations

Based on the result above, it seems like 1/4 th of all lenghts will result in an invalid message. it also seems like it is every message length that is a multiple of 4 is invalid.

This result does not change if you send larger messages before smaller messages, or smaller messages before larger messages, and it seems to be true for a large area. The results seen in test 2 might indicate that it is basically true for the entire valid range of lenghts, even though an irregularity was noticed at the extreme lenght.

TheHarvard commented 3 years ago

further testing with ocellus indicates that:

TheHarvard commented 3 years ago

@TheHarvard and @RobotSigmund talked, and @RobotSigmund will create a RobDesk issue where we ask ABB about these issues.

TheHarvard commented 3 years ago

RMQ has been figured out as part of the wiig project.

It is now implemented as part of RNL.