Bit Shift Hardship

Discal

Member
Join Date
Aug 2010
Location
Florida
Posts
34
I am not the best programmer by any means but I usually can sort out most problems; not this time. Three of us have been trying to solve this issue, it has gotten to the point where it is starting to crank my winder so I figured it was time to seek outside assistance.

Not the best of programs but it has been running for more than a year without problems.

We have a small rotary assembly table that compresses three separate components together using about 900 ft.-Lbs. supplied through a pneumatic cylinder. To prevent dry cycling the fixtures we have two lasers looking for parts in the nests. The Bit Array is shifted every time the table indexes, if parts are present the cylinder is cycled and a one is loaded. Three stations over a pick-and-place; using vacuum cups, picks the parts and drops them onto a conveyor. This has run flawlessly for over a year.

There are times when the components do not successfully snap together and then are dropped on the line and need to be sorted and run back through the press. It was decided that the we should be looking for the cylinder to completely extend instead of using the part present lasers. This would allow the pick-and-place to skip over parts that were not compressed together properly, instead cycling them back through the machine a second time.

Now I am finally to my problem, the lasers worked perfectly for more than a year. When we switched the input signal in the program to the “Press in Down Position” bit, the Bit Shift stops working. The limit is functional and is seen by the PLC, the “Parts Present” bit will go true but a one is never loaded into the Array. To troubleshoot the problem we branched the rung and added a test bit that we toggle on the fly. When we run the lasers everything is perfect, as soon as we toggle over to the limit switch the Bit Shift stops and when we swap back it will start again.

The table dwell time is two seconds. The “Table in Position” bit and the lasers come on almost simultaneously, whereas the “Press in Down Position” bit lags by about a quarter second. I do not see that this should be an issue because I can manually load the bit while the machine is idle and it takes me far longer than a quarter second but it will accept it. That is the only difference we have been able to find.

Now that I have finished my novelette, hopefully someone can enlighten us as to the error of our ways.

Thank you for taking the time to read.

Bit Shift.jpg
 
The table dwell time is two seconds. The “Table in Position” bit and the lasers come on almost simultaneously, whereas the “Press in Down Position” bit lags by about a quarter second.

It seems to me that if "table in position" bit fires a quarter of a second before "press in down position" then you will not load a 1 into the BSL because "part present" is 0 when the BSL in enabled.
 
I agree with Mark and dginbuffalo. Look at the timing of the "table in position" with the status of the "Press in down position". You may have to delay the BSL instruction for the half second after "table in position" comes on.

Regards,
Garry
http://www.accautomation.ca
 
You need to setup rung 10 to work with the new input, like you did with rung 9. Basically anywhere the laser sensors are.
 
Where are the B3:1/5, B3:1/6 and B3:0/7 OTEs located within the ladder logic and how are they being controlled?
Since they are not hard inputs, the internal bits OTE location within the ladder logic will determine the timing of their evaluation; you might miss scans.
I'd first Cut the rung controlling the B3:0/7 OTE and Paste it just above or bellow the B3:1/5 and B3:1/6 ones.
If this does not do it, then, as @dginbuffalo suggested, add a time delay after B3:1/0 becomes true before triggering the BSL instruction.
 
First and foremost, thank you to all who took time to reply.

My current understanding then is as follows:
My “almost simultaneously” was in fact not, the lasers indeed had to be leading at all times for the Bit Shift to work properly. Something my self-taught middle-aged fat man eyes did not discern. After playing around with a test station, I think I have a work around but will have to get back on the machine to test.

I little more information, The “Table in Position” signal comes from a Camco Indexer. The indexer never stops running; there is just a two-second dwell between rotations. I always write a program with a minimum of three ladders. All of my hard inputs come in on Ladder 2, and my last ladder holds all of my outputs. I have found this method of writing programs allows for easier monitoring of I/O for colleagues with a limited (even less than my own) understanding of what they are looking at. This is why you only see Binary inputs in the screen shot.

I will update after I have been back out to the machine.
 

Similar Topics

Hi All. I have a very specific question about tracking using an encoder and bitshift register. We would like to use a Compact or Control Logix PLC...
Replies
40
Views
1,600
Hello. I've been using the answers in this forum for a while now, so thank you. Usually I can find the answer I'm looking for with a basic...
Replies
8
Views
733
Hi, I need some help write a PLC instruction. I am using Proficy Machine Edition 6.5. Our indexing rotating table has 3 nests that are equally...
Replies
15
Views
3,893
Good morning (EST), I am trying to implement the code below in on an S7-1200. It's barely half a dozen instructions, but I am stuck; I have not...
Replies
26
Views
5,535
I have a program I need to work out for a client and I'm having trouble figuring out the correct logic to do it. Let me see if I can explain it...
Replies
27
Views
6,416
Back
Top Bottom