IO problems KRC1

    Hi.

    I'm trying to revive a KR 15 L16/2 KRC1 KSS 2.3 with no documentation or electrical schematics, so I'm a bit lost.

    I'm having a problem with the Fronius solding station, when I turn on the station, it keeps feeding wire nonstop, so I'm trying to diagnosticate the problem.

    Starting from a possible software problem, I took a look at the IOSYS.INI file and found something concerning, I'm attaching the file in txt.

    As you can see, the DeviceNet, the one that goes to the Fronius station, is ocupying the bits 1 to 32.

    The PROFISL is also located there, so I don't know if that can be an issue.

    I also took a look at the config file and found multiple signals declarations in the ArcTech technologies in the same adress, I'm concernt about that too.

    After confirming if there's any problem in the software, I'll go and take a look at the Fronius station, but I want to make sure that there's no dumb error here with an easy fix.

    Also, there are many other signals without maping, I'm still trying to map everything, this cell is a chaos, but I think I got enough for now.

    Thanks in advance.

    Your ProfiSL is not active. Look at the DRIVERS section of IOSYS.INI:

    Code
    [DRIVERS]
MFC=0,mfcEntry,mfcdrv.o
DEVNET=2,dnInit,dndrv.o

    Only the drivers listed (and not commented out) in this section are "active". Settings for inactive drivers are ignored.


    The signal declarations in the ArcTech are probably just ways to give names to those I/O addresses, to make the code easier to use. Something like:

    Code
    SIGNAL WireFeedOn $OUT[10] ; declaration -- assigns name to $OUT

WireFeedOn = TRUE ; turns on $OUT[10]
$OUT[10] = FALSE ; turns off $OUT[10] -- no conflict

    So those "overlaps" in the I/O are unlikely to be a problem. In the above example, you can control $OUT[10] either directly, or by the user-friendly name.

    In your case, I'm guessing that one of the WF outputs (10-13) is "stuck" True, causing your wire feed to keep going.

    Quote from SkyeFire

    Your ProfiSL is not active. Look at the DRIVERS section of IOSYS.INI:

    Didn't know that, thank you, one thing less to worry.

    Quote from SkyeFire

    So those "overlaps" in the I/O are unlikely to be a problem. In the above example, you can control $OUT[10] either directly, or by the user-friendly name.

    I understant, I'll leave it like that, I suppose it has to work since it worked a few years ago and no one could have changed that by accident.

    Quote from SkyeFire

    In your case, I'm guessing that one of the WF outputs (10-13) is "stuck" True, causing your wire feed to keep going.

    I would like to know how to check that, because when I go to the outputs and toggle the outputs 10 and 13, that changes nothing, so not sure if it's sending the signal anyway or if there's another problem.

    The signal goes through DeviceNet to a BECKOFF DeviceNet and then to a RS485 or RS422 pheriferic that connects to the FRONIUS station, so no idea how to see what signals are being turned on.

    Last question, is there any problem with having ArcTech 10, 20 and 50 installed in the robot? I find that quite odd to have more than one, I assume each one has a function, but I'm worried that could cause some problems.

    After checking that, I think I will be calling FRONIUS so they can check the wiring.

    Thank you so much.

    Quote from BOTja

    I would like to know how to check that, because when I go to the outputs and toggle the outputs 10 and 13, that changes nothing, so not sure if it's sending the signal anyway or if there's another problem.

    Sorry, I was incorrect. I'm basing this on your screenshot:

    image.pngAnd guessing that WF+ is Wire Feed Forward, while WF- is Wire Feed Backward. I'm further guessing that there are two of each to support having multiple weld guns with multiple wire feeders on the robot. So I would check $OUT 10,11,15, and 16 and see what they're doing.

    You could also try a quick program like
    FOR Counter = 1 TO 32
    $OUT[Counter] = FALSE
    ENDFOR

    That will force off all the outputs to the Fronius. If the wire keeps feeding, that suggests one of two possibilities:
    1. Something in the robot SPS is turning the wire feed output back on -- scan the outputs from 1 to 32 and see if any of them are still on
    2. A wiring issue in the wire feeder

    Quote from BOTja

    Last question, is there any problem with having ArcTech 10, 20 and 50 installed in the robot? I find that quite odd to have more than one, I assume each one has a function, but I'm worried that could cause some problems.

    I never used ArcTech very much, but if I recall correctly, those aren't version numbers. Instead, each Axx module set controls a different feature of ArcTech. So there should be no conflict between them.

    Thank you SkyeFire , I'll monitor the outputs and then check the wiring, I wanted to check out a possible configuration error with the signals.

    Although I find it pretty odd the way signals are declared, it seems like when an output is activated, multiple orders are sent to the solding station, but I will assume it works and move on to a wiring problem.

    Quote from BOTja

    Although I find it pretty odd the way signals are declared, it seems like when an output is activated, multiple orders are sent to the solding station, but I will assume it works and move on to a wiring problem.

    Like I said, it could be something in the SPS, triggering multiple signals off of one Although KUKA doesn't usually do things that way, they rely on subroutine calls to trigger logic cascades. But to eliminate that possibility, another test would be to temporarily halt the SPS and then try turning all the $OUTs 1-32 False. With the SPS inactive, you should be guaranteed manual control over those $OUTs with no conflicts.

Advertising from our partners