Barcode scanner - PLC communication

N

Thread Starter

Natahion

I am using GE Fanuc PLC and Mitsubishi Melsec and would like to get data from barcode scanners. If someone out there could share their experience and
knowledge on the subject, I would be grateful.
 
G

Gavin MacLean

With the GE you would need a PCM module, and then to write the comms in megabasic. Your local distributor may be able to provide code for you barcode scanner.
 
N
hello
i am not used to plc,but have worked with
barcode scanner,which can be programmed according to our needs for eg. baud rates,
hand shaking signals,start-stop characters etc. o/p of barcode scanner is of RS232 standard
hence data can be collected and maintained easily.It also provides other standards also.for further detail contact me
 
M

Michael Griffin

I've used bar code scanners with an RS-232 interface to the PLC. The "best" way to apply them is usually application dependent. However, there are a few general points which should be kept in mind.

- The bar code reader is usually configured via software, and the configuration is down loaded from a PC to the reader.
- The configuration usually covers things like bar code type (recognise a specific type, or any type), number of characters (fixed or variable), various hardware specific parameters, as well as the triggering and response configuration.
- Most readers can be set up to read continuously, or only when triggered.
- The read trigger can often be either a contact input, or a serial command.
- Continuous read is good for when bar codes may come by at any time.
- Triggered reads are good for when the bar code is being presented only when expected.
- You can usually configure the header and terminator characters in the serial string from the reader. This can include having no header or terminator. Headers and terminators are useful when you can have a variable number of characters in the bar code.


You will need to write reliable a serial input handling routine in your PLC to process the input data from the reader. I'm not familiar enough with the PLCs you mention to offer any specific advice there, but there are a few general principles you may wish to keep in mind. These mainly centre around making sure your routine can handle unexpected events. These may include incorrect data, too much data, too little data (i.e., only part of a bar code, or "junk" characters), missing headers or terminators, etc. Basically, assume that whatever could go wrong with the data will go wrong.

I've found that if you have an operator interface display, you should use it to provide decent manual control functions for troubleshooting reader problems. This should include displaying any bar code data read, and allowing the reader to be manually triggered for test purposes.

Mechanical installation of the reader should follow the manufacturer's
recommendations. This statement may sound a bit obvious, but the person responsible for the mounting hardware may not bother to read the instructions if making the thing work is someone else's problem. The distance to and angle
of the bar code are important. The readers should not be exposed to excessive
vibration.

It can also be important to ensure the scanning beam isn't "seeing" excessively shiny surfaces around the label. Sometimes angling the reader slightly will help with this.

The labels themselves can be a problem if they are of poor quality. Many bar code readers can output a "quality index" to the configuration software. The "quality index" is a relative "figure of merit" indicating how much trouble the reader is having seeing the label. You can use this to see how good your set-up is.

The above is just a brief overview of some of the simpler points. I don't know if it is of any help. If you have some more specific questions, please let me know.


--

************************
Michael Griffin
London, Ont. Canada
************************
 
C

Cattaneo Andrea

Following your need I had done some projects involving this problem and the best I had found is to use something like an interface in between.

Of course in some case it could be an extra cost but if this function is integrated into another
device (like an Operator terminal) that is already present in the system that the cost is already covered.
I had used several brands of thus Operator Terminals with successfull results.

I hope this helps you

regards
Andrea Cattaneo ESA
 
Top