We have an “old” UR5, CB1. We mounted a camera on the tool flange. We use the robot to sweep a lineair segment. The camera records a 3D image during the sweep. The robot sends a “capture image” message via socket_send_string() just prior to making the sweep. The problem we observe, is that this message comes sometimes way before the sweep is supposed to be made, e.g. while the robot is still moving toward the starting point. Sometimes, it’s quite close to the actual moment. We observe differences of 1 second. Sometimes only 100msec or so. Throughout the trajectory of moving from sweep position to another sweep position, the robot is very consistent, but the delays are awful.
We tried to switch to MODBUS I/O, but it has more or less the same problems. We cannot rely on accurate timing. Switching to a digital output is an option, but requires a lot of work. But would that be reliable? We don’t want to make a lot of effort to come to the conclusion that I/O’s don’t work reliably either.
Does anyone have experience with this? How did you solve the sync issue? The scans themselves look ok. We scan with a resolution of 0.25mm in X,Y,Z and the images look good. Just the startpoint needs to be synced correctly. BTW we do not require an encoder (were would we fit it?).
Try putting a sync() command after the movement command of the robot and before the socket_send_string() command. This should make the program wait for the robot to finish moving and then send the socket message.
Thanks for your answer. This almost works. I do get the TCP/IP message nicely in time, my scans look very nice now, BUT somehow, the ORDER of the move and send_string gets reversed!! So the move is executed first, then the string is send, although in Polyscope the order is FIRST send string THEN do a move. I now have to puposely reverse the order of commands to get good results. The funny thing is, the first time through the loop, the order is good, second time through it gets reversed…
I “sprinkled” sync() everywhere, but there’s no further improvement.
So it seems to be some kind of thread timing issue then…Although I do not use threads or subroutines in my program, I do sem to be affected. Are there any ohter sync() versions I can use, to REALLY force order of Polyscope commands?
Do you have a return from the computer when the string is recieved. Then you could place a read_string after the send_string and the robot would wait for this string to be recieved before executing any further commands or 2 seconds for the command to time out.
In our experience there can be a slight delay on socket communications, meaning it’s the delay in the communication that is causing your “flipped” logic where the command is coming in after the motion starts. Also, are you using any blends in your motion? If so that changes the way that commands are interpreted, not sure it affects things like socket commands but I know it affects how IO is triggered.
If you’re able to implement it XMLRPC is a much faster protocol. We see 8-16 ms response times on RPC calls.
Thanks for your answer. I have a rather old robot, socket_read_string() is not support, neither xmlrpc. My version is 1.5.7849 Feb 6 2012.
I tried enter_critical / exit_critical, no succes. A sleep does help a bit, but there just doesn’t seem to be a way to guarantee robot movement finished before socket comms. Best result is using sync() and accept that order get reversed.
But it’s no real solution. I use 2 movel and require that those positions are actually reached. No blending, etc. The positions come from a PC. The urscript is just read 6 floats, go to that position, read another 6 floats, send an ascii string, move to 2nd position, repeat.
The send string relative to position doesn’t seem to have noticeble delays, images look great and we can do our measurements, it’s just the order reversal…
Does switching to a hard i/o solve this? It’s a lot of work.
Assuming that you’re working on a commercial product - developing for a software/hardware version that nobody can get hold of anymore doesn’t make a lot of sense… anything you do is not going to be entirely compatible with a CB3 robot. Can you get some time on a more recent robot for testing?
Unfortunatly, no. I would very much like that, but I can’t at the moment. So I was hoping someone, with a newer version, could tell me if they experienced something similar?
Anyway, all code should be 100% compatible with newer versions, we di not use anything special. Only thing that can be different is timing. Are there any known issues?
We decided to go with the i/o option. When work is complete I’ll report my results
Even though socket_read_string is not supported in CB1/1.5, you can still perform other socket read commands.
E.g. socket_read_ascii_float() and simply send "(1)" to the robot to verify receive…
Yes, you are right, but that would only increase delays and it would still be a “kluge”.
I’ve just finished the wiring and ran a new test. This time, I do not send a socket message, but simply set an output. The camera treats that as a trigger. Everything works fine now. Funny, that if I set the output to “On” the external output goes low and vica versa. Is it some setting? Luckily the camera can invert inputs.
But, the inversion remains interesting. Would like to have more clarity about that, but for now I can continue.
