Latest version of RSI Config

    We’ve been playing with the latest version of RSI and finding the instructions lacking.


    During testing and while in MoveCorr state our robot times out (around 6 seconds) despite being sent data and pretty much crashes everything and needs restarting.


    Firstly regarding setup is anyone running in TCP?


    Does T1, T2, AUTO effect it?


    Do we need a real time system or can windows cope?


    Is there anything trick in setting up the RSIx file in WV that the examples don’t show?


    We are running the latest version of RSI on KRC4 8.5


    Many thanks for any help

    you are welcome


    but to get real help you still need to provide some facts.... such as actual version, actual message etc.

    version 8.5 is only major version. you did not mention RSI version at all.

    btw. "latest version" is relative and really means nothing, state the actual product version in full.


    message "timeout" is not clear either, full message is needed and in exact form.

    you did not post your code either and it is unclear if you ar using fast or standard RSI (4ms or 12ms RPI) and what did you do to trace the problem.


    you did not state how things are connected either. is the connection direct, using router or WiFi, if the network settings are compatible and conflict free. WiFi adds latency.

    then about your PC software talking to RSI - how exactly you are ensuring timing? Windows in not RTOS and standard timers are not good for anything below 30ms.


    and the list goes on and on...

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Unfortunately it’s the weekend and there’s a pandemic on so I don’t have access to every detail. I was just trying to get ahead during some down time.


    So if Windows is no good below 30ms then method of connection, version no, IPO_FAST etc are all irrelevant, no?


    What RTOS does everyone use then?


    FYI


    KSS01205 is the error generated, communication software is able to reply in microseconds and is our own, connected via Ethernet, set to 12ms. Runs for about 137 packets then falls over


    We are trying TCP rather than UDP


    They just updated out KRC4 to 8.5 and said they had updated the RSI to suit (all I have to go on I’m afraid)

    Yes and we striped down everything so windows could be at its best and 137 packets before error is the best result we’ve had.


    So we are faced with only a few remaining options:


    Can windows even do this for us?

    Do we revert back to UDP to speed things up that way?

    A more powerful PC or switch to RTOS?

    RSI is new to us and we are all working remotely with a lot of trial and error. It would be great to get some clear info as to RSI ‘s potential on windows before we waste any more time and money on it.

    Yes multi threaded etc ,


    We send/receive 137 packets before our data stream falls over and then at around 6-9seconds the error message is displayed and shortly after KSS crashes


    We have now had some success in UDP so we potentially think TCP was the issue which is a shame as we can make TCP much safer

    Well, the "timeout" error in RSI generally means that a packet failed to arrive within the required time window. RSI's timing requirements are rigid, and any packet that fails to arrive on time means that RSI has to fault.


    I would try running a Wireshark capture of the data stream and see what kind of timing jitter your packets have. Also identify which packet arrives late to cause the RSI fault.


    Another thing you could try is simply set up a test case with the PC and robot exchanging time stamps, to see where the delays are.


    Generally TCP/IP should work fine, unless you're sending massive amounts of data, or you have network issues. That's another thing WireShark might help you identify, whether or not you have retries going on.


    The way the failure keeps occurring around 137 packets is odd, though. That could be some kind of issue in your PC-side application, or you could have some background task in Windows that bogs down system resources at roughly that "heartbeat" rate. The quick test there would be to try shutting off the Windows firewall, and kill every background task and service possible. A "stripped" Windows installation can be very quick and stable, but most desktop installs tend to accumulate cruft over time. The next test would be to try running the test using a bare-bones Linux installation -- ideally, write something like a Python script that can be cross-platformed between Windows and Linux, so you can get an apples-to-apples comparison.

Advertising from our partners