# Sync movement to TCP/IP message **URL:** \ **Category:** Robot Communication\ **Created:** [June 7, 2017, 3:19pm UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859 "2017-06-07T15:19:17Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![mvrooij](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mvrooij/32/2151_2.png) [@mvrooij](https://forum.universal-robots.com/u/mvrooij)\ **Post date:** [June 7, 2017, 3:19pm UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/1 "2017-06-07T15:19:18Z")
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?). Any tips are welcomed and appreciated! ---
**Author:** ![anon90783502](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@anon90783502](https://forum.universal-robots.com/u/anon90783502)\ **Post date:** [June 8, 2017, 6:56am UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/2 "2017-06-08T06:56:28Z")
Hello, 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. ---
**Author:** ![mvrooij](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mvrooij/32/2151_2.png) [@mvrooij](https://forum.universal-robots.com/u/mvrooij)\ **Post date:** [June 8, 2017, 3:46pm UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/3 "2017-06-08T15:46:48Z")
Hi, 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? We’re nearly there 🙂 ---
**Author:** ![mbush](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mbush/32/76_2.png) [@mbush](https://forum.universal-robots.com/u/mbush)\ **Post date:** [June 8, 2017, 11:04pm UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/4 "2017-06-08T23:04:17Z")
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. ---
**Author:** ![mvrooij](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mvrooij/32/2151_2.png) [@mvrooij](https://forum.universal-robots.com/u/mvrooij)\ **Post date:** [June 9, 2017, 7:55am UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/5 "2017-06-09T07:55:56Z")
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. ---
**Author:** ![ajp](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/ajp/32/471_2.png) [@ajp](https://forum.universal-robots.com/u/ajp)\ **Post date:** [June 9, 2017, 8:39am UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/6 "2017-06-09T08:39:24Z")
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? ---
**Author:** ![mvrooij](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mvrooij/32/2151_2.png) [@mvrooij](https://forum.universal-robots.com/u/mvrooij)\ **Post date:** [June 9, 2017, 9:14am UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/7 "2017-06-09T09:14:00Z")
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 ---
**Author:** ![jbm](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/jbm/32/614_2.png) [@jbm](https://forum.universal-robots.com/u/jbm)\ **Post date:** [June 9, 2017, 11:34am UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/8 "2017-06-09T11:34:30Z")
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… ---
**Author:** ![mvrooij](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mvrooij/32/2151_2.png) [@mvrooij](https://forum.universal-robots.com/u/mvrooij)\ **Post date:** [June 9, 2017, 2:18pm UTC](https://forum.universal-robots.com/t/sync-movement-to-tcp-ip-message/859/9 "2017-06-09T14:18:18Z")
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. Thanks for all the replies.