Sending/Receiving string in Submit Interpreter

    I needed to send and receive strings between robot and Keyence 3D vision sensor for Bin-Picking. I often send the trigger scan signal as soon as robot is outside the container area so that sensor controller has enough time for the calculation of the next part(s) to pick during the time robot is doing other jobs like placing in the machine etc. When robot is back in Home position it will request the calculated next pick-positions from sensor.
    This time because of a very small cycle time robot needs to obtain the next data from vision sensor as soon as possible in advance for background calculation during other jobs. I have created a state machine in a .sub file for background communication using submit interpreter.
    Here is my problem:
    Each time a string should be written in buffer strBuf[] but the buffer is always empty after the command is run.


    Running the same program with robot interpreter works fine but at cost of time(up to 2.5 Sec), but by using a submit interpreter:



    My first thought is, it needed more time to perform this than cyclic time submit interpreter allows so no string is received after executing KeySendString(strBuf[]). Is there a way I can get this done correctly?
    Thanks

    without seeing more code cannot tell much.



    but why don't you use one shot to call those subs? Submit runs continuously and same state can be processed many times, potentially corrupting data.

    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

    As Panic said, we'd probably need to see the SendString and RecvString routines. And get a better idea of the overall context -- what communications are you using between the KRC and the Keyence? For that matter, what generation KRC and KSS version?


    My gut feeling is that Panic is right -- as the SPS loops infinitely, that state machine may simply be repeating much too fast. You could test this by creating an array and having each step of the state machine record StrBuff to the array, for post-mortem analysis. Or, try temporarily adding a decent WAIT SEC delay (maybe 1sec?) to each state of the state machine and live-monitor the State value and the StrBuff value to see where/when the string is being cleared.

    another problem is the way FSM is structured - there is absolutely NO confirmation that operation is complete and FSM just blindly increments state regardless if step/state is completed or not. that is NEVER a good idea. no wonder you get different results when this is run in another interpreter.

    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

    Oh my bad, I forgot to mention: KRC4 and KSS 8.3.2


    I used EKI for the communication. Confirmation if each operation is complete was implemented in each state where necessary and many more. Having many LOC I tried to remove ones that are not particularly related to my question. SendString and RecvString routines were included to show where the string was later used in the code and the execution never reached any of them when I began using a variable and Msgnotify() to follow it. In this case I could only check the content of strBuf[] after the line SWRITE executed, and it was empty. If it is done hard-coded way by writing a dummy string directly in the routines it worked. So I thought the problem is the SWRITE line.
    I can not use Multisubmit because the version does not meet the minimum requirement for it. I will surely try what you guys already suggested on Monday. Thanks a lot.

    yes that is a very old 8.3 version. meanwhile several things got improved and KSS8.3 family is up to some 40+ releases.
    since your KSS license is for "KSS8.3" upgrade to newer 8.3 release would not brake that agreement.


    In fact same applies to all software, including tech options - check your license stickers inside cabinet. They all refer to major version only. If upgrade is to another major version, Kuka will want $$$.



    personally i would:
    1. make full backup (archive, KRCDiag and HDD image).
    2. in your computer install 7zip as it allows reading/extracting from WIM files
    3. get newer KSS8.3 version, as i recall KSS8.3.15 or higher is needed for MultiSubmit
    4. install upgrade
    5. test if everything is ok (Everything should work after KSS upgrade)
    6. install MultiSubmit (just contact KUKA).


    I would expect KUKA to be supportive:
    If you do it right, everything works, no license breach and life is good.
    If you mess up, you need to restore it to where you started from (Kuka still made a sale of a USB recovery stick or get to dispatch service tech to fix it in which case they still make money).

    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

    Like 1

    This is a very good idea, Panic Mode. Thank you. I had wanted to make use of the Multisubmit on our test cell for a while now but our versions did not permit it. I will go through those steps and upgrade. While waiting for the approval to do so, I would like to ask if there is any difference between using MultiSubmit or calling various .sub files from the main sps.sub.

    [size=2]of course there is a difference....[/size]


    [size=2]they all run asynchronously, .. but there are differences...[/size]


    [size=2]main SPS is the only SPS that can use motion instructions (async external axis). extended submits cannot do that.[/size]
    [size=2]main SPS is needed for proper KRC operation (tech options add their code here), extended submits are completely yours.[/size]
    [size=2]main SPS calling subprograms means fragmenting of scope. same happens in robot programs too. just try to motion step backwards out of subprogram.[/size]
    [size=2]main SPS should not have nested loops, delays etc. you are welcome to use them in extended submits.[/size]
    [size=2]etc.[/size]

    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

Advertising from our partners