I assume you're using RSI in XML-over-TCP/IP mode?
There really shouldn't be any delay. RSI will query the server every 12ms, without fail. Any packet delays or losses will cause RSI to throw a fault.
if you are interested in verifying timing, simply use WireShark. it gets every message timestamped with high accuracy. in my experience the robot will send messages at defined interval (12ms or 4ms). the response to KRC from external system may vary and this is not because of channel but rather computation or processing on that remote end. delay here is what i would focus on as this can get RSI tripped...
I assume you're using RSI in XML-over-TCP/IP mode?
There really shouldn't be any delay. RSI will query the server every 12ms, without fail. Any packet delays or losses will cause RSI to throw a fault.
MoveCorr() was used to control robot motion. After the robot sends the position and time stamp to the host computer, and the relative offset sent by the host computer is received within 12ms. Will this offset be executed within 12ms this time or within the next 12ms？？
if you are interested in verifying timing, simply use WireShark. it gets every message timestamped with high accuracy. in my experience the robot will send messages at defined interval (12ms or 4ms). the response to KRC from external system may vary and this is not because of channel but rather computation or processing on that remote end. delay here is what i would focus on as this can get RSI tripped...
Compared with timing, I want to know the time from the host sending the offset position to the robot completing the offset motion. The robot uses the movecorr () command to control the robot motion
hmmm... it looks like your requirements are changing. i am not sure what you are really after.
using RSI you can send corrections to robot as well as read robot position. btw you can use fast option where RSI is operating on 4ms interval rather than default 12ms. but
so what exactly seem to be the problem? what is stopping you from doing what you want?
hmmm... it looks like your requirements are changing. i am not sure what you are really after.
using RSI you can send corrections to robot as well as read robot position. btw you can use fast option where RSI is operating on 4ms interval rather than default 12ms. but
so what exactly seem to be the problem? what is stopping you from doing what you want?
Choose IPO instead of IPO_ Fast, because in IPO mode, there is already a median filter to ensure the smooth motion of the robot.
Data acquisition: infrared camera captures moving targets
Motion compensation: control the robot motion through movecorr(). Realize the relative static motion between the robot and the moving target
Therefore, we need to predict the robot position according to the total delay time (acquisition time delay, data operation delay and robot motion delay)
so what exactly seem to be the problem? what is stopping you from doing what you want?
read robot position (continuously)
then when ready to do a motion:
start timer
issue motion command (or correction in case of RSI).
stop timer when reported robot position matches commanded value.
MoveCorr() was used to control robot motion. After the robot sends the position and time stamp to the host computer, and the relative offset sent by the host computer is received within 12ms. Will this offset be executed within 12ms this time or within the next 12ms？？
The robot completes the motion before the next communication cycle, if it is physically capable. If one sends RSI a POSCORR input of 100mm, the robot will try to complete that 100mm motion within 12ms, which will almost certainly fault the robot.
That's why it is incumbent upon the programmer to ensure that the RSI program does not receive impossible commands. It is also why RSI programs generally need to have internal PID controls and filters to "smooth" sudden input changes.
