RSI $SEN_PINT variable not updating

    I have a very basic RSI setup to test out how to use KRL variables over Ethernet. In this instance I am trying to use the $SEN_PINT variable to send single digit integers from the KRL to the test server. I have my RSI configured and data is exchanging but when I change the $SEN_PINT variable in the KRL program, the value is not being sent over RSI to the test server. The variable does change in the KRL program because an IF statement doesn't work when I manually change it, but I don't see these changes communicated in RSI. I have hooked up a monitor to this variable as well but this also doesn't show any changes (however this could be due to me not using the monitor correctly)


    My setup is as follows:

    KSS version: V8.3.22

    RSI Version: 3.3.5

    controller type: Kuka C4

    robot type: Kuka KR16-2


    My RSI Context:

    My RSI Ethernet Config:

    My KRL program

    What I see on the test server

    Code
    <Rob Type="KUKA">
<Senpint>0</Senpint>
<Digout o1="1">
<IPOC>4181589</IPOC>
</Rob>

    Thanks for any help!

    Edited 2 times, last by Divvet ().

    Well, after adding the signal to the Monitor, you want to see if there's a difference between the SEN_PINT and the ETHERNET object outputs.


    There should not be any way for the $SEN_PINT to not reach the SEN_PINT object -- if it's not, then we have a very strange issue to debug. If $SEN_PINT reaches the SEN_PINT object, then the issue lies in the config of the ETHERNET object.

    Ok makes sense! I wont be in front of the robot until tomorrow, possibly Monday so I will update when I do. Thanks for now!

    Morning,


    So... I have the monitor working correctly and think I have spotted the problem, but not sure why its happening. When I set the SEN_PINT variable to "1", it instantly changes back to "0" (See RSI Monitor below). I don't think this is typical behavior?


    Actually I think I may have figured this out, just working on the required changes. Essentially I have been using the RSI Test server to just echo the RSI requests. I am guessing it is echoing back 0 values to the variable so it's instantly changing from 1 to 0. Will update when confirmed.

    Getting closer to resolving. What I stated above seems to be correct and I have made changes to my code, however I have the problem now where the variable keeps switching back and forth between 1 and 0 when changed (Shown below in the section of the logs)


    Code
    [2022-03-21 13:17:18,370] DEBUG    source.src.RSIRI.server       get_robot_data() 80 {'Senpint': '1', 'IPOC': '2839674'}
[2022-03-21 13:17:18,370] DEBUG    source.src.RSIRI.server           send_reply() 92 {'Senpint': '1', 'IPOC': '0'}
[2022-03-21 13:17:18,374] DEBUG    source.src.RSIRI.server       get_robot_data() 80 {'Senpint': '0', 'IPOC': '2839678'}
[2022-03-21 13:17:18,374] DEBUG    source.src.RSIRI.server           send_reply() 92 {'Senpint': '0', 'IPOC': '0'}
[2022-03-21 13:17:18,378] DEBUG    source.src.RSIRI.server       get_robot_data() 80 {'Senpint': '1', 'IPOC': '2839682'}
[2022-03-21 13:17:18,379] DEBUG    source.src.RSIRI.server           send_reply() 92 {'Senpint': '1', 'IPOC': '0'}
[2022-03-21 13:17:18,382] DEBUG    source.src.RSIRI.server       get_robot_data() 80 {'Senpint': '0', 'IPOC': '2839686'}
[2022-03-21 13:17:18,382] DEBUG    source.src.RSIRI.server           send_reply() 92 {'Senpint': '0', 'IPOC': '0'}
[2022-03-21 13:17:18,385] DEBUG    source.src.RSIRI.server       get_robot_data() 80 {'Senpint': '1', 'IPOC': '2839690'}
[2022-03-21 13:17:18,386] DEBUG    source.src.RSIRI.server           send_reply() 92 {'Senpint': '1', 'IPOC': '0'}

    I haven't quite worked out if this is my code causing it yet, so I was wondering if anyone knows from a controller perspective why this would happen?

    After some further testing, it definitely appears that the controller is re-setting the value after the first RSI cycle. It goes:


    Cycle 1: Controller: Sends SEN_PINT=1

    Cycle 1: Client: Receives SEN_PINT=1, Echos back SEN_PINT=1

    Cycle 2: Controller: Sends SEN_PINT=0

    Cycle 2: Client: ReceivesSEN_PINT=0, Echos back SEN_PINT=0

    Cycle 3: Controller: Sends SEN_PINT=1

    Cycle 3: Client: ReceivesSEN_PINT=1, Echos back SEN_PINT=1

    Cycle 4: Controller: Sends SEN_PINT=0

    Cycle 4: Client: ReceivesSEN_PINT=0, Echos back SEN_PINT=0


    The KRL program is simply:

    Edit: picture of the RSI monitor

    HELP PLEASE! :loudly_crying_face:

    Edited once, last by Divvet ().

    I always seem to figure something out after right after I post. I just removed the MAP2SEN_PINT from my RSI flow and the SEN_PINT value stays stable.


    This begs the question, in my current setup I have SEN_PINT going to the input 1 of Ethernet object and MAP2SEN_PINT in the output 1, both with the same XML tag in the Ethernet config. The idea was that changing the value in the KRL would send the value into MAP2SEN_PINT.

    The problem I have, is that RSI is setting MAP2SEN_PINT to 0, the same time as SEN_PINT is changed in the KRL program. I thought about seperating these in the ethernet config to senpintIn and senpintOut but the problems I have then is by default RSI is sending 0 values to senpintOut. So when my KRL program sets SEN_PINT to 1, the RSI is setting it back to 0 before it has a chance to update its value.


    How do I overcome this?


    Hope that makes sense!

    Edited once, last by Divvet ().

    You need to implement a handshake of some kind, and maybe some sort of single-point control. Say, $SEN_PINT 1 is only written by your KRL, and $SEN_PINT 2 is only written by the RSI program. But both programs read both variables. Then each one is used as a send/receive confirmation so that the program with "custody" of the variable can change its state.

    Ah right ok, that would make sense as its two programs working in parallel. I think I was over estimating what RSI does but I am guessing a lot of checks needs to be implemented manually. I will try this and see what happens.


    Thank you for the help and putting up with my rambling! :grinning_squinting_face:

    Well, your original program has two separate parallel tasks both writing to a shared global resource, in a non-synchronized fashion. Collisions or strange "spikes" are inevitable.


    RSI and KRL have the same "priority" level when accessing global variables. Since the various Interpreters in the robot are run on a scheduled multitasking system, there's no way for both processes to access the variable at the same time, and so KSS does not deconflict them (or, rather, the deconfliction is inherent in the scheduling). However, from the outside looking in, you would see the kind of results you've been observing.


    RSI and KRL give you a lot more low-level control than many robot languages, but the price you pay is that you have to manage all these "conflicts".

Advertising from our partners