Multiple fieldbus interfaces... how to specify which one in the signal declaration?

  • Hi all!


    * KRC2 + windows 95.


    I've always worked with only one fieldbus in the same robot cell, this means I've always had to worry about the number of input or output to declare a signal variable:


    SIGNAL myDeviceNetInput $IN[1]

    SIGNAL myDeviceNetOutput $OUT[1]


    That easily identifies that both variables are the first input and output respectively...


    But how should I declare a signal in another fieldbus given there are 2 fieldbus interfaces in the same cell?


    SIGNAL myDeviceNetInput $IN[1]

    SIGNAL myDeviceNetOutput $OUT[1]


    SIGNAL myProfibusInput $IN[1]

    SIGNAL myProfibusOutput $OUT[1]


    The proghbexpert_r5 2_en manual doesn't explain this...


    Maybe... is that in the iosys.ini? should I declare the IN and OUT ranges there?


    Thank you all!

  • AD
    • Helpful

    What KSS version?


    There are only a fixed number of $INs and $OUTs, and each one can only be assigned to one Fieldbus. Which $INs/$OUTs are connected to which Fieldbusses is controlled from IOSYS.INI (KRC2) or in the WorkVisual IO Mapping screen (KRC4).


    So you might dedicate $IN/$OUT 1-128 to FieldBus 1, and dedicate 129-256 to FieldBus 2, and so on. The one rule is, the assignments cannot be allowed to overlap.

  • Sorry Skyefire... I've put the "KRC2" tag and I thought it would be clearly visible. Long time since my last post here... And it had been before the interface change...


    I don't know exactly the KSS version, I only know it's KRC2 and it runs Windows 95... so an old guy...


    After working for a long time with KRC4... I did not remember iosys.ini... ^^¡


    That's it.


    Thank you for the extra details!


    :thumbup:8)

  • what...?



    you map physical I/O from whatever bus to a logical I/O

    logical I/O are I/O that robot programs can use, such as $IN[1..8192], $OUT[1..8192]

    you cannot have two fieldbuses mapped to same logical I/O


    at this point it does NOT matter what the physical I/O or fieldbus is connected, all programs can see are logical I/O. but working with I/O addresses directly is a bad idea. it may be tempting on a project with only a handful I/O such as in school lab. but that's about it....

    this is hard.....it is easy to make mistake... code is not documented.... messages are not commented... and this is a nightmare to maintain or troubleshoot. in one word - unprofessional.


    SIGNALS are simply aliases or "nicknames" for logical I/O. there is nothing to force you to create fieldbus specific signals.


    suppose you have $IN[1] mapped to some DeviceNet input.


    You can create bunch of signals such as

    SIGNAL DeviceNetInput1 $IN[13]

    SIGNAL ProfiBusInput1 $IN[13]

    SIGNAL EtherCatInput1 $IN[13]


    despite different name, they are all the exact same thing.... because they still point at one and same logical I/O ---> $IN[13]

    when input 13 is true, all of those signals are true

    when input 13 is false, all of those signals are false.


    Btw it makes no sense to name the signals like that. Signal names are supposed to indicate signals FUNCTION, not type of fieldbus, size or color of the wire, brand of sensor etc.


    For example:


    Code
    SIGNAL GripperOpen $OUT[1]
    SIGNAL GripperClose $OUT[2]
    SIGNAL GripperIsOpen $IN[6]
    SIGNAL GripperIsClosed $IN[7]
    SIGNAL ConveyorIsRunning $IN[4]
    SIGNAL ConveyorSpeedSet $OUT[17] TO $OUT[24]
    SIGNAL ConveyorSpeedAct $IN[9] TO $IN[16]



    This allows you to write entire program using signals only - without ever mentioning single I/O address. And THAT is the real goal. Program becomes READABLE and MAINTAINABLE.


    For example:

    1. WAIT FOR GripperIsClosed; generates message that is READABLE to everyone. messages like "Waiting for $IN[3174]" tell NOTHING about FUNCTION of mentioned input.


    2. when one of the I/O module fails or gets replaced, you don't have to rewrite whole program. just move wire from dead input or output to a spare one (or new module) and change SIGNAL declaration. that means change in ONE place rather than sifting through heaps of code and editing potentially many files.


    3. when program is deployed to another robot with different fieldbus and I/O configuration, you just map your signals according to connected I/O. your program still works - don't have to change a thing.


    4. if you are doing simulation (either in OL, OPS or on real robot that does not have rest of the cell connected yet), it is possible to replace file with SIGNAL declarations with alternatives such as BOOL etc. variables. Then you can control them either manually or using background process to make realistic tests - when GripperClose is set and GripperOpen is not, turn on GripperIsSet after small delay. Then you can test failure modes (for example actuator stuck, or input disconnected etc.) all without having complete cell in front of you.


    5. convenient bit level access, etc.


    Code
    SIGNAL ERROR_CODES $OUT[201] to $OUT[208]
    SIGNAL ERROR_CODE_Bit0 $OUT[201]
    SIGNAL ERROR_CODE_Bit1 $OUT[202]
    SIGNAL ERROR_CODE_Bit2 $OUT[203]
    SIGNAL ERROR_CODE_Bit3 $OUT[204]
    SIGNAL ERROR_CODE_Bit4 $OUT[205]
    SIGNAL ERROR_CODE_Bit5 $OUT[206]
    SIGNAL ERROR_CODE_Bit6 $OUT[207]
    SIGNAL ERROR_CODE_Bit7 $OUT[208]

    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

  • panic mode:


    Skyefire has answered exactly what I needed. (THANKS AGAIN SF!)


    If you read my original post again you'll notice I have not any problem with declaring signals.


    Indeed, when I have to maintain a code with $out[300]=TRUE code style I'd like to have a shotgun and the original coder nearby... this is really unprofessional and prone to error...


    Summarizing, IO numbers are from 1 to XXXX, and if you have multiple fieldbusses, the first one could be from 1 to 400 and the second one would be from 401 to whatever... and that is what is defined in IOSYS.INI.


    Without the iosys.ini part I could not imagine how to define the addresses that were in each fieldbus (i.e. the first input of each bus... clearly one will be 1 and the other one will be XXX).


    Thank you very much for the answer.


    :thumbup::)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now