What is the best way to test the code changes for industrial robots?

    Hello.


    I think all of you agree with me that compared to other applications (web pages, desktop applications, etc.) errors in a robot code are crucial.


    So, I have a question: how do you test your code? I am not talking about the simulated paths for a robot. Please, don't say that a manual testing is the only way :loudly_crying_face: Because it is time consuming and for me who works in the R&D department code changes rapidly.


    For the other programmable applications you can build pipelines and test your code changes in the cloud (CI/CD).


    Is it possible to do the same thing for industrial robots?


    As I understand, the problem is to build a robot code in the cloud because of the unknown compiler and specific functions.

    But maybe one of you used a real robot for that?

    I tried to write tests for my functions in the edge cases, but on a real robot it is still time consuming.


    So, in summary, my question is: what is the best way to test the code changes for industrial robots?


    Best regards,

    Aivaras

    there is only one true way to test it ... and that means using real robot. industrial robot is not a toy or a mere message on some screen, it can hurt someone and cause serious damage.

    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

    For now we are using KUKA robots. But my company wants to start testing some solutions with ABB robots.

    For now I just want to know if it is even possible because I do not think that it is an easy task, it requires a further investigation.

    I am happy that my manager finally sees how necessary is to properly test and refactor a code 😃 It is only strange to me how much manually work is needed in specialisation, which is responsible for reducing repetitive work.


    If we talk about motions, I have to admit it, I do not even trust the motions generated by simulators. But I do not think that it is a bad decision to use tests for something like the stability of cell work. For example, the robot is working as a state machine. And a basic test for that is to use wait sec * to imitate "work". The robot does not have to move at this state. What is expected from a robot is to go from one state to another.


    Another example could be a conveyor control. It does not require the motions of a robot, but it is easier to test it with a programming code than in the real life.


    In our case, we perform a lot of calculations inside the KUKA robot, using the functions INVERSE and FORWARD. Basically, for some cells we use a robot as a real time simulator. For safety reasons and in order not to repeat the same calculations, I test the work programmes at T1 mode for every single operation. We use the results of calculations for the generation of a final programme code which is also tested in T1 and only after that I use EXT mode for a manufacturing process.


    For some robotics solutions we are starting to use ROS, but it will not cover all our solutions.

    Quote from Aivaras Narbutas

    ... It is only strange to me how much manually work is needed in specialisation, which is responsible for reducing repetitive work.

    write modular code. write and test your subs and functions once and then you can use them as many times you like and on many projects.

    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

    Thumbs Up 1

    @Aivaras Narbutas

    according to your post #4 I would suggest: create your own robot


    You do not trust the (simulated) motion generated by the robot manufacturer.

    Why should they make two motion generation (one for real and second for simulation)? -> Waste of time and man power

    On the other hand you are using INVERSE and FORWARD

    Concerning motion I would expect that all robot mamufacurer know what they are doing


    Instead you are using ROS (and you do not trust ROS either)


    As panic mode mentioned:

    Quote from panic mode

    write modular code. write and test your subs and functions once and then you can use them as many times you like and on many projects.

    this is the way to do it

    Quote from Aivaras Narbutas

    I am happy that my manager finally sees how necessary is to properly test and refactor a code 😃 It is only strange to me how much manually work is needed

    If you want to do automated testing you have to do a lot of manual work before

    there there... lets not do anything rush.

    just imagine every unhappy user going after those who told them to read the manual or contact manufacturer :astonished_face: :winking_face_with_tongue: :winking_face: :smiling_face_with_sunglasses:

    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

    Most processes are too complicated to realistically simulate due to all external inputs and devices. You can't just simulate the robot, you'd also need to simulate PLCs, sensors, and physical items. That quickly becomes a tremendous amount of work and still doesn't give an accurate representation of the real world.


    The only way to make changes faster is to become a better programmer and to be able to quickly troubleshoot and fix problems.

Advertising from our partners