KSS13012 "<SYS-X44> Error during ECat stack initialization [NetworkResponse () no Network Response]"

    Hi

    I read Panic Mode response on this topic. What means that bus is dead? As configuration or phisicaly?

    I have EK1100 with EL1008 and EL2004, ended with EL9010, KRC4 K8.3.18.

    Configuration is well done but not assigned yet I/O signals, mapping not yet realised. Could be this the reason of message error?

    EK1100 leds are lighten, 24 VDC connected, and Ethercat cable goes into X44 on CCU.

    ""KRC4 controllers use EtherCat for most things (there are several buses). and EtherCat has some nice things but one of the issues (at least in KUKA implementation) is that if you add or remove node from one of EtherCat buses, that bus is going to be pretty much dead. Even devices that were working fine before will no longer work simply because you connected one more node (or disconnected). once the bus is dead, you will see messages telling that one or more of previously working devices cannot communicate any more. in your case you connected something to an existing bus and transport of messages stops because they don't know which way to pass the data around.to make it work with you MUST makes sure that physical connections and configuration match - at all times. KRC4 does not allow hot plugging or pasivating of EtherCat devices.so you need to use WorkVisual to add new devicethan should make KEB bus happy (interface X44). it still remain to be seen how are you going to use them (if KUKA options support more than one force sensor).""

    What means you need to add new device and make KEB bus happy?

    Thank you

    the only way any EtherCAT bus in KRC is going to be ok (working) is that software and hardware configurations are matching.

    as soon as one (or more) of connected devices (hardware) are added or removed from the bus, or get replaced with a different device or get replaced with same device but with settings that are not matching the original device, the entire bus is dead. in that case robot is not going to be "happy" and will "complain" about the changes.

    Example, one of bus networks has 3 devices (connected as A-B-C) and all three are working.

    Then user starts messing with the system...

    Example 1:

    User swaps order of two devices, making physical changes to topology to something new like A-C-B. since that topology does not match configured topology A-B-C, robot complains and that entire bus is dead - even communication with the other devices is broken so you get not only faults about B and C but also about A (because entire bus is kaput and no communication takes place - all devices are seen as faulty).

    Example 2:

    User starts messing with the working system and only replaces one of the devices with another product. So instead of expected A-B-C, robot now sees A-B-D or A-D-C or D-B-C. since none of those cases match configured topology A-B-C, robot complains and again entire bus is dead, none of devices are communicating, even the ones that remained the same (and in same place on the bus).

    Example 3:

    User starts messing with the working system and only replaces one of the same device but with different settings. So instead of expected A-B-C, robot now sees A-B-C'. again that does not match configured topology A-B-C, robot complains and again entire bus is dead, none of devices are communicating, even the ones that remained the same (and in same place on the bus).

    Example 4:

    User starts messing with the working system and removes one device so that bus is now just A-B or A-C or B-C. Again that does not match expected A-B-C and entire bus is dead...

    Example 5:

    User starts messing with the working system and physically connects additional device. Regardless where on the bus that new device appears, robot will sense it a different topology from one that is configured and entire bus is dead.


    Are you starting to see the pattern here? You can literally kill the bus (and stop production) by merely plugging in some random device to the end of the bus.

    To fix this you need to make sure that devices physically connected to the bus and devices configured in WoV:

    a) match (same product, same brand, same type, version etc.)

    b) have same configuration

    c) are connected in exactly the same order

    The same applies to other EtherCat networks (control bus etc).

    In case of drive packs (KPP/KSP) one can replace one product with new device (or compatible one from ANOTHER controller) and KSS will detect the change and as long as they are compatible, it will automatically update the configuration so that new product is used. After that (reboot required) one can go ahead and replace the next device etc.

    But one cannot simply swap two KSPs in the same cabinet (for testing purposes for example) even if they same type (20A versions for example). KSS will see the change but it is not sure what user has in mind so it refuses to automatically update config - maybe the drives have swapped places OR maybe the drives are in same places but there is wiring error etc. hence recovery in this case (or when multiple drive packs have been exchanged at once) is manual.

    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

Advertising from our partners