I have the following system: S4CPlus; Pick- Conveyor with Vision; Place- Fixed RobT; post inspection Indexed Work Area with photoeye triggering a vision inspection.
The system occasionally shuts down with the following Error:
Error 50174:
The WObj is not conncted to the conveyor CNV1. Robot TCP cannot be coordinated to work object. Object can be dropped because of time synchronization fault on conveyor node.
-Check for missing WaitWOBJ.
-Check that work object changed to stationary before DropWOBj was executed.
-Check for time synchronization fault, see status on conveyor node.
I also periodically receive the following Warnings, which don’t shut me down, but they are dropping frames:
4317: Scene info from Indexed Work Area1 discarded. 0.3 seconds older than incoming item positions.
4318: Item positions for Indexed Wrok Area1 discarded. 20.6 seconds older than incoming scene info.
The post inspection vision triggers from a photoeye, and also initiates two interrupts which are linked to TRAP routines. The two interrupts are executing twice per second. The TRAP routines have one or two PulseDO instructions.
I have set the PC network card at 10Meg and Full Duplex. I have lengthened out the trigger distance on the Pick Vision to reduce the number of frames. Can you recommend anything else to try?
For the 4317 and 4318 error the following migh apply.
Try to set the PC on half duplex. Also check that you have used the IP, default gateway and the subnet mask with the correct values on both the controllers and the PC. Check that there is no RSI issued on your Main Computer on your system. Some MC’s on the S4C+ have some problems with their network connections. Your local ABB office can help you with that.
Is your hub 10 Mbit that might also help. You should also check that your trig and strobe wiring has the proper shields.
I will get in contact with you about error 50174.
On some modern computers there is something called Hyperthreading. If this is deactivated in the BIOS it might improve the performance.
Do you have the latest updates for your network card?
I will try the half duplex. The switch that I am using is 10/100. The 100 light is on for the S4C+, but off for the PC (after I forced the PC network card to 10). The camera is the digital one with the supplied trig/strobe cable. I am unfamiliar with Hyperthreading, but will look into it.
You probable have some kind of timing problem in your RAPID program causing the 50174. Send a backup of your system to Serop Product Support and they will distribute to the right resources unless you have already solved it.
The best is if you can force the whole link between PC and controller to 10 Mbit Half duplex. The easiest way is to use a 10 mbit hub.
The 50174 problem occurs if you acknowledge an itmtgt too early.
Normally this is not a problem, but if you change your Pick or Place routines around the last TriggL, you can mix up the timings.
If you use the instruction AckItmTgt, you should review this.
It may occurr if you tune any motion event configuration.
It may occurr if you tune the any encoder configuration parameters, like StartWinWidth.
A workaround may be to change the rapid variable AckDelay to -0.1 in the main routine, like:
PROC main()
AckDelay:=-0.1;
InCoordRout:=FALSE;
InitSafeStop;
InitSpeed;
WHILE TRUE DO
…
This is a litte “special trick”, which I dont want to explain, but it’s worth a try.
Thanks. I have modified the Pick routine, so I will try to look at the Trigg AckItm timings. Also, I have a special post inspection where I am not using the AckItmTgt statement, but I do have an interrupt that runs when my post inspection Work Area QIdle=0 (this tells me that a target is in the que). In the interrupt, I use a NextItmTgtType to see if the target type is accepted. I pulse an output if it is not. I then use the Flush*tmSrc command to clear out the Que.
My place routine is just moving to a fixed RobT and dropping the item. I am not using any ItemSource for the place. The product then goes down a conveyor and to a photoeye, which triggers a camera for a post inspection. If the item is accepted, I assign a 1 to it. If the item is rejected, I assign a 2 to it. When the item gets put into the que, I use the QIdle signal=0 (there is something in the que) to trigger an interrupt TRAP routine. The TRAP routine looks at the item type to determine whether or not to set an output to reject the item. I then FLUSH the queue to get ready for the next item put into the queue.
!**********************************************************
!
! Trap Post Inspection Trap
! Trap triggers when doQIdle turns OFF
! This trap will check for rejects.
!
!**********************************************************
TRAP PostInspectTrap
NextItmTgtType ItmSrcData{2}.ItemSource,Type;
IF Type=1 THEN
PulseDOHighPLength:=0.08,doGoodPart;
ENDIF
Flush*tmSrc ItmSrcData{2}.ItemSource;
ENDTRAP
I tried to use the AckItmTgt statement, but could not get it to work. I ended up using the Flush*tmSrc instead.
The ItmSrc{2} is only used for this post inspection, within this TRAP routine. I am actually setting the output doGoodPart, which will mask the actual output that rejects the part. If doGoodPart never turns on, then the part will be rejected. I use a cross connect that is (NOT(doGoodPart) AND TRIGGER INPUT) = doRejectOutput. When doGoodPart turns on, the doRejectOutput is turned off.
I was back at the customer site yesterday. I tried the AckDelay:=-.1. This did not seem to help. The slower I ran, it seemed like the more likely it was to fault out.
One note: This is a double pick, single place. I had used the QuickAck logic. When I removed the QuickAck logic, the system ran without faulting out. Do you think this is related?
The QuickAck is most likely the cause of the problem.
Have you tried not to use QuickAck?
It may be an easy tune to fix this problem.
In the procedure IsQuickAckOk, the constant SafeDist are used to be 200. Try to increase this, for example set it to 250. If that doesn’t solve it, increase by 50 up to 500.
OK thanks. I am no longer at the customer site, so I will not have a chance to try for a while. I did disable the QuickAck when I was there, and I was able to run for almost 2 hours without faulting. WIth the QuickAck enabled, I would fault within 10 minutes.