You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old August 4th, 2005, 12:21 PM   #1
plcengineer
Member
United States

plcengineer is offline
 
Join Date: Jan 2004
Location: Va
Posts: 150
Product Tracking with a ML1500

Gents: I have an application coming up that I would like to get some opinions on. I have a conveyor that will be running 100FPM that I will need to divert product. Basically, a scanner will be above the three divert chutes to read the barcode to send me a signal. From that signal, I will determine what chute to open to send the product. We will have an encoder on the conveyor that is running so we can track the product. I have installed a HSC in the ML1500 to take in the signal.

I am thinking about different ways to track the product. I am thinking about using Fifo's but then I am wandering how to track the product with the kickoff position. I was thinking that I could setup how many pulses equaled an inch, then calculate how many inches it was from the scanner to the chute. Does anyone have any ideas of how to track the position along with the product?

Thanks,
  Reply With Quote
Old August 4th, 2005, 01:17 PM   #2
CroCop
Member
United States

CroCop is offline
 
Join Date: Aug 2005
Location: Utah
Posts: 1,050
I've done similiar (read bar code, check vs. what should be running, if not proper, remove from line). I used logic to break down what needed to happen, and a simple shift register. Worked well because the data was pass/fail (1/0) and I used the encoder input to track position and step the shift register. You could step a shift register with a sensor as well if you wanted.
  Reply With Quote
Old August 4th, 2005, 01:22 PM   #3
plcengineer
Member
United States

plcengineer is offline
 
Join Date: Jan 2004
Location: Va
Posts: 150
Do you have any sample code with FFL and FFU? Or, should I be looking at BSL etc? How did you do the tracking with the encoder? I guess I am wandering how you stepped the shift register.

Thanks,
  Reply With Quote
Old August 4th, 2005, 02:44 PM   #4
CroCop
Member
United States

CroCop is offline
 
Join Date: Aug 2005
Location: Utah
Posts: 1,050
I have a copy of the code somewhere at home. I'll try and dig it out. I did it in Directsoft, but the conversion to RSLogix isn't too difficult.

The flow of logic was pretty basic, I figured out how many pulses it took to go from sensing to reject, and used that as a preset counter value. Use the pulse count as the accumulated value in the counter, and when the counter finishes counting, shift, and reset counter.

I'll see if I can find it.
  Reply With Quote
Old August 4th, 2005, 02:50 PM   #5
bioplc
Member
United States

bioplc is offline
 
bioplc's Avatar
 
Join Date: Jul 2005
Location: tampa
Posts: 97
I agree with CroCop...we have done something similar to it...we used a Shift Register and 1- good, 0- bad ( we used automation direct)...
note: read the manual before you use 1s and 0s..sometimes shift register by default has 1s in it....you finally end up accepting all the product.

Automation direct has all 0s by default.
  Reply With Quote
Old August 5th, 2005, 12:26 AM   #6
CroCop
Member
United States

CroCop is offline
 
Join Date: Aug 2005
Location: Utah
Posts: 1,050
Here's a screen shot. I aplogize for the lack it not being a full working program, but I couldn't find the original so I just gave the guidelines.

The jixt is to have 2 seperate shift registers, and tie the diverter output together using sensors, or using an encoder input if you like. I like then sensors, it's a little simpler, but if you already have the encoder, you can use that just as well.
Attached Files
File Type: doc Barcode Ladder Example.doc (228.5 KB, 61 views)
  Reply With Quote
Old August 5th, 2005, 01:46 PM   #7
plcengineer
Member
United States

plcengineer is offline
 
Join Date: Jan 2004
Location: Va
Posts: 150
Thanks for the screen shots. I do have a question. I am thinking about doing the following, so please comment. I may take my HSC input A+ signal from the encoder and hook it to I:1/0 on the HSC input card. Then, if I rotate the shaft, I'll know the approx number of pulses from the scanner to the reject. After doing this, I was thinking that if I saw a reject, I could set a 1 in a BSL and rotate that bit with I:1/0. If I saw the bit 1 rotate in a set window, I could then say now look for the PE and divert. Once I divert, I clear out the 1. Does this sound feasible??

Thanks,
  Reply With Quote
Old August 5th, 2005, 02:16 PM   #8
CroCop
Member
United States

CroCop is offline
 
Join Date: Aug 2005
Location: Utah
Posts: 1,050
Why don't you set the pulse count to zero, set a product in front of position upstream, turn on the line, and stop the line in the downstream position? You would know exactly how many pulses it took to move from a to b then.

