KRC1 ArcTech A20 "Error Welding Controller"

Hello.
For the first I will check:

- the signals from Fronius comming to robot interface (I/O map), in input area from robot You see signals ?
- when You acknowleadge error on Fronius Led indicator on the front of Fronius will Disapear
- when You start to wire forward - after ACKNOWLEADGE ! - wire going out ?
- can You make gas test ?
- are You using welding through choosing JOBS or You send to robot all of parameters (amps etc ) before everyone welding point ?
I was not using any tech pack for welding, I just prepared interbus configuration ( keep in mind Fronius have few types of interfaces for example 96-bit input output or in my case 112- bytes input/output interface area), have You prepared NOT-AUS (E-STOP) ? Have You changed on Fronius controlling from internal to external
How You prepared start welding MACRO ? and STOP welding macro ?
Do YOU HAVE ANTYCOLLISION SENSOR signal in high value ?

I'm looking for YOUR reply.
Marek.

Check carefully signals group in config.dat for welding functions. I met that in some version arctech is set to give just pulse. Fronius need stable signals.

I'm not personally familiar with the A20 package. But my best guess would be that, upon starting a weld, the software is expecting a particular set of feedback signals from the Fronius, and for some reason is not receiving them.

I would start with a mass Grep search of the entire /R1 directory for any occurrences of "TPA20". Once I knew which line(s) of code triggered this error, it would be a matter of working backwards to the trigger conditions. Then set up an Oscilloscope tracing the signals involved, and perform a test weld.

Hm... doing a quick peek at an old copy of A20 I had in the archives, it looks like all error messages are generated in A20.SRC. None of the messages match your exact text, but I'm guessing that #5, "WeldControlFault," is the most likely culprit. Nothing appears to be setting the actual error number, so that 0 in your message is probably a red herring.
Going back further, that message only appears to be sent by TECH_STOP2, which... appears to be intended for stopping the weld during an E-Stop. Odd.
Okay, there's an interrupt that calls A20 with an INSTR value of 7 (which calls TECH_STOP2), which is triggered by $CYCFLAG[3], whose declaration is:

$CYCFLAG[3]=(($IN[FLT_NUM[1]]==I_WELD_FLT[1].STATE) AND ($IN[FLT_NUM[2]]==I_WELD_FLT[2].STATE) AND ($IN[FLT_NUM[3]]==I_WELD_FLT[3].STATE))

The FLT_NUM variables are obviously input numbers. The I_WELD_FLT variables appear to be some sort of configuration for the expected state of each of the related inputs. So my best guess would be that those config variables are part of the problem.

Skye ?
So this fronius lost E-Stop signal from robot ?
When I prepare test configuration of fronius with kuka on intebus I'm not using A20 tech pack, for tests fronius input E-stop I derive from Motor_On signal and there is no problem with interruptions with welding.
Marek

Well, I was incorrect. Inside A20, TECH_STOP1 is intended for handling any robot faults, like E-Stop. TECH_STOP2 is the subroutine that generates the message "WeldControlFault", and it is specifically for stopping operations if a fault occurs on the weld controller. And TECH_STOP2 is called by Interrupt 6, which is conditioned on $CYCFLAG[3].

Without more details of the original problem, right now my best guess is that TECH_STOP2 is being called due to some configuration error in the condition checks set for $CYCFLAG[3].