Would this be a good way to organize the program?

    Hi all,


    I probably will have to program some CSC8 robots without pendant, this makes it a little stranger as no operator will be able to reset the program if needed.


    Thinking about it and the best way to do it and being completely newbie with Stäubli, I've thought on using this strategy:


    Create a program that will start at boot, that program will have an infinite loop that will handle the emergency stop signal (used to reset it all), then I plan to create a parallel task for each part the PLC requires to process so I will be able to kill those tasks in case of an emergency stop (as a rude mechanism to make it possible to reset the programs):



    part0 and part 1 will have all the cycle to pick and place parts from A to B, with all the logics and conditions, I could add a kind of error signal to let the main program know everything is running fine and in case it is not, inform the PLC about it, but that would be the design.


    Does this look good to you?


    Thank you in advance.

    Hello Robtecnic,

    2 or 3 small things :

    - You can't use the Start() program in your taskcreate ! (You can use the Start only if this program belongs to a library)

    - Take the habit, when you have a quick loop like While/Endwhile, to add automatically a Delay(0) (for example before the EndWhile.

    - After the taskKill, you can wait that the task is dead (taskStatus...)

    - Same thing before the task create (a small taskstatus and you control that the task don't exist already)

    - diEmOK : Look about esStatus function

    - You need to add ==True when you control an Input (like diGoHome). If you work with SRS you have a Syntax control button.


    Better than Taskill (kill the task anywhere), you can use a bool variable to give an order to the task. I think in all Partx program you have a loop. Stop the loop whith your Bool and the task will be stop imselfe...an properly.


    There is different ways to use the tasks and mostly the movments. The best is to use one task for all the movment (to be sure that you can't send different trajectories in the same time (In this case, your robot will be totaly crazy :(). Use the main program to take the big job (like a small PLC include), and a second task to control the robot. In this case, it will be easy to add asynchonous fonctionnality !


    ...

    Have a good day.

    Great points Galet ,


    - delay(0) I guess to avoid collapsing the CPU in case of infinite loops without much to do inside.


    - About sending a bool to the task to get it stopped itself... how this works? I mean, I understand a task as a function (that restarts automatically) and in case that task is controlling movements, I should be capable to check the variable only after each movement and only if I check it manually there... Could you post a small sample about that?


    Thanks again!

    Quote

    delay(0) I guess to avoid collapsing the CPU in case of infinite loops without much to do inside.

    Yes. Remember that the main task (Started with the running of Start program) have only 10 to priority.

    Quote

    About sending a bool to the task to get it stopped itself... how this works? I mean, I understand a task as a function (that restarts automatically) and in case that task is controlling movements, I should be capable to check the variable only after each movement and only if I check it manually there... Could you post a small sample about that?

    When the controler receive an Emergency Stop, the robot is stopped (Power off), and normaly, the pointer of the "robot task" is stopped on WaitEndMove() or something similar (waiting function). If you kill directly the task, you loose the pointer synchronisation and you need, to restart, to reset the point's memorization (ResetMotion), controle the actual robot's position and send the new trajectory. If you control, the Boolean variable, you can prepare the restart before loose the pointer.


    Like all the robot, it's easier after a issue, to controle the restart rather than to close all and search the next trajectory.


    Best regards,

    Understood, in this case I can afford to just cancel the movements as the robots will have to move upwards till a vertical coordinate and then move home, where they will release the part to fall in a box.


    So, in case esStatus returns something different than 0 in the main task, I will call resetmotion (maybe not needed as the emergency stop will have entered) and then kill the movement task and wait till it has completely disappeared. And at last wait for the PLC signal to restart the program to go HOME...


    Thank you again!

    Quote

    I will call resetmotion (maybe not needed as the emergency stop will have entered)

    Emergency stop don't reset the movment memory. It's the reason why, after an emergency stop, you can restart from the same position.

    Quote

    Understood, in this case I can afford to just cancel the movements as the robots will have to move upwards till a vertical coordinate and then move home, where they will release the part to fall in a box.

    Yes, It's very easy with a scara robot.


    Have a good day...

Advertising from our partners