Use this number of pulses to rotate the BSL, and then do the compare and divert.
  Reply With Quote
Old August 5th, 2005, 02:29 PM   #9
plcengineer
Member
United States

plcengineer is offline
 
Join Date: Jan 2004
Location: Va
Posts: 150
That is a good idea for getting the number of pulses from A to B. Maybe I am missing somthing here. Are you saying if the number of pulse = 1000 from A to B, then if the number of pulses = 1000, then run the BSL? I was thinking that I would need the HSC input to rotate the BSL to track the 1 down the line. How would I handle multiple 1's like back to back rejects? maybe I am missing something..

Thanks,
  Reply With Quote
Old August 5th, 2005, 02:34 PM   #10
Jiri Toman
Member
United States

Jiri Toman is offline
 
Jiri Toman's Avatar
 
Join Date: Jun 2002
Posts: 498
Quote:
Does this sound feasible??
No it does not. That's not how it's done.
First of all you shouldn't use FIFO (asynchronous ) shift register and secondly you can't count pulses.
You need to use synchronous type of shift register.
You will need to construct this shift register by using COP instruction. You need to shift integers not just 0's and 1's.
You need to have an "Induction photoeye" at the point of new
box entry. Each conveyor encoder pulse represents so many inches of travel. Say for example one pulse is one inch.
If you have a box that is 10 inches long you will feed 10 integers into the shift register. These 10 integers represent the box length in the shift register memory. Since most boxes will experience some kind of slippage you will need to incorporate a
"re-allignment photoeye" somewhere down the line.
When box breaks this photoeye you examine the shift register
contents and if you see that the shift register data is ahead
of the physical box position you know that you had some slippage and you will re-allign the shift register data to reflect the
physical world.
After all the re-allignment photoeye is at a known distance
(represented in pulses) from the induction photoeye.

The "Point of divert photoeye" is positioned at the point of divert. When box breaks this PE you will examine the appropriate
stage of the shift register and if there is a number bigger than 0 present you will decode the meaning of this number.
Divert or not divert. Each divert will have it's own photoeye.
If you have 10 diverts you will track numbers 1 to 10.

After the divert is completed you should verify the arrival of the box by breaking a "divert complete photoeye".
In other words the count of boxes sent to a specific divert should be equal to the count of boxes arriving at this divert.
  Reply With Quote
Old August 5th, 2005, 02:35 PM   #11
OkiePC
Lifetime Supporting Member
United States

OkiePC is offline
 
OkiePC's Avatar
 
Join Date: Mar 2005
Location: ENE of Nowhere Oklahoma
Posts: 9,520
I wrote a SLC program that tracked tires on a 210' conveyor. The tires are dropped onto the conveyor at fixed points along it's path, I needed to know which tires were in which locations for later sorting. My program scales an encoder input into whole feet (since no tire is smaller than 1 foot). A data table of 210 elements stores the contents of each foot of the conveyor. I use an integer derived from the encoder to represent the end (output) of the conveyor. So, as the conveyor moves, the integer increments from 0 to 209 and then rolls over. When a tire is dropped onto the line, I simply dropped data in the data table at the location of the pointer plus an offset for the distance from the drop location to the end of the line (with wrap-around). When a photoeye detects a tire exiting the conveyor, I search the first six entries in the data table starting with the pointer, (1st 6 feet of conveyor) find the next entry for the tire and moved it to a fifo for the next section.

The next section consisted of more conveyors with diverters to still more conveyors. For these, I would FFU tires from the stack into a single register when they entered a diverter zone. If the tire was diverted, the data was sent to the FIFO stack for that diverter. If the tire exited the zone without diverting, it's data was copied to the FIFO for the next section. I relied on photoeyes to guarantee whether or not a tire was diverted. That way, if the diverter failed to operate, my tire tracking data would not get messed up.

This method doesn't require moving a bunch of data. The pointer that refers to the end of the conveyor has to be constantly updated, and that's about it. Using the encoder allows the line to be stopped, reversed, and started without fouling up the tire tracking logic. It will run for several months at a time without error. The only time it screws up, is when someone physically disturbs the product (clear jam-ups, etc.) If they move a tire more than a few feet from it's original location, then it will misplace that tire and send it to the default location.
  Reply With Quote
Old August 5th, 2005, 04:05 PM   #12
Jiri Toman
Member
United States

Jiri Toman is offline
 
