Interconnect scan time?

Hey everyone.

Just want to know if the interconnect has a scan time.

Here's what I want to do.

Using a wtc weld controller wt6000 and 20iB controller I get a DI from the Welder at weld complete. I want to send that bit to the plc (control logic 5000) to count the welds and compare it to a defined amount of welds. For tracking of missed welds.
But when I connect the DI (from Welder) to DO (to plc), the plc doesn't always pick up every signal.
Is there something more I can do on the robot end.

Quote from Nation

According to the manual, I/O interconnects are updated "periodically". Who knows what Fanuc's definition of that is.

If you want guaranteed scan times, I would recommend you move the interconnects into a background logic program. A background logic program will update every 8ms.

Thanks for the reply,

This is what I'm doing currently, however I'm faced with a problem.

Sometimes I get a double count on a weld sequence, say when asked for 4 welds, I'll get a count of 5. And I can't figure out why.

Right now in my background logic I'm pulsing the signal for 0.5 sec in order to ensure the PLC picks it up (PLC scan time being 20ms to 50ms). So either the welder is holding on to the weld complete signal longer then my 0.5s pulse and I send it again, or the robot is somehow flickering the signal.

Background Logic:

IF (DI[Weld Complete] = ON), Flag[WC]=(ON)
IF (Flag[WC]=ON, DO[Weld Increment]=PULSE,0.5sec
IF (DO[Weld Increment]=OFF), Flag[WC]=(OFF)

WTC schedule near the end:

Turn ON Weld Complete
Turn OFF Weld in Progress
Extend Until NO Initiate
Turn OFF Weld Complete

Is there a better way I can write the background logic?

Quote from Nation

Code

! Raising edge capture ;
IF (DI[Weld Complete] AND !Flag[WC]),DO[Weld Increment]=ON ;
Flag[WC]=(DI[Weld Complete]) ;
! Reset output when the ack comes in. ;
IF (DO[Weld Increment] AND DI[Weld Inc ACK]), DO[Weld Increment]=OFF ;

Thanks for this.
If I do this, would I still have to use a flag?
Can't I just go directly DI to DO?
Or is the communication too slow?

I was initially using the flag to ensure the signals don't get lost in scan time.

Quote from Nation

The flag is there to catch the raising edge of the weld complete signal.

The reset of the output is what the ACK from the PLC would be for. It would come on once the PLC saw the output from the robot. Once the robot got the ACK, it would turn off its output and wait for the next raising edge of the weld complete signal. This would guarantee that the robot held the output on for at least on PLC scan.

With the code I posted, the sequence of events would be as follows:
[list type=decimal]

• A transition from low to high is seen on the Weld complete input

• Weld Increment output is set high

• Robot waits till it gets an ACK from the PLC, acknowledging that the PLC has seen the weld increment bit go high.

• ACK comes in

• Robot sets Weld Increment low, goto step 1.

[/list]

Display More

Nation, thanks for all the help but will this work if its a BG logic?
Or would it be better to add this as a macro after every weld?

with the way I have it now, the robot sometimes sends the signal twice to the plc. I can''t determine if the WTC is sending the weld complete twice or the robot is sending the signal to the plc twice or something in the plc is flickerig to pick it up twice but every now and then I keep getting a weld high fault.

Quote from Nation

It should work as background logic, provided you add the ACK in on the PLC side.

If you fire it from a macro, you would have to rewrite it. You wouldn't need the flag that acts as a raising edge capture, since the program would run sequentially.

As far as double hitting, does your PLC have the ability to run traces? Might be worth it to trace the output from the robot.

Thanks

What I'm wondering is if this is running in the backgrond, will the robot stop if it doesnt receive the sigal back? or will it continue to the next weld?

I think its bizzare that this only happens once in a while, around 4 times average per 8 hour shift.

Is there any other way I can write a logic to cofirm weld complete is achieved and communicate that with the PLC?

I'll also talk to the Controlls team in checking the RPI.

Thanks so much guys.

Quote from Nation

Another method would be to move the counting logic to the robot side, and just have it output the current count. Then you could compare the final count to how many counts that particular part is supposed to have, and generate a fault if it doesn't match.

Thanks for this idea, however having an issue with it.

What I thought at first was to increment it on my own, and then check with the PLC when it does fault to ensure that I have the same count as the PLC.

What I did was

IF DI[weld complete], R[1]=R[1]+1

That didn't work for some reason, the numbers I kept getting were in increments of 3 or 4 or 5, never consistent. So I figured my weld complete bit was on for too long.

Next I tried

IF DI[weld complete] = ON, F[1] = ON
IF DI[weld complete] = ON AND F[1] = OFF, R[1] = R[1]+1

This way, my flag never goes off. Stays high forever.
Next try using my digital output for weld initiate, I figured I try the one shot with this as when the weld initiate goes off the weld complete should go on.

IF DI[weld complete] = ON, F[1] = ON
IF DO[weld initiate] = OFF AND F[1] = ON, R[1] = R[1]+1

Also tried it with the 'weld in progress' bit from the welder, which 'should' go off same time as weld complete comes on

IF DI[weld in progress] = OFF AND DI[weld complete]=ON, increment by 1

Nothing happened, maybe the signals come on and off too quick for robot to catch it.
Changed the weld complete bit to a flag

DI[weld complete] = F[1]
IF DI[weld in progress] = OFF AND F[1] = ON, increment by 1

This also produced random numbers.

If I can't even increment properly then I cant even count it. This is all in BG Logic.