Editing a background Task in RS results in System Failure?

RobotStudio
1

Any Ideas on the following?

I have a multi-move system with two motion tasks, and a background task handling PLC type functions and low latency stuff.

When in RS and online, if I open any rapid modules for the background task; the controller at any point can go into system failure.

It could be instantly as soon as I select the module, 30 seconds later, or a few minutes…

To recover from the crash I need a full “I” restart.

  • Originally this program was a “static” type, but I’ve changed it to normal so can’t attribute it to that.
  • Task in background to motion task 1, and there is very little at all; actually only running at 20 Hz.
  • I have got to the point of error handlers for every function attempting to track It down; nothing…
  • No issues running the robots- I just can’t edit the task.
  • It can be any line of code, or module. As soon as I select a line with the mouse the failure can occur.

(RS and Robot Ware RS6.08 btw)

2

Not quite so sure, but how is the task configured? Normal, semi-static or static? Maybe it needs to be normal until you have finished debugging and have solid code.

3

Is there a reason you are running the task behind a Motion Task?

For your background task it is presumed you have set Task_in_foreground to motion task1.
From the system parameter manual:
Task in Foreground contains the name of the task that should run in the foreground
of this task. This means that the task for which the parameter is set will only execute
if the foreground task is idle.

Try setting the background task’s parameter Task in foreground empty.

4

Is that task executed with the “safety” flag activated? If this is the case, if the task stops the system will get a sysfailure.

Anyway, its a strange behaviour. It could be related to the follow program pointer feature, try disabling it before you open that module.

Have you tried to use a previous version of RS? I had problems with the latest versions of RS so I currently use RS6.03 sometimes.

5

Thanks for your comments

The task is has been changed to a normal task for quite a while, but possibly there are some “static” remains from being created as a static. So I could try created a new task from scratch I guess.

No safety flag is attached to this task. I possibly could revert rw, but I’m currently using collision avoidance as a backup and asymmetrical zones to squeeze everything out of the production rate.

Yeah, the task is in the background to Rob_1; but RS seems to make you select one motion task in the foreground if the additional task is of type normal.

I think I might try editing a backup offline and then uploading; that should tell me if the route cause is the controller or RS.

6

Often times when I need to edit a background task I will work from a fresh backup, to ensure that no data is lost. Then do a restore, so that as far as the controller knows, it was always like that. One thing to be sure of though, if the module is automatically loaded, make sure you overwrite the module in the directory from which it will be loaded with your changed module.

7

Here’s the CAB_TASKS and MECHANICAL_UNIT_GROUP sections of a SYS.CFG file from a system that has a number background tasks. None of them have a task in foreground.

SYS:CFG_1.0:6:0::

CAB_TASKS:

-Name “T_A1B1” -Type “NORMAL” -UseMechanicalUnitGroup “G_A1B1”
-MotionTask

-Name “T_A2B2” -Type “NORMAL” -UseMechanicalUnitGroup “G_A2B2”
-MotionTask

-Name “T_MON” -Type “STATIC” -TrustLevel “SysHalt”
-UseMechanicalUnitGroup “G_A1B1”

-Name “T_POS” -Type “STATIC” -TrustLevel “SysHalt”
-UseMechanicalUnitGroup “G_A1B1”

-Name “T_GEN” -Type “STATIC” -TrustLevel “SysHalt”
-UseMechanicalUnitGroup “G_A1B1”

-Name “T_AUTOBACKUP” -Type “NORMAL” -UseMechanicalUnitGroup “G_A2B2”

MECHANICAL_UNIT_GROUP:

-Name “G_A1B1” -MechanicalUnit_1 “Unit_A1” -MechanicalUnit_2 “Unit_B1”
-UseMotionPlanner “motion_planner_1”

-Name “G_A2B2” -MechanicalUnit_1 “Unit_A2” -MechanicalUnit_2 “Unit_B2”
-UseMotionPlanner “motion_planner_2”