Why profisafe communication sporadically failed while Starting SyncMove

Mauclub

Sometime when we start a synchron move with command SyncMoveOn  ProfiSafe communication failed. It apears in aprox one of seven times and only while SyncMove. When we moved at same time both robots without SyncMove it doesn´t apear.
Why it is happen somtimes?

matti

update: We have 888-2 Profinet Controller/Device, so safety unit and I/O's to PLC are connected. Reason is quite likely not PLC or network but safety unit at robot side seems to quit service for 3-4 seconds in that situation. All I/O's on that unit are reset (undefined) for the same time and also safety input. PLC signal to other units than robot stay put. Problem occurs when welding with both robots (arc on or off)

Tompanhuhu

Is your cpu load at 100%? Any background tasks or loops without waittime? 
What is the profisafe SIL level and watchdog timeout limit?
I have seen similar issues with RecoveryPosSet instruction, do you use this? 

matti

CPU-Time is something between 70-100%  when error occurs. (How to reduce?). We have one automatically generated bg-Task:

>>TASK4: (tLtcBgTsk,,)
SYSMOD/user.sys @
which serves the Laser Tracker, but LTC is not in use when we tested.

Required performance level is d/e and we varied watchdog-time between 150 and 5000 ms without a effect on incidence of the error. 

Error occurs all 20-60 times when we check for it but always at the same position:

...

 ArcLStart rPosAkt\ID:=10,V100,smh,wld_h30n0\Weave:=wv_h30n0,fine,tool_w50022 \Wobj:=BT1\Track:=track_h\SeamName:="seam1";
  ArcL *\ID:=20,V200,smh,wld_h30n0\Weave:=wv_h30n0,Z10,tool_w50022 \Wobj:=BT1\Track:=track_h;
(->)  ArcL *\ID:=30,V200,smh,wld_h30n0\Weave:=wv_h30n0,Z10,tool_w50022 \Wobj:=BT1\Track:=track_h;
  ArcL *\ID:=40,V200,smh,wld_h30n0\Weave:=wv_h30n0,Z10,tool_w50022 \Wobj:=BT1\Track:=track_h;

...

Program counter and robots position are both on that line in interpreter in both robot tasks.

The error occures more frequently when arc is switched on which may point to some kind of time lapse in the process (weld guide is on and power source is watched, there is more traffic on network).

We also checked for inconsitencies in point positions for external axes and tool orientation - no result.

(manipulated position of axis, slightly unnormalized orientation)

matti

We finally figured out a solution for the problem.

Reason was, that we use SafeMove with safe in/outputs to stop robot movement and axis monitoring (speed, brake ramp). We have 2 robots and 6 external axis, so 18 in total on 1 controller. Additionally we have 2 background welding tasks running.

It seems, that the CPU-load is to big then to handle incoming requests from SafeMove then.

(IRC5 can handle 4 robots or 3 welding robots, so 18 axis in the latter case - that's what we have)

We had to drop axis monitoring and synchronous welding with multi-move is fine.