Possibly OT Software question

Hey again guys,

First of all, standard disclaimer goes here: I'm not asking you to do my "homework" for me, nor am I asking to download anything illegal, unethical, or without the express written consent of the Major League Baseball Association. As usual, I'm looking for someone to just tap me with the clue by four.

The problem: Operators print off barcode labels and apply them to finished product. They then scan the labels to enter them into a database. The barcode is later scanned again when the product is being shipped out. Only, sometimes, there's an "item not in inventory" error message caused by the operator not scanning the barcode label when it's applied to the product.

I have a pretty good idea of what my ladder logic will look like, and the communication protocols that will be involved. I'm kind of hung up on the software side of things. I'm not allowed to mess with the software for the printer or the scanner. What I'd like to do is set up a program that would send out an ASCII stream with the barcode's number when it's printed, and one that will send an ASCII stream with the barcode number when the barcode is scanned. Our IT guy told me that we use an SQL database, if that's any help.

When I asked him if there was an off the shelf solution, he said that there wasn't, as far as he knew. My questions for you guys are as follows:

1. Is my IT guy right? If such a creature doesn't exist, I'm going to have to write a program. I'm willing, but completely clueless.

2. If the answer to 1 is yes, do you have any recommendations on where I should start? I've got a C++ textbook, and have been trying to teach myself a little here and there ahead of a class I'm going to be taking a couple of semesters down the road.

Once again, I'd be grateful for any light you could shed on this matter.

What type of processor are you using? Your IT guy say they are using an SQL database. Does this mean everything is stored in an AS400?

We use A-B here and there are two ways that I know to communicate back to the AS400. One is to use an xcoupler. It's a module that fits in the ControlLogix rack.
The other way is to send out the data through a serial port using a wedge. Its a device that converts ascii and sends it out to the AS400 over ethernet. It support's many other protocols also.
I am working on a project right now where I am looking at adding an ascii module (1769-ASCII) and sending data over to the AS400. I am on the road at the moment and won't be back for a couple of days so I can't tell you the model number of the wedge we use. There is a lot of into out there to if you google ascii to as400.

robpaige; said:

Hey again guys,
---
The problem: Operators print off barcode labels and apply them to finished product. They then scan the labels to enter them into a database.

Click to expand...

Please research and specify the details of this database as suggested. There are off the shelf solutions. The most obvious of which is whatever system prints the barcodes for the operators, needs to account for their position within the process. If that proves to be too big an obstacle to move... you may look at the detailed specs of the reader/printer to see if you can get an echo signal into a HMI, PLC, or PC (in that order of preference). A Red Lion G3 could be programmed to log the data, send it the PLC if you like, display it, timestamp it, attach HMI operator comments, whatever you like, and then FTL sync it periodically, or write to a sql database. I am no database guy, but there will need to be some coordination between your system and "their untouchable black box" in order to allow access, and populate the correct records.

robpaige; said:

The barcode is later scanned again when the product is being shipped out. Only, sometimes, there's an "item not in inventory" error message caused by the operator not scanning the barcode label when it's applied to the product.

Click to expand...

Again, "they" printed the barcode, "their" system can't account for it? "sounds like an issue for IT" would be my first suggested reply to whoever challenged me with this task...tell 'em that while you study the system.

robpaige; said:

I have a pretty good idea of what my ladder logic will look like, and the communication protocols that will be involved. I'm kind of hung up on the software side of things. I'm not allowed to mess with the software for the printer or the scanner. What I'd like to do is set up a program that would send out an ASCII stream with the barcode's number when it's printed, and one that will send an ASCII stream with the barcode number when the barcode is scanned. Our IT guy told me that we use an SQL database, if that's any help.

When I asked him if there was an off the shelf solution, he said that there wasn't, as far as he knew. My questions for you guys are as follows:

1. Is my IT guy right? If such a creature doesn't exist, I'm going to have to write a program. I'm willing, but completely clueless.

Click to expand...

Hmmm, the IT guy is dumping his problem in your lap. Turn your nose up at it before you lap it up...it might turn into a big can of wh**p worm$. They are gonna make you split the ASCII stream going to printer to snag a copy?

This sounds like a pencil pusher who is blowing smoke because he doesn't know enough about his stuff to give a better answer.

These are solely my gut feelings, and I could be way off base.

robpaige; said:

2. If the answer to 1 is yes, do you have any recommendations on where I should start? I've got a C++ textbook, and have been trying to teach myself a little here and there ahead of a class I'm going to be taking a couple of semesters down the road.

Once again, I'd be grateful for any light you could shed on this matter.

Click to expand...

I trust the Red Lion G3 for logging about as much as I trust a PLC, skip the ladder, do it with a proven, fast, non-windoze hardware based HMI.

Mark and Okie,

Thank you both for the feedback, you've given me quite a lot to go on. Okie I discussed some of the exact same things you mentioned with the fellow who gave me this task. I also pointed out to him that we should also be ensuring that team leaders are working with the operators to cut down on these incidents, and they are working on it. Truthfully, I'm taking this on because I find the challenge fascinating, and I'm in a position where this is seen more as an opportunity for me to learn new things than anything else.

Mark, I'm (tentatively) thinking of going with a 5/04 processor, as from what I've seen of the specs, it can handle ASCII streams.

Rob - I've seen a number of people do bar code applications with Ignition (the SQLBridge module, when it was "FactorySQL").

1. What is the "ASCII stream" doing or accomplishing? Are you just trying to log the scans to the database?

