Sys.WdTimer=1, background task hanging

[kmonroe023]

I'm having a weird problem with a Power Pmac running the latest version of the firmware (1.5.8.0). It seems that something is causing the background task to hang; Sys.WdTimer counts down to zero and everything on the PMAC stops. I've isolated the problem to one PLC that gets enabled when the machine is recovered after it has been E-stopped. Once the e-stop is cleared and power is re-applied, this PLC is run to enable all motors and run them to their 'home' positions, once that is done it disables itself.

 

Now for the strange part: this will only happen if the E-stop occurs while a motion program is running (in CS1). If the e-stop occurs while the machine is enabled (all motors on), but not running any programs, the machine recovers normally.

 

I've attached the PLC so you can have a look at it; nothing too complex here so I fail to see how this could cause the background task to hang, plus it works just fine any other time except under the conditions I discribed above.

 

I monitored Sys.WdTimer and Sys.BgTime, when plc8 is run, BgTime stops updating, WdTimer will count down and watchdog the system when it gets to zero.

 

When we estop the machine we just remove line power from the Geo DirectPWM drives, 24vdc control power to the drives stays active.

 

Thanks,

kmonroe

8 - plc8 fast homing.zip

[kmonroe023]

One other bit of information, the housekeeping PLC that handles machine recovery runs the small bit of code below right before it actually enables PLC8.

 

Ldata.coord =1; //deselect any cs1 transforms

tsel(-1);

call timer(0.25);

 

Could trying to disable transforms in a script PLC cause the watchdog faults? Coordinate System transforms are used while running the motion programs.

[Omron Forums Support]

After looking at your PLC, nothing seems particularly suspicious. The only thing that stands out to me is this one line:

 

jog4 = raisedPos;

 

I think that should be:

 

jog4=(raisedPos);

 

if raisedPos is a variable.

 

Also, there have been some issues in the past with older firmware versions wherein the following setting:

 

Sys.CpuTimerIntr=1 // Use internally generated clocks

 

can sometimes cause strange watchdogs.

[kmonroe023]

I figured out what was causing the watchdog faults; it was the tsel(-1) command I described in the post above yours. Apparently you can't use that command in script PLCs.

[maxvoxel8]

We had a sporadic WDTFault for a long time and I think I've traced it down to calling tsel1 in a PLC, but only when motion is happening. We are calling the ComputeNCTransform subprogram from a PLC, and it works most of the time, but reliably causes a fault only if a motion is being initiated at the same time as tsel1 is called. However since transformation matrix 1 is already active most of the time, I can hopefully just change it to

 

if(Coord[1].Tsel != 1)

tsel1

 

And avoid further WDTFaults.

[Omron Forums Support]

You can run tsel from a motion program by putting it into a subprogram and running that from the PLC with:

CMD"&1 CPX CALL {SUBPROGRAM NAME}"

 

If a motion program is running already, that may be an issue.

[maxvoxel8]

I know I can run it as a program, but the coordinate system could be disabled or already running a program and I still want to be able to update the work offsets.

 

CPX seems really useful though, I didn't know about it before.