BACKGROUND
I have a problem in my program which I originally misdiagnosed as movement-related, because I kept getting errors about “Overlapping Blends in a [MoveJ or MoveL], a waypoint was skipped”. The error was intermittent at first but becoming more frequent. I had removed blends from all the movements I thought were involved and was still getting the error. I removed one more blend from a waypoint several moves later, and that seemed to finally solve the problem. I stopped getting the error and the robot stopped skipping waypoints.
That is, until a day or so later. I was checking on it and found it stopped because parts had tipped over and were scattered about the inspection surface. This time, there were no error messages. I had programmed it to stop if anything was obstructing the inspection camera, and it had stopped because a part rolled in front of the lens. However, the way my program is set up, it should be impossible for parts to be left on the inspection table like that.
I started it again and watched it skip all the same waypoints again, this time with no error message of any kind. It would finish inspection, pick the part up, drop it and return to the belt. It was supposed to be delivering the part to a box next to the inspection table, but it was skipping that drop point altogether. And now, instead of intermittently having this issue, it was doing it with every single part. So now, here is the meat of the problem:
The box delivery portion relies on feedback from two scales. The scales count parts placed in one of two boxes, BoxA or BoxB. When one box is full, it triggers an audible alarm and automatically starts filling the other box. This gives time to change boxes out without any downtime.
CURRENT PROBLEM
Two counting scales with 3 relay outputs each are connected to the UR’s inputs. The scales’ relay outputs are: Lo, OK, and High. If a scale is reading underweight, it closes the Lo relay. If it has the right amount of weight, it closes the OK relay. If it is overfull, it closes the High relay. The relay common is +24VDC from a power supply. I have these wired to the UR as sinking inputs.
Then I have a series of IF statements in my program that decide which box the robot should drop a good part into. So here is a simplified sample, which I employed to test whether my code was being executed correctly:
IF BoxALo (input) =True(HI)
MoveJ BoxA
Else
Halt
I could see on the I/O tab that the input BoxALo was on. It showed up that way. But despite it being verifiably turned on, when my robot would reach this line of test code, it would halt.
This code was working properly for quite awhile. Then it began gradually to malfunction, and now it doesn’t work at all. Therefore I suspect gradual hardware failure within the UR, but I need to confirm this somehow. This program has been running almost continuously for at least a week, during which time the BoxALo and BoxBLo inputs are almost always on. Is that causing damage to the board? How do I fix this?
Thanks,
Anna
On your dry contact side of the relay are you using the 24VDC from the UR controller or from an independent power source? If an independent power source this could cause issues with the input not working correctly.
I would patch a Digital Output to the suspected damaged Digital Input and have a simple program Set Hi / Sleep / Check Input state / Set Lo / Sleep / check input state, let it run for a while to isolate and check if the input gives inconsistent results to rule out of the issue is local IO damage or something external.
I’m using an external power supply, which is also powering other things.
That is a good suggestion, I will try that.
I would also use the 24V above your digital input you are using to the relay dry contacts so that the robot is using ROBOT 24V to ROBOT GND through your digital input. We have seen issues where you wire an external 24V source to the dry contact as they are reference signals to the 0V and if the 0V are not on the same levels it can cause issues. You can also wire the controller to use the external 24V source for all input and output
I will try that. The scales have a single common each, which I wired to the 24V power source, but since they would only be connecting that common to a single output at a time there should be no problem with using the robot’s 24V instead. After I run the test to check for internal damage, I’ll connect each scale to a different 24V input common and see if that fixes it.