2. Do you (need to) do anything in the PLC with the scanned data?

3. Is the bar code scanner: a standalone machine (some automatically send a UDP message every time they scan), hooked up as an input to your PLC, set up as an input to a computer program (PC sees a USB scanner almost like a keyboard), or a stand alone portable unit (like a PDA)?

4. Please get details of your database from the IT guy. What type of database is it (ie, Microsoft SQL Server, Oracle, MySQL, etc) . Ask him if can create a user account and a database/table for you to write to. Also verify that his department takes on the responsibility of maintaining and backing up the database.

5. Ultimately, at a high level, what do you want to accomplish? Ask if you need to interoperate with the software/process of the operators. For example, do they need to see your entries?

Nathan,

1. I plan on using the ASCII stream to differentiate between multiple barcodes. If an operator prints off, say, five of them, I want the process to account for all five barcodes.

2. No, the PLC doesn't need to do anything with the scanned data. Basically I'm setting up a system that trips an alarm if all the printed barcodes aren't scanned or otherwise accounted for (a "bar barcode" button for when a label doesn't print properly)

3. Stand alone portable unit

4. working on it.

5. I want to cut down on the discrepancies between barcodes printed and barcodes scanned to ensure that each pallet of finished product is accounted for in our system.

For barcodes, If you want to do a 1:1 on printed and scanned, then EVERY barcode should be unique.
We do this here by appending a sequence number to them, The first barcode printed for Pallet qwe321 is qwe321-1, if we need to reprint that barcode, the new barcode is qwe321-2, etc,etc. The system ignores the - and everythign after it when looking a Pallet up.

In the database, You could keep a table where when a label is generated(printed) a new record is created. Have a 'scanned' field for that record and either leave it null or set to 0. When the lable is scanned, Set that field to 1.

How are you synchronizing the data from the portable scanner to a PC or Network?

There is probably already some mechanism to track unique bar codes.

You could use the Ignition SQL bridge module. Consider writing a new record for each label, with a field to record when it was scanned. I would use the approach Dravik mentions, except that you may want to write the current "datetime" instead of a 1. NULL represents that the action hasn't occurred, non-NULL (with a scanned datetime) means it has. You could also use alerting in Ignition to send you emails/text messages after some alarm condition has been met. For example, if a certain amount of time has gone by with creations but no scan, or if a certain number of labels have been created and not scanned, etc.

Where does this "ascii stream" physically come from?

Okie,

I think I'd have to generate one. Since the software for the printer and scanner is black boxed, I was thinking that maybe I could install a program on our network. This program would basically "watch" the database that has the barcode information in it, and when the database is accessed by the printer program, generate an ASCII stream with the number of the barcode that was accessed.

More questions for you guys. If the barcode number is 12 digits long (this being the maximum number of digits I'd need to ensure each barcode is identified uniquely in my PLC, I might be able to get away with 8 or 10 digits, but I'm looking at worst case scenarios) and I use a start and stop bit, then we're looking at an ASCII string comprised of a total of 56 digits (4x12, plus one start word plus one stop word) is that correct?

Also, I'm thinking about the process itself, and what the PLC would be doing. If my program does what I outlined in my previous post, then the PLC receives an ASCII stream when a label is printed, it would then receive an ASCII stream again when the label is scanned, without sending anything from itself to the network. Since each barcode is printed only once, I might be able to use a unique ASCII stream being sent to the PLC twice as a way of saying: The first time means the label was printed, the second time means it was either scanned or marked as bad (either way, it's accounted for). Does that pass the sniff test for you guys? Do you think I'm missing something here?

Finally a question of hardware. I looked at the 1769-ASCII module, and I think it might be overkill for the process I am working on. If my first and second questions are both okay, then what I'm doing is sending streams of 50 zeroes and ones to my PLC one string at a time. Would the AB 5/04 processor be beefy enough to handle this, or do I need the 1769-ASCII?

robpaige said:

I think I'd have to generate one. Since the software for the printer and scanner is black boxed, I was thinking that maybe I could install a program on our network. This program would basically "watch" the database that has the barcode information in it, and when the database is accessed by the printer program, generate an ASCII stream with the number of the barcode that was accessed.

Click to expand...

I'd also have the program perform the same task for when a barcode is scanned

Something about the way you are figuring your "ASCII stream" is off. ASCII is character codes, 8 bits per character. Start and stop bits are also per character. When you set up the serial port, the start and stop bits are defined, they do not usually show up in your data on either end. You will see them if you "scope" the signal. There is usually an "end" character as part of a transmitted string, very commonly a Carriage Return.

The idea of sending identical strings for printed label and scanned label is going to cause problems. Why not add a code to explicitly state which it is? You're making the strings, they can be anything you want them to be. P123456789012 could be a printed label and S123456789012 could be a scanned label. Without identification, consider this scenario: Something happens to cause you to miss the "print record" for 234567890123. You recieve the "scan record" for 234567890123, but how would you know that? You would assume it's the print record and keep waiting for a missing scan record.

Thanks Mellis. I don't know where I got 4 bits per character. So I'd be looking at an ASCII stream of 112 bits, including a start and stop character. And I keep forgetting how much power I actually do have over this process, you're right, there's no reason not to do it the way you suggested.

Still missing something...
Say you send a 12 character string, and you set up your serial port for 8-bit data, 1 start and 1 stop bit. Each character will now take 10 bits. However, you don't really care unless you are monitoring the signal on the cable. You care that the 12 characters (8-bits each) show up in the PLC memory correctly. The start and stop bits will not be there.