Hi,
I have a XRC controller on a UP50 Robot. We are occasionally getting alarm 4463 (Parity error) come up and faults the robot out. We just reset and it will run again. Can anyone point me in the right direction as to what this might be.
Regards
Paul
Parity Error Alarm 4463
-
PaulT -
August 27, 2016 at 5:42 AM -
Thread is marked as Resolved.
-
-
The only one I know of who uses parity checking is Honda. Did you get your robot from Honda or do your work for Honda?
Parity checking looks a an input or output group group to make sure the correct number of bits are on. For example if you had a command
Wait IG (1) 2
The robot would normally wait for input group 1 to have a value of 2 (or 00000010 in binary). This would be a odd count and the parity check would have to be off. If you had the same command but with a different value,
Wait IG (1) 6
The robot would look for the input group to be 00000110. With this binary pattern the count would be even and the parity would be on and the robot would really be looking for 10000110 (Parity uses the last bit in a group to check or not check even/odd count).
The same thing happens with the output group commands. If the binary count is odd the last bit is not turned on, if it's even the last bit is automatically turned on, for example;
DOUT OG (1) 4 would give 00000100 binary with or without parity because the binary count is odd
DOUT OG (1) 36 would give 10010100 with parity check because the binary count of 36 would be even, the last bit comes on for the parity check.This all comes down to the PLC you are communicating with. Some PLC's use parity check on inputs and outputs, so the robot has to match (they are assuming you have a broken wire or something is wrong if the parity does not match).
One last note. Because parity check uses the last bit in a group you can no longer count to 255, the last bit in a group. You can now only count to 127 because you loose the last bit.
-
Hi Robodoc,
Thanks for your reply. No We don't work for Honda, but I think you have started to point me in the right direction. I'm not at all electrical or robot friendly so sorry if I sound dumb here. This is a robot that was off an old line that we are just trying to get running again. When the robot powered up we had a fault with the JZNC-XIU06B I/O module. I believe this is a bit of a special as it was configured to PNP input/outputs. Since couldn't get hold of this module we decided to swap it for the more standard JZNC-XIUO1B which is NPN. This meant we had to change our input /output signals from PNP to NPN through some relays and wiring changes. It sounds like maybe we don't have this quite right. I have sent your reply back to our electrical engineer who no doubt will understand this more than me.
Regards
Paul -
If you are not using parity I would suggest turning parity checking off.
Please set S2C117, 118and 119 to zero for inputs and S2C122, 123 and 124 to zero for outputs. This will make the inputs and outputs work "normal" and no more parity errors.