Dear, when reading the doc depicting how RTDE works, I find it a bit tricky to handle the receiving package from controller. Assume external PC is packing setup message while the controller is sending data package out. And the data package will stay in buffer till PC turns to wait for receiving setup response, and what PC gets is actually data package rather than setup response. Another problem is we need to flush the buffer each time before we tend to receive the latest value. Is there any point I’m wrong? Please help to point it out. Thanks. BTW, I assume it uses TCP/IP connection instead of UDP.
We basically rewrote the python library that you can find at the bottom of here to run in nodejs so that we could use the asynchronous nature of the library as well as to work with a lot of our other modules that interact with the robot.
The sequence of steps we take in the code is to connect to the client and ask for the controller version, just to ensure that we ahve a controller that works with RTDE, we then negotiate the protocol version we are going to use. Once that is done we will then set-up all of the different packets that we want to hear back from the server. Once that is done we start the server synchronization. By using a .on() method we are able to receive each of the buffer packets into memory and then process them. Even if they are coming in faster than we can process they are stored in memory in the order in which they are received and processed accordingly.
Part of our set-up of the data that we want returned to us is how to decode the data so as we are building out the string of objects to listen for we are also building our a string of how to decode the buffer that comes back to us. We then just simply parse back through the buffer when it comes back and link everything back together. By following the examples given in the above link we were able to rather quickly get up and running with the python library, it took about a week to get the nodejs library working but it works very well now. If I want to add additional parameters I simply add them to our configuration file which is simply a JSON object and then restart the client with the new configuration.
Dear Mbush
What a detailed description! Thanks. I read the python lib already. And it is the same as you said. I have a concern when we are waiting for setup response, we may receive the data package or message package instead if the synchronization is going on when we just start to send setup package. The reason is data and message are sent out without request seperately. How to handle this?
BR
Songlin Cai
Dear Songlin Cai,
I have not experienced an issue where we receive the data buffer prior to starting the synchronization. Once we have completed the set-up we send the synchronization start command and then only do we begin to receive any data. The irony is, because of the way that we wrote our code and the asynchronous nature of node.js we could actually handle receiving the data before synchronization was complete and the code would not know any difference.
Also, we do not run the RTDE on the client computer of the robot but rather on a separate computer that is attached via TCP/IP over ethernet. Not sure if this creates a better or worse situation but we have not had any issues with the protocol once we got the encoding/decoding working correctly.
Matt
Dear Mbush
If we know how controller sends data, it might help. For instance, if the controller sends one package at most within one 8ms cycle, we could find a workaround for a more robust program.
BR
Songlin Cai
The controller streams data to you at 125 Hz, so only one package every 8ms but if the controller needs the entire time slice for processing my understanding is that it will not send out packet during that time slice. We have not seen this that I am aware of but when you get it every 8ms hard to tell if you are missing a slice.
On our other software where we are listening to the streaming port (30003) we actually only process every 10 data packets and this is close enough to real time for what we are doing with that data.
Thanks,
Matt
10Hz with port 30003? That’s far away from declared 125 Hz.
No, its streaming at 125 Hz, we just process every 10th item that we receive. Its to limit the load on our embedded computer that we use for processing all of the information. We do not actually have anything run on the robot controller, we use a separate embedded computer for all of our cloud connections. So instead of getting a data packet update every 8ms we get one every 80ms. Believe it or not, cut our CPU load from around 90% to less than 15%. I have since learned a better way to decrypt the buffer and when I have the chance I will be changing that on the RTE port 30003 code that we have and that should resolve our CPU load issue and go back to reading each packet that is sent to us.
Hope that makes more sense.
I need to process data transmitted through port 30003 real time client.
however i have a hard time try to convert the value. assume that i need to get actual tool position for x axis, i should read the gnuplot col 56. the byte array i get is { 63, 130, 91, 86, 58, 246, 92, 22 }
when i convert it to double in C#
it shows
my robot is at home position so it should have x position = 0
any idea on how to convert this?
Hi? I haven’t started to process 30003. One note is to take care of big endian and little endian issue.
BR
Songlin Cai
You may want to move the robot to another position and try again, the accuracy is probably not going to return 0 at double precision, if you were to round that number that you are printing to the console, it would round to 0
For instance
console logged 5.91E-201
rounded to 6 decimals 0