digital I/O.
You mean, individual wires for each signal?
If the I/O hardware isn't the issue, my best guess would be there's some EMI noise causing an occaisional bit flip.
what is the environment? did you check the wires/cables themselves? nothing pinched or scraped? how long is the I/O cable and how is it routed? what type of I/O modules exactly? more specifically what type of outputs and what current is sufficient to activate the inputs?
relays outputs are simple to work with as nothing seem to bother them - they will work with AC or DC or whatever. but relays are far from perfect because they wear. one of the problems are the minimum and maximum current. high current obviously erodes contacts and possibly makes them stick (weld). but inputs draw very little current and many are unaware that relays contacts require some minimum current or the contacts will deteriorate. this is called wiping current or wetting current (it cleans oxidation or contamination of the contacts). to avoid this one can use gold plated relays but i have never seen those in outputs cards, but they are common in instrumentation etc. so if your devices have inputs that only draw 1mA or so when energized, do not expect longevity from relay card rated for 2A per point unless you deliberately increase current. this can be done by adding resistors across inputs to get some 5-20mA of current.
finally what is the exact EXT setup and what program number fails to run when you get this error? with this you can narrow down search to specific input and output.
You mean, individual wires for each signal?
If the I/O hardware isn't the issue, my best guess would be there's some EMI noise causing an occaisional bit flip.
Yes, it´s individual wires
what is the environment? did you check the wires/cables themselves? nothing pinched or scraped? how long is the I/O cable and how is it routed? what type of I/O modules exactly? more specifically what type of outputs and what current is sufficient to activate the inputs?
relays outputs are simple to work with as nothing seem to bother them - they will work with AC or DC or whatever. but relays are far from perfect because they wear. one of the problems are the minimum and maximum current. high current obviously erodes contacts and possibly makes them stick (weld). but inputs draw very little current and many are unaware that relays contacts require some minimum current or the contacts will deteriorate. this is called wiping current or wetting current (it cleans oxidation or contamination of the contacts). to avoid this one can use gold plated relays but i have never seen those in outputs cards, but they are common in instrumentation etc. so if your devices have inputs that only draw 1mA or so when energized, do not expect longevity from relay card rated for 2A per point unless you deliberately increase current. this can be done by adding resistors across inputs to get some 5-20mA of current.
finally what is the exact EXT setup and what program number fails to run when you get this error? with this you can narrow down search to specific input and output.
The environment is machining lathes.
The wires cables are was replaced and long are five meters wire unshielded.
The PLC outputs are from an S7-1200 (relay type) connected directly to the KRC2 robot.
For the KRC2 robot inputs, we use a WAGO DeviceNet interface.
The external automatic has been programmed for a length of 8 bytes (PGNO_FBIT), with the parity bit (PGNO_PARITY), with the validation bit (PGNO_VALID) and with reflection of the program number enabled (REFLECT_PROG_NR)
The program reflection is checked in the PLC before sending the validation bit (PGNO_VALID).
if you are using reflection of PGNO, there is no point in calculating parity. and could be calculated wrong.
parity is a poor man solution to check if value is correct. it reduces error check to a single bit. using reflection one can compare every bit. result of that comparison should guide you to specific bit or I/O channel to troubleshoot.
so when you see the issue, get all values (PGNO sent, PGNO reflected, parity value) and check them out.
if you are using reflection of PGNO, there is no point in calculating parity. and could be calculated wrong.
parity is a poor man solution to check if value is correct. it reduces error check to a single bit. using reflection one can compare every bit. result of that comparison should guide you to specific bit or I/O channel to troubleshoot.
so when you see the issue, get all values (PGNO sent, PGNO reflected, parity value) and check them out.
Do any of the log files contain all the values (PGNO sent, PGNO reflected, parity value)?
when you see fault and robot stops, navigate to ext interface monitor and look at the values. everything is there. or... create own monitor using ConfigMon.ini
