BSL problem

[bdoutney]

I am having some difficulty with this. I am getting short counts. almost always 1 short. I am using AB micrologix 1100. and a BSL instruction. I have a newspaper gripper conveyor about 150 grippers long from a machine that inserts ads into the papers out to a stacking machine. At the end the papers drop onto a flat conveyor for the last 5 ft. I have a sensor(A) counting grippers with papers in them before they drop on conv. and a gear and prox on the flat conv. roller that I use to shift the BSL with. I am using the input from sensor(A) to set the bit address. The object is to have the count at the end of the flat conveyor where the papers stack up to 50 and then drop the bundle away.

 

[Lancie1]

Okay, now let me ask a few questions to get the answers coming.

1. Has your BSL worked correctly in the past, and is this a new program?

2. Can you post your Micrologix program, or at least the part of it that uses the BSL? You can ZIP the RSS file and attach it to your next post, or you can take a screen snapshot ("Print Screen" is one way) of the relevant rungs.

3. "I have a newspaper gripper conveyor about 150 grippers long..." is not what we need to hear for a bit-shift program. It is either 149, 150, 151, or some other number of grippers long. Your BSL deals in exact integers. It will not understand about, approximately, or close enough. How long is it really? Is your BSL "Length" parameter set to 150?

Length is the total number of bits to be shifted by the BSL. Bits located to the left of the last bit in the array, up to the next word boundary cannot be used.

 

[bdoutney]

I have used a BSL in the past for rejecting stuff but not like this
I attached a zipped copy of the program(I MACH LINE COUNTER.zip (19.9 KB, 1 views) Let me know if its not showing up.
The 150 number does not matter. I am counting the papers as they drop off that conveyor onto the flat conveyor. The prox is on the last gripper right before it opens. I should not have put that number in my post

 

[Kev77]

I think your problem is that the B9:0/0 that you are using in your bit address for "Paper Present" is also used in the BSL array. Try using B9:4/0 or something that is not in the array. Look at it this way, if position 0 doesn't have a paper and and the sensor is triggered between teeth, it doesn't matter because you just loaded a 1 in position 0. This is why you are "sometimes" one short. It all depends on when the paper is seen.

 

[bdoutney]

I see what you mean. I now made the bit address read the input directly. I will try that out shortly. I have read many of the BSL posts on BSL and still have trouble with the timing.

"if position 0 doesn't have a paper and and the sensor is triggered between teeth, it doesn't matter because you just loaded a 1 in position 0. This is why you are "sometimes" one short. It all depends on when the paper is seen"

If my paper count triggered between teeth would not my bit address be back to a zero by the next tooth - false to true transition of the BSL and shift a 0?

 

[Kev77]

When the rung with the BSL instruction goes from false to true, it compares what the status of the bit address, if it is true, position 0 is true, and if the bit address is false, then position 0 is false. By using the a bit in the array, you are putting a value in manually and not allowing the instruction to work correctly.

 

[Lancie1]

By using the a bit in the array, you are putting a value in manually and not allowing the instruction to work correctly.

That seems to indicate that BD does not understand how a BSL is supposed to work. It introduces a bit (either 0 or 1) at the beginning point, and shifts that bit each time the BSL rung goes from false to true, all the way out to the "Length" setting of the BSL. Period.

 

[bdoutney]

When the rung with the BSL instruction goes from false to true, it compares what the status of the bit address, if it is true, position 0 is true, and if the bit address is false, then position 0 is false. By using the a bit in the array, you are putting a value in manually and not allowing the instruction to work correctly.

Are you saying I can't use the input I:0/2 directly as the bit address? I am starting to think that the problem is the paper detector signal being of inconsistent duration. Remember these are 2 different conveyors. One gives me the paper count and then drops them into the other which delivers the papers into a stacking machine 60 inches or 58 pulses later and to know when 50 have gone in whether the conveyor speeds change or stops and starts.

 

[Lancie1]

That looks fine for the BSL setup.

Carry-over to the next pulse could cause missed counts.

I can see where you might improve it some by adding a bit. For example on Rung 001, if you also put the pulse bit I:0/0 in series with the XIC B9:3/9, that would make sure that two 1's back-to-back at B9:3/9 does not keep the output ON for two pulses, without a break (which would cause a missed count).

 

[Kev77]

I agree, the BSL looks good, just make sure that the paper input on when the drop table pulse happens. This will ensure that the correct data is passed. I don't see an issue when an input is used in the bit address of a bit shift. Are the two conveyor speeds matched? Can you do a drawing on the sensor and cam layout?

 

[bdoutney]

They are speed matched but the second belt conveyor spacing is not as exact as the first/gripper conveyor because they papers are just falling on to it. that is not really a problem though. The flat conveyor. prox puts out about 6-8 pulses/paper so I have a 1 being shifted and a bunch of zeros which I ignore until I see another 1 and that is my count 60 inches later.
I don't know about making sure the the paper input is on when the drop table pulse happens. These are not mechanically linked. This might be the root of my missing count problem. What do you think about having the paper sensor latch a bit for the BSL Bit Address to be unlatched by the BSL done bit?

 

[Eric Nelson]

I don't know about making sure the the paper input is on when the drop table pulse happens. These are not mechanically linked. This might be the root of my missing count problem. What do you think about having the paper sensor latch a bit for the BSL Bit Address to be unlatched by the BSL done bit?

That's the approach I would use. I would also add a one-shot to the drop table pulse. Something like this...



-Eric

 

[Kev77]

The problem that I see with the setup would be getting the two signals on at the same time, every time. What is the signal duration of both the paper present sensor and the pulse counter? If the "paper present" sensor duration is shorter then time between pulses then you might always have a count issue. If I remember correctly the shift happens on the first scan following a false to true transition. I am not at my PC with logix right now but I will check later.

You might get it to work with the latch and unlatch that you stated above.

If it was me, I would look at trying to get it where you have one pulse per paper. There would be some timing that would need to be done but it would give you the ability to track better.

 

[chixrex]

new here, i am also using rslogix 500, but i dont know how to understand the logix please help me.

 

[chixrex]

given inputs:
1 push button up
1 push button down
2 sensor for confirming the correct position of the elevator,.
for ground position.
1 push button up
1 push button down
for second floor position.
2 sensor for confirming the position of the elevator in second floor position.
2 sensor for elevator door.

output:
motor reverse
motor forward