ABB Nodes
ABB Robot Nodes
- abb-robot-rmq
- abb-robot-io
- abb-robot-fileservice
- abb-robot-webservice
- abb-robot-subscription
- abb-robot-command-builder
- abb-robot-rmq-parser
- abb-robot config node
RMQ / DIPC / IPC
General
ℹ️ NOTE: This document is based on RMQ / DIPC / IPC as implemented through web-services. It is also possible to implement RMQ / DIPC / IPC through PC SDK, which might change some of the details.
RMQ / DIPC / IPC (RMQ) is a communication protocol that is built into the "Multitask" and "PC-Interface" of the ABB robots. It is a old and relatively low level (lower than RAPID) communication protocol that allows messages to be sent from one "Queue" to another. The following concepts are implemented as part of RMQ:
-
Message - A message is a communication between two users/queues in RMQ. A message can theoretically contain up to 3000 bytes though Webservices imposes a 444 byte limit. Each message contains:
- A source queue which specifies where replies should be sent (Required)
- A label designating what datatype is being sent (Optional)
- A ascii coded, easy to read body containing the actual data sent (Optional)
- A "UserDef" which is a 15 bit number containing meta-data about the message (Required)
-
Queue - A queue is a user (server, client, terminal, consumer, producer) of messages. A queue exists for each RAPID task, and must be manually created for any other user in the system. A queue has a queue size (mex allowed messages in the queue), and max message size (Bytes).
The Robot Norge RAPID team has determined that RMQ is the preferred communication protocol for communicating both internally and externally between asynchronously executing programs, and will push RMQ as the interface to use when possible
Queues
Creating Queues
Webservices
When using webservices, a queues can be created with the following command:
curl --digest -u "Default User":robotics -d "dipc-queue-name=[RMQ_NAME_OF_QUEUE]&dipc-queue-size=8&dipc-max-msg-size=444" -X POST "http://[ROBOT_IP]/rw/dipc?action=dipc-create"
The queue is cleared when the robot controller restarts, so the queue must be created again.
Note that the queue is created with queue size of 8 and max message size of 444.
After creating the queue, the queue can be referred to with the [RMQ_NAME_OF_QUEUE] (Which should be set to the actual name of the queue) in Webservices and in RAPID.
The name of the queue should be all capital letters and words separated by underscores, and be prefixed by RMQ_.
Robot
To properly configure the queue for the robot tasks, manually adjust the SYS.cfg file to include the following RMQ parameters for each task:
(NOTE the file must be manually adjusted as the parameters are not accessible from the TPU/FPU or RobotStudio)
-Name "T_ROB1" -Type "NORMAL" -MotionTask -RmqType "Remote"\
-RmqMode "Synchronous" -RmqMaxMsgSize 3000 -RmqMaxNoOfMsg 10
The task queue names are always "RMQ_[NAME OF TASK]", so in the example above it is: RMQ_T_ROB1.
Sending messages
Meta-Data
The UserDef part of the message is a 15 bit number that represents meta-data. The meta-data performs two functions; The 2 highest bits of the meta-data is reserved for specifying what kind of instruction-type the message is, while the 13 lowest bits are used as a unique identifier to track the message and replies.
There are 4 instruction types: EVENT, EXECUTE, ALLOCATE, RESPONSE.
In short, EVENT instructions trigger events (and do not care who or if anyone is listening), EXECUTE executes specific code, ALLOCATE allows the dynamic allocation of large data structures, and RESPONSE is a response to an earlier instruction.
See overview below:
| Instruction (2 higher bits) | Description | Identifier (13 lower bits) | Description |
|---|---|---|---|
| 00 (0) EVENT | An EVENT instruction will trigger an event with the message data as value. No response is expected when triggering an event. | Event ID | The Event ID is the numeric ID of the event that should be triggered. |
| 01 (1) EXECUTE | An EXECUTE instruction try to execute the data in the message. A response with the result (success flag, error message, return value) is expected. | Response ID | The Response ID is a unique number that will be used in responses to this instruction. |
| 10 (2) ALLOCATE | An ALLOCATE instruction will allocate memory for the message data in the robot controller and return a pointer to it | Response ID | The Response ID is a unique number that will be used in responses to this instruction. |
| 11 (3) RESPONSE | An RESPONSE is not an instruction, but signifies that the message is a response or reply to an instruction. | Response ID | The Response ID is a unique number that was specified in the original instruction. |
ℹ️ NOTE: that if no response is wanted, then the Response ID can be set to 0. This will skip any reply.
Sending message with Webservices and Curl
To send a message with webservices the following command should be used: [RMQ_NAME_OF_QUEUE] represents the name of the queue (the same as the one used to create it). [DATA] represents the data to be sent. This should be of a specific data type in the robot controller and type and value should be separated by a semi colon. example: num;1 or pos;[0,0,0] or string;"This is a stiring" (Note that the " character may need to be escaped). [META-DATA] is the meta data for the message. Example: 0 or 3 or 2200.
curl --digest -u "Default User":robotics --data-ascii "dipc-src-queue-name=[RMQ_NAME_OF_QUEUE]&dipc-cmd="1"&dipc-userdef=[META-DATA]&dipc-msgtype=1&dipc-data=num;1" -X POST "http://192.168.91.150/rw/dipc/RMQ_T_ROB1?action=dipc-send" -v -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8"
here is an example with all the data:
curl --digest -u "Default User":robotics --data-ascii "dipc-src-queue-name=RMQ_OCELLUS&dipc-cmd="1"&dipc-userdef=0&dipc-msgtype=1&dipc-data=num;1" -X POST "http://192.168.91.150/rw/dipc/RMQ_T_ROB1?action=dipc-send" -v -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8"
Sending EXECUTE messages to execute RAPID procedures
When sending EXECUTE messages you need to set the meta data to EXECUTE (1) and the Response ID that is wanted (can be 0 if no response is wanted).
When the robot receives and EXECUTE message of the type "command" then it will try to execute that command, and if everything is successful it will return the same message as a RESPONSE message with the same Response ID.
If the robot fails to fully execute the Procedure specified in the EXECUTE messages, it will return a RESPONSE message with the same Response ID, but the data will be of a type "ErrorInfo". This data may contain data describing which error caused the procedure to fail. The following is a proposal for how this datatype should be structured:
RECORD errInfo
string context;
num err_number;
string err_name;
string err_type;
string err_domain;
string err_text_title;
string err_text_str1;
string err_text_str2;
string err_text_str3;
string err_text_str4;
string err_text_str5;
ENDRECORD
PERS errInfo <ID>:=["",0,"","","","","","","","",""];
The context string is for a Note that the err_number might change over time.
Sending message with RAPID
To send messages with RAPID, the following methods are used (See their respective documentation in RobotStuido):
- rmqfindslot()
- RMQSendMessage()
Receiving messages
Receiving messages with Webservices
BM should add information here about how this is done...
Receiving messages with RAPID
To recive a message with rapid the following methods are used (See their respective documentation in RobotStudio):
- RMQGetMessage()
- RMQGetMsgHeader()
- RMQGetSlotName()
- RMQGetMsgData()
Examples
These examples are set up for how to send commands to the robot controller using curl.
A command is a datatype defined in the robot controller that can be sent as part of a EXECUTE mode RMQ message to force the robot controller to execute an arbitrary defined method.
After completion, the robot controller will send a response RMQ message with the result. If an error occurred, the response will be of an error type. If the procedure succeeded, the response message will contain the command that was sent, with any return data that was generated. The response can also be skipped if the id is set to 0 (see above)
A command consists of:
- The object that the procedure should be executed on.
- The procedure that should be executed by the robot controller.
- The arguments (up to 5) that the procedure should be executed with (Can be set to null).
Here is an example of the command datatype:
[["","",0,"","",0,""],"",["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]];
Example 1: Calling a method with no arguments
To call a method with no argument, the following command can be sent:
[["","",0,"","",0,""],"moveToHome",["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]];
This command will call this procedure in the robot controller:
PROC moveToHome()
!Code example
ENDPROC
The response after (successfully) executing this method will be:
[["","",0,"","",0,""],"moveToHome",["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]];
Example 2: Calling a method with arguments
To call a method with arguments, the following command can be sent:
[["","",0,"","",0,""],"pick_place",["pose","",0,"[[0,0,0],[1,0,0,0]]","",0,""],["pose","",0,"[[0,0,0],[1,0,0,0]]","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]];
This command will call this procedure in the robot controller:
PROC pick_place(pose pickPoint, pose placePoint)
!Code example
ENDPROC
The response after (successfully) executing this method will be:
[["","",0,"","",0,""],"pick_place",["pose","",0,"[[0,0,0],[1,0,0,0]]","",0,""],["pose","",0,"[[0,0,0],[1,0,0,0]]","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]];
Example 3: Calling a method with RETURN arguments
To call a method with RETURN data (arguments), the following command can be sent:
[["","",0,"","",0,""],"getCurrentPosition",["pose","",0,"[[0,0,0],[1,0,0,0]]","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]];
This command will call this procedure in the robot controller:
PROC getCurrentPosition(INOUT pose point)
!Code example
ENDPROC
Example response after (successfully) executing this method will be:
[["","",0,"","",0,""],"moveTo",["pose","",0,"[[100,200,300],[0,0,1,0]]","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""],["","",0,"","",0,""]];
Conveyor tracking
To implement conveyor tracking the master system needs to access the conveyor positions on the robot controller.
One way of doing this is to manually access the IO that sends the conveyor count to the robot.
The IO is named: c1CntFromEnc .
This Io will only be updated once each time the camera shutter is exposed, and will not update in between. Due to this, it might be necessary to use the timestamp to interpolate conveyor positions between shutter exposures. Due to timing, it might be necessary for the robot to buffer this locally.
Development
- To deploy to node-red running in a docker container, run:
npm run build && docker exec -it <container-id> bash -c 'cd /data && npm rebuild' && docker restart <container-id> && docker attach <container-id>
RobotStudio
RobotStudio can be downloaded from ABB: Download RobotStudio Setup a virtual controller of your choice.
Enable communication with Virtual Controller
In order to allow requests from any IP on the network we can redirect REST API to 0.0.0.0 and port 80:
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=80 connectaddress=127.0.0.1 connectport=80
Add firewall entry:
netsh advfirewall firewall add rule name="Open Port 80" dir=in action=allow protocol=TCP localport=80
You should be able to connect on port 80 (WWW) of RobotStudio from any IP
Release
Make sure you have publish access rights for your token. Make an NPM minor release:
npm run build
npm version minor
npm publish
git push
git push --tags