KRC2 connecting to Fronius

    Hi,

    I have some experience with KRC4 controllers but have been tasked with commissioning a welding cell consisting of...

    - KRC2 controller with v5.4 software

    - ArcTech 2.3

    - Fronius TPS 4000

    - Beckhoff 5250 DeviceNet bus coupler with...

    1x KL1408 8-ch digital input

    2x KL2408 8-ch digital output

    1x KL6021 RS-485 interface card


    Apparently the robot was serviced but it was noted by customer that they removed the RS-485 'slice' from the bus coupler and have implemented a simple entry into the IOSYS.ini to communicate to the input and output slices. So, when I arrived, it has the input slice, then the 2 output slices (and then the bus terminator slice). The IO configuration has the DeviceNet driver enabled and the following...


    [DEVNET]

    INB0=10, 0, x1

    OUTB0=10, 0, x1

    OUTB1=10, 1, x1


    I understand this to mean that the signals are mapped to inputs 1-8 and outputs 1-16 and I was able to set/reset these output and witness the inputs from the IO monitor window.


    If I place the RS-485 slice into the last position of the bus coupler (end terminator is absolute last of course) without changing anything else, the mapping is completely lost. I can appreciate that some auto configuration from adding the RS-485 slice has occurred but I'm unsure of how this is being changed. Is there some manual configuration required?


    I've done some searching but can't find anything specific to the KRC2 with my hardware setup. I found this thread useful which tells me hardware wise I'm on the right track with a "DeviceNet over 485 " connection between the robot controller and welder but hope users like 'panic mode' and others can assist.


    So my questions are...

    What should my [DEVNET] look like in the IOSYS.ini ?

    Are there any other settings I need to check?

    I see all the Fronius signal names in the IO (prg number, strobe, etc, etc), is this standard config when ArcTech is implemented?


    Any example config files or general help is appreciated.


    Regards

    BigM

    Quote from BigM

    If I place the RS-485 slice into the last position of the bus coupler (end terminator is absolute last of course) without changing anything else, the mapping is completely lost.

    What is happening, specifically? "Mapping is completely lost" tells us nothing.

    There is a good possibility that this RS485 device adds some Diagnostic data to the bus coupler. This would explain why the IO-mapping is off.


    Did you try it without IO assignment in IOsys.ini?


    Does it work again once you remove RS485?

    @Skyfire

    Apologies, by "Lost" I mean that the Inputs and outputs that i can witness changing state in the first couple bytes in the IO monitor window no longer change state when I add the RS-485 slice and that it can not be seen anywhere in the 1-1000+ bit range. (2 buttons tied to the first byte of inputs are normally closed, and scrolling through the entire input range there are no inputs on).


    It makes me think that's why the Kuka service guys removed the RS-485 slice and kept it 'simple' with the 8-ch cards as this is just 1 byte per slice and not some unpredictable in/out byte arrangement that the RS-485 slice must present.


    The customer did tell me that the Rs-485 slice was in the first slot, and when reattaching it, i have added it as the last slot. I read nothing in the Beckhoff documentation about a specific order of adding the slices as to whether this changes the mapping of the slices as a whole.


    Florida,

    Yes, when I remove the RS-485 slice, it works again.


    Did you try it without IO assignment in IOsys.ini?

    No, but i will give it a try today.



    I would have thought that this type of setup, according to the thread I linked to in my original post, was almost a hardware standard for welding with a Fronius source taking into account the widespread use of both Kuka and Fronius that someone, somewhere may have a similar if not identical setup. I do understand that this is a controller running windows XP on the pendant so is quite old. It doesn't even have a floppy drive attached anywhere so not sure how i can archive to take backups.

    first of all did you check with Fronius how much of I/O are to be associated with your module?

    if i recall it is some 10-20 bytes in, and similar for out.


    and are you saying that DeviceNet is working (no fieldbus errors) and only the existing digital I/O are no longer responding


    well... thing is to figure out how the bus coupler arranges data from detected modules. it is very common that order in memory (I/O) does not correspond to physical order of modules. units that exchange large blocks of data are often mapped first because their IO blocks are whole bytes or words. then the signals from digital I/O may appear at the end of the block, even if they are physically closer to bus coupler.


    suppose RS485 unit takes 18bytes in and 12 bytes out. if mapping is as mentioned, that would cause your input signals to appear in byte 19, and your outputs to appear in bytes 13 and 14.


    and since you did not yet adapt mapping in IOSYS.INI, your existing digital I/O are now controlled by wrong I/O.

    you can try mapping your digital I/O to higher bytes such as:


    [DEVNET]

    INB0=10, 18, x1 ; if 18 bytes are for RS485 (bytes 0-17)

    OUTB0=10, 12, x1 ; if 12 bytes are for RS485 (bytes 0-11)

    OUTB1=10, 13, x1 ; this is the next one...

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Quote from panic mode

    [DEVNET]

    INB0=10, 18, x1 ; if 18 bytes are for RS485 (bytes 0-17)

    OUTB0=10, 12, x1 ; if 12 bytes are for RS485 (bytes 0-11)

    OUTB1=10, 13, x1 ; this is the next one...

    I agree with panic mode!


    The Devnet need to be changed a little bit:


    [DEVNET]

    INB0=10, 0, x18 ; if 18 bytes are for RS485 (bytes 0-17)

    OUTB0=10, 0, x12 ; if 12 bytes are for RS485 (bytes 0-11)

    OUTB1=10, 13, x1 ; this is the next one...


    if you want you can write every single byte instead of using the multiplier:

    INB0=10, 0, x1

    INB1=10, 1, x1

    INB2=10, 2, x1

    INB3=10, 3, x1

    etc.


    Reference:

    ;[DEVNET] DeviceNet on the KUKA MFC

    ; Entries in form 2 for driver dn2drv.o

    ; {address}=DeviceNet MACID

    and

    ; Form 2:

    ; {token}{offset}={address},{byte}[,{multip}]

    ;

    ; {token} INB, INW, INDW, OUTB, OUTW, OUTDW

    ; {offset} byte offset of robot IO System

    ; {address} address of a peripheral device (0..m)

    ; driver specific information, see descr. below

    ; {byte} byte offset at this peripheral device (0..m)

    ; Offset starts with 0 at the every device

    ; driver specific information, see descr. below

    ; {multip} creats n dataobjects of {token}

    ; Example:

    ; INW4=10,0,x2

    ; Two words of the peripheral device with address 10 and

    ; up from byte 0 are mapped to the inputs 33-80.

    Quote from BigM

    Apologies, by "Lost" I mean that the Inputs and outputs that i can witness changing state in the first couple bytes in the IO monitor window no longer change state when I add the RS-485 slice and that it can not be seen anywhere in the 1-1000+ bit range. (2 buttons tied to the first byte of inputs are normally closed, and scrolling through the entire input range there are no inputs on).

    Are there any error messages?


    If not, then your DN is working fine, it's just the mapping that's been disrupted. Unfortunately, the Beckhoff "sliced" I/O does not always have the I/O mapping match the physical arrangement. So it's possible (even probable) (As Florida and Panic have said) that the RS485 slice has taken up the first X bytes on that DN node, and bumped the digital I/O further down.


    The quick&dirty brute-force check would be to change (for example) INB0=10,0 to 10,1, then 10,2, etc, and keep doing it (with an I/O Reconfig each time) until the DN driver starts throwing errors. That'll tell you the new total number of input bytes on the Beckhoff node.


    The right way to do it would be to get the Beckhoff docs for that RS485 slice, which will state the number of bytes In and Out that slice adds to the node, and change your assignments accordingly. Or, look up how to use the Telnet tools in the KRC2 to query the Beckhoff node and have it report back how many bytes it has going each way.

Advertising from our partners