Jiri Toman's Avatar
 
Join Date: Jun 2002
Posts: 498
Quote:
The only time it screws up, is when someone physically disturbs the product (clear jam-ups, etc.) If they move a tire more than a few feet from it's original location, then it will misplace that tire and send it to the default location.
This is the reason why most tracking systems will not use FIFO's.
If you lose a box you will screw up the whole FIFO memory, everything that's in the FIFO stack!
I am not saying that FIFO's don't have a place in conveyor tracking and your application seems to be OK but for most part that is not
a preferred method of tracking. I have used FIFO's for tracking
myself in different applications but I would never use it in
a large tracking system with many diverts. The potential for
screw up is too great and potential screw up is too big!
  Reply With Quote
Old August 5th, 2005, 06:19 PM   #13
CroCop
Member
United States

CroCop is offline
 
Join Date: Aug 2005
Location: Utah
Posts: 1,050
I'm of the same opinion. I like the sensors sensing the product, but that can fail if someone puts their hand in front of a sensor.

Back to the original question, what are you reading from the bar code, how many lines can you divert to, and what drives the decision on where to divert?
  Reply With Quote
Old August 5th, 2005, 09:40 PM   #14
jrwb4gbm
Lifetime Supporting Member + Moderator
United States

jrwb4gbm is offline
 
Join Date: Apr 2002
Location: NC
Posts: 2,185
I worked on a system a couple years ago that had the divert lane included as the last two digits in the barcode. I used some masked move and compare equal instructions to strip the rest of the barcode off and determine the correct divert assignment.
  Reply With Quote
Old August 11th, 2005, 07:48 AM   #15
OkiePC
Lifetime Supporting Member
United States

OkiePC is offline
 
OkiePC's Avatar
 
Join Date: Mar 2005
Location: ENE of Nowhere Oklahoma
Posts: 9,520
Quote:
This is the reason why most tracking systems will not use FIFO's.
If you lose a box you will screw up the whole FIFO memory, everything that's in the FIFO stack!
I am not saying that FIFO's don't have a place in conveyor tracking and your application seems to be OK but for most part that is not
a preferred method of tracking. I have used FIFO's for tracking
myself in different applications but I would never use it in
a large tracking system with many diverts. The potential for
screw up is too great and potential screw up is too big!
In my defense, the flat belt conveyors I was talking about have manual sorting downstream, so it wasn't critical if an error occurred. We have five lines feeding into four sorting stations. The fifth line feeds into the four conveyors via diverters. Before my program change, all the tires on the fifth line were sent to the others pretty much randomly. That meant that the person sorting tires at the end of the each of the four lines had to handle all the different products from the fifth. My program change allows them to control which tires from the fifth line go to which conveyors (1 through 4). If I had bar code scanners, there would be no errors. I used what we already had...an encoder and a photoeye. Zero downtime...all done with online programming changes. I don't use FIFO to track what's on the flat belt conveyor. I use a data table with an encoder based index scaled in feet. The FIFO stacks are used for roller bed conveyors that connect the 5th line to the diverters. My FIFOs are subdivided with error checking so if a tire is removed, sorting will be disrupted for a maximum of about ten tires, and then it self corrects.
Quote:
The only time it screws up, is when someone physically disturbs the product (clear jam-ups, etc.) If they move a tire more than a few feet from it's original location, then it will misplace that tire and send it to the default location.
This only happens when there is a mechanical failure or ballup..I haven't yet learned how to program around those situations yet.

The intent of my original post was to point out a method of mapping the contents of a conveyor without moving all the data as the conveyor moves, but, instead, move the pointer that refers to the end of the conveyor. It's much more efficient and that's important when you're using a lower end PLC.
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
DVT Camera PRODUCT ID Select HELP!!! POWER_PACKED LIVE PLC Questions And Answers 11 May 3rd, 2005 11:23 PM
AB ML1500 to Emerson servo over ModBus Allan Barnes LIVE PLC Questions And Answers 1 February 23rd, 2005 09:09 PM
Bug Tracking Timotheos LIVE PLC Questions And Answers 12 May 8th, 2004 01:19 AM
Configuring ML1500 LRP C do to Modbus Peter Nachtwey LIVE PLC Questions And Answers 4 December 5th, 2003 06:22 PM
RS-logix does not recognize a PLC ML1500 Raul LIVE PLC Questions And Answers 6 February 12th, 2003 06:55 PM


All times are GMT -5. The time now is 08:42 PM.


.