RPI for PLC side. Use "packetinterval" parameter of Function block. You can found parameter in instance DB of FB. If you using RPI less than 32 connection problems occured randomly. Because Siemens PLC is not powerfull CPU for Ethernet/IP
Posts by M.Ozkan
-
-
Quote
I have spoken with fanuc and they have said that its probably a problem with the LCCF block of Tia Portal. It seems that they have had more problems with this library of Tia Portal.
Tia libraries of Ethernet/IP working very well. You should make settings correctly in TIA program. Call program in Cyclic Interrupt OB. Use RPI >= 32 ms.
-
This problem has numerous causes. For example, if SmartHMI.exe stops working, it disconnects the KCP connection. If the PC restarts, the connection is disconnected. In case there is an issue on the Ethercat line, the connection is lost. If the PC cannot catch up with the vxwin cycle time, the connection is lost. The easiest method to identify is to take and examine the logs with KRCdiag.
-
Seeing a gap can have many reasons. Among these reasons, it can be related to the gearbox, RDW card, driver package, motherboard, parameters, or even cable problems. Based on my previous experiences, even though we replaced the gearbox, the gap persisted due to an issue with the RDW card. If you are confident about the mechanical condition, you should systematically check the other components.
-
I have similar problem with messages:
- Emergency Stop inoperative
- KSS12041 Ackn.: Position comparison robot controller <-> safety controller not possible.
- KSS15085 Ackn.: Controller in failsafe state.
- KSS01205 Ackn.: Zyk_PosIPO cycle time.
I take KRCDiag and examine of logs and I found some logs:
ERROR iHnf1 22:21:22.969 : Cycle 17843. Wrong cycle timing. Delayed for 32015 us (Min: 6000 us, Max: 18000 us). Source: PLC cycle watchdog
ERROR iHnf1 22:21:22.969 : Cycle 17843: cycle time violated (source: 703).
ERROR iHnf1 22:21:22.969 : InterfaceSetTimingViolationFailureState(): Timing-violation SOS_FAILURE_STATE_IS_ACTIVE
WARN iHnf2 22:21:22.969 : switching timer source to TS_TSC
ERROR iHnf1 22:21:22.969 : Cycle 17843. Wrong cycle timing. Delayed for 32017 us (Min: 6000 us, Max: 18000 us). Source: Generic high precision time
ERROR iHnf2 22:21:22.969 : Cycle 17843. Wrong cycle timing. Delayed for 32097 us (Min: 6000 us, Max: 18000 us). Source: PLC cycle watchdog
ERROR iHnf2 22:21:22.969 : Cycle 17843: cycle time violated (source: 703).
ERROR iHnf2 22:21:22.969 : InterfaceSetTimingViolationFailureState(): Timing-violation SOS_FAILURE_STATE_IS_ACTIVE
ERROR iHnf2 22:21:22.969 : Cycle 17843. Wrong cycle timing. Delayed for 32121 us (Min: 6000 us, Max: 18000 us). Source: Generic high precision time
ERROR iHnf1 22:21:22.970 : hnfDoSafeOSCyclic: Cycle time violated in cycle 17843
ERROR iHnf2 22:21:22.970 : hnfDoSafeOSCyclic: Cycle time violated in cycle 17843
INFO dKRC 22:21:22.977 : Meldung Nr. M_15058 abgesetzt
INFO tMELD 22:21:22.977 : M_15058: "Die Steuerung ist im fehlersicheren ..."
WARN tNextGen 22:21:22.980 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A4)
WARN tNextGen 22:21:22.980 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A5)
WARN tNextGen 22:21:22.980 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A6)
BASIC tNetP052 22:21:22.983 : <SYS-X48>: KCP-Connected State-Change: Old='KCP_Plugged' -> Act='KCP_Unplugged'
WARN tNextGen 22:21:22.984 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A1)
WARN tNextGen 22:21:22.984 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A2)
WARN tNextGen 22:21:22.984 : CNextGenPowerBrakeControl: Wrong hardware state in "ReadyToMove". (A3)
WARN tLRS_HP 22:21:22.984 : laghpStateRegular: Spontanantriebsstopp
INFO tLRS_HP 22:21:22.984 : Meldung Nr. M_108 abgesetzt
ERROR tCabCtrlFa 22:21:22.984 : virtual void CCabCtrlOpProcessSafetySignals::DevelopIO(): No communication with Safety! Interface versions: CabCtrl(13), Safety(0).
INFO tMELD 22:21:22.984 : M_108: "Drehzahl-Stopp aktiv"
INFO tZYK_preIP 22:21:22.992 : Meldung Nr. M_310 abgesetzt
INFO tZYK_preIP 22:21:22.992 : Meldung Nr. M_3186 abgesetzt
INFO tMELD 22:21:22.992 : M_310: "Antriebe durch Safety deaktiviert."
INFO tMELD 22:21:22.992 : M_3186: "Antriebe wurden entladen (Grund: SAFETY)"
It seems motherboard problem in PCH chip because HPET timer in PCH chip in my case. It seems similar.
My thesis some threads in VxWin taking too long time and safety system going to fail safe state reason of thread monitoring. All safety communication lost included the SmartPad and you can see Emergency Stop Inoperative and red banner on top. I tried replace PLC and other related components but no success. I will try new motherboard in few days.
-
Thank you for reply.
It was working with the same hardware before the motherboard got damaged. The only difference is the K11 and S11 codes. However, the BIOS and hardware manager appear as K11. The original software version was 8.5.7, but I installed 8.3 for testing purposes, yet the same messages are appearing.
-
Hello All;
I have KRC4 controller KR5 and KSS V8.5.7 HF1 software.
I replaced the faulty D3076-K11 motherboard with D3076-S11. The Kuka HW Manager recognizes it as D3076-K11. So far, there is no problem.
KSS give some strange error messages:
- Controller in failsafe state
- Unknown operation mode
- Temperature sensor PCH (-21474836 C) out of range
- Position comparison robot controller <-> safety controller not possible.
Operation mode can't selectable because Mode selection popup does not showing up also SmartPad disconnect button does not work too.
BIOS show sensor 3 (I guess PCH sensor) is in Error state.
I check diagnostic viewer:
- No ethercat error on any controller components included of SmartPAD. All components show Operational state.
- I tried SmartPad on other robots and there is no problem.
- Install 8.3 but all messages same.
- Create new project nothing change.
- I tried new Smartpad nothing change.
Does anyone have an idea ?
-
-
Hello Y200 Interface can run on real controller ?
-
You can't add Profisafe module to KRC2. Remove profisafe module and try again.
-
ROBOT : KUKA KR10R1100_2
KSS 8.6.9 HF2
Kernel system version KS V8.6.52463
Is it possible to install KSS V8.3 (downgrade) on a robot that has version KSS V8.6 ? In case yes what is the procedure?
No You can't
8.6.X software running on new motherboard and 8.3 not supported. Also vice versa not supported.
-
PLC as Profinet master also known as IO Controller. Robot is IO device and on your scenario PLC should be in IO Controller Mode.
Other steps:
- You should be check Profisafe address on each side. Robot profisafe address can be set on Workvisual Profinet settings and Safety Related Settings pages.
- You must be use ACK_GL function on PLC. Profisafe communication failures can only be reset by this function. Without acknowledge robot always show Profisafe Communication Error.
-You can try other "compatible modes" for example "8.2, Profinet 2.2" on Workvisual profinet settings page.
-
Hello;
KUKA KRC4 and KRC5 controllers already support OPC UA connection with optional technology packages. Just ask to local KUKA and you can get technology package.
-
Hello;
I have Durr painting robots with KEBA controller. Anyone have documentation of controller and system ? I don't know this robots and KEBA does not provide any documentation on website and not found any information on internet.
-
Connector pinout shows all signal of the gun. You can't connect some signal to RDW box. For example digital I/O's and 24V signal should be connect externally or to Robot I/O modules.
In RDW you can just connect resolvers signal and temperature sensor.
-
Are people outside kuka not allowed to create plugins for kuka HMI?
Everyone create plugins there is no limitations. (If you know how to do)
Do you need to buy license to create plugins?
There is no need licence. Because it is not salable products of Kuka.
Do you have to pay for documentation (to get demo plugin source code)?
There is no documentations. Because it is not public and normally users not need to write own plugins (Kuka thinks so)
-
Sorry I don't remember clearly which tool used but some holes included three dowel pins inside. If you didn't remove dowel pins may can prevent to remove flange.
-
If I remember correctly, some screws on the opposite side need to be unscrewed from the robot base. After that, the gearbox can be completely disassembled. I completely disassembled it a long time ago, but there is no replacement part inside of the gearbox. We have some backlash issue and we just replaced the bearings and the problem went away.
-
Theoretically negative values cause not to energy consumption because motors generate own energy to main DC Link. This mean negative values is not adding to total consumption. Please note ABB's consumption counter is not only axis values it is including total consumption with external units mainboard, display etc. When you stop the robots total consumption still increasing because controller components need to energy to work.
-
Sometimes axis motors under regenerative effect and generate own energy cause of external load or conservation of energy rules. It is absolutely normal and generated energy absorbed by brake resistors. If you see minus value of axis, this mean the axis generate energy itself.