Unit testing robot programs

    Coming from a software background, my expectation when writing any code is to have automated unit tests verify its behaviour. Because of this, it makes me a little uneasy that robot controllers don't support this "out of the box", and I would like to at least approach something like automated testing.

    I've seen a couple of posts on this forum bring this up (in particular see Verify all code paths and What is the best practice for reusing the same parts of a code in KUKA robots?), but I have no idea how this would be achieved in practice.

    My thinking is that it could be a generic test program that would reference a collection of library functions to execute, as well as input/output for those functions, and failure testing for the same. This could then be executed partially automatically in OfficeLite. My worry with this is then propagating passes and failures out of OfficeLite -- do you just display testing errors as messages?

    I'm less sure of how the submit interpreter could be tested, though I haven't researched OfficeLite/PLC interaction.

    Any guidance would be appreciated, but snippets of any testing code would be gold.

    For reference, I'm working with KRC4 8.5.7, and am in the process of installing OfficeLite 8.5.9.

  • Fubini November 22, 2023 at 4:32 AM

    Approved the thread.
    • Best Answer

    Each test case is going to need a unique test program. A function that receives integers can't be tested with the test program for a function that receives strings, for example.

    Messages are probably the primary method for getting test feedback, especially during input sanitization. Most of my library functions make heavy use of SWITCH/CASE statements and limit checking at the top of the function, with error messages thrown for unsupported values. Whether the program halts on that message or simply passes an error back up the chain is situational, but generally I don't want my library functions to have halting states.

    With KSS 8.x, it's now also possible to do simple ASCII read/write to files, which I've made use of in the past to test functions by generating a file of random values, which the test program would read in, feed to the function being tested, then log the results back to another text file. Or the test program might read in a file of input values, and another file of expected results, and run comparisons.

    Thanks for the advice SkyeFire, that gives me a starting point.

    What is your process like for testing submit interpreter code? For the system I'm working on, the submit interpreter is a quite convoluted state machine, for which I would usually do some kind of behavioural/black-box testing if I were working on a different system.

    Or more generally, do you know if there is a way to automate signals into OfficeLite?

    i'm following this topic closely as i am equally interested in this. Time has been constrained so i have not gotten around to do something universal yet, but i'm hoping to develop somekind of helper tools to alleviate code testing sometime in the future.

    Currently i often end up writing specific testing programs that hammer logical code with diffrent test cases (random values, edge cases, faulty values, etc). I even sometimes if there is dynamic paths in a program chunk them out and test in a separate loop to verify functionality.

    One tip i would have is to not only test that good parameters work but also remember to verify that a faulty condition will not run.

    I often rely on alot of error handling in my code and it has saved me alot of trouble, but code may sometimes become lengthy.

    Quote from noclip8492

    What is your process like for testing submit interpreter code? For the system I'm working on, the submit interpreter is a quite convoluted state machine, for which I would usually do some kind of behavioural/black-box testing if I were working on a different system.

    In the old days, I would often link outputs (bits or 'words') to various states of the state machine, and/or to variables I could monitor in the CONFIGMON. These days, I might have the state machine log every state change to an ASCII file, plus time stamps and any other state data I thought relevant. Any such logging would need to be managed carefully (for example, only start logging on a trigger event, then end after X state transitions) to avoid overflowing log sizes. Also, the file-access commands are slow enough they may effect the "jitter" of the SPS, so that's something to be aware of.

    For OL, your connection options are a bit more limited. You could look into OpenShowVar (disclaimer: I've never used it, but others on the forum have quite successfully), or use EKI if you have that installed, to send logging/state data to another computer.

    I don't recall offhand if OL 8.x supports Ethernet/IP, ProfiNet, or EtherCat (I haven't used OL since KSS 5.6), but if you have any of those, I would suggest looking into CodeSys. It's basically a software PLC, and the free "trial" version is basically fully feature-complete, but will only run two hours before requiring a reboot. I've had good luck running it with all the aforementioned bus protocols, and it has some nice tools for building GUI-HMI front ends (which I haven't tried).

    I also know there are some open-source implementations of EtherCat in Python and other languages, though I haven't used any of those.

Advertising from our partners