I have a request to scan a part with one mounted scanner and then scan a serial with another mounted scanner. I can scan from both, but I need to take it a step further and ensure that the part can only be scanned by scanner 1 and the serial number can only be scanned by scanner 2.
This should be a simple enough task, but I have not been able to find any code examples in the Progress documentation.
I am on OE 12.0, but this will have to work on 11.5 and up as well.
What you expect from the OpneEdge documentation? How to read your scanner (you don't even mention the brand/type)?
I think it's more reasonable to look in the documentation of the scanner and port whatever examples they come with to OpenEdge.
Scanner for part number:
REPEAT: UPDATE cPartNr IF NOT CAN-FIND(part WHERE part.part-nr = cPartNr) THEN NEXT.END.
Scanner for serial number:
REPEAT: UPDATE cSerialNr IF CAN-FIND(part WHERE part.part-nr = cSerialNr) THEN NEXT.END.
The point is, you probably have different sessions for the part scanner and the serial nr scanner, right? Then it is easier to fix it in the program itself. If you have two scanners simultaneously attached, please elaborate a bit more on the situation at hand.
There will only be one session of progress running. My customer (Honda) requirement is that scanner A scans part and scanner B scans serial number. There are mounted stationary scanners.
I might point out that I have already tested using both scanners through a single session and it works fine. Where I got stuck was to force the scan in the manner that I have indicated.
I don't really understand your post, sorry!
If the scanner driver supports a "scanOnlyPartNumbers" and "scanOnlySerialNumbers" properties then you should set those.
Otherwise you are going to need to employ some business logic.
If the business process is very structured and only one or the other can be validly used at a given moment then perhaps you just need to disable the one that should not be used until such time as it is appropriate to use it. Or just ignore input from the "wrong" scanner (that would be pretty bad UI though).
Or, if either scanner could be used at any arbitrary time, then you need some logic such as what Patrick shows. Basically -- when a scan is completed determine if the scan is a "part number" or a "serial number". Maybe there is a simple way to do that -- perhaps all "part numbers" start with "P" and serial numbers start with "S". Or maybe parts have 6 digits and serial numbers have 8. Or maybe (as Patrick suggests) they already exist in the db and you can look them up to see which sort of number it is. Only you know how the part numbers and serial numbers can be differentiated and how you can determine which one was just scanned.
We are in retail point of sale and deal with many different types of hardware including scanners. In all the hardware we deal with the manufacturer provides drivers that allow you to control the hardware.
In our POS module we use OPOS and/or POS for .NET to control the hardware. This allows us to subscribe to hardware events such as a Scanner.DataEvent. In this DataEvent you could then add your logic to assign the ScannerData to whatever field you want.
You should also be able to configure the scanner on what type of barcodes you can scan. Hopefully, the part number and serial number us different barcode symbologies.
I do not yet have the info on the scanners themselves to determine if they can be set as scan only for a particular number (barcode). In my testing, I am using USB plug and play scanners. I have never heard of controlling what a scanner can scan. I made the assumption that this was to be done in Progress. There is a distinct order in which the scan will be done, part first and then serial. I was crazy enough to think that I could find some code reference that would say
I am already doing something similar in Freedom ErrorPrrof using Visual Basic (old as hell). I can actually set a device to do what I want it to do, including be inactive. I thought this would be no problem in Progress.
It might be that simple. Roger makes some very good points too.
But it is kind of unrealistic to think that you're going to find sample code just lying around for a hyper-specific and yet almost completely unspecified need.
"Talk to scanner" is not a Progress function any more than "Talk to cash register" or "talk to cattle prod" is. Setting that aside you appeared to say in your first post that you already knew how to successfully communicate with the devices. The missing piece seems to be the business logic. You just revealed a little bit more above but I somehow doubt that that is the full story. But if that *is* the full story I don't see what is stopping you from doing what you describe.
It probably is no problem in Progress. Once you get a clear description of what the task is.
I have worked with multiple scanners on a single com port. The scanners where connected to one single dock-station. Each of the scanners communicated with there own identifier. Just able to built logic on the identifier of the scanners.
I used the configuration software of the scanners to configure the scan string info on each scan event. Base on that you can strip the scan to determinate the identifier and the scanned code.
Hope this will help.
If I can ask another question about working with scanners. We would like to start using a wireless scanner and there are a number of Bluetooth devices available. does anyone know what the range (from the base station) of the scanner is. We need it to cover about 50 feet
If you can tell the difference between a part number and a serial number once scanned, one might as why you care that they only get scanned by the "right" scanner? Seems to me, if you get the data, you get the data and, if you don't get the data, you can easily detect that and alert the user that you need the missing data, whichever scanner is convenient.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
I would ask the customer for clarification regarding the 2 scanner requirement. The requirement may actually be that the end user needs to be able to scan either a part number or serial number and show something different on screen depending on which was scanned. When they added the 2 scanner requirement, they may have been dictating the technical solution without knowing that you can accomplish the same thing with only a single scanner and some business logic.
You may be able to accomplish it as-is with some sort of port identifier in the code as you suggested, but in general, scanners simply read barcode font and pass the characters to the listening program. They are extremely basic input devices. There are probably a few settings like whether each scan should be sent with a carriage return, but that would be based on the scanner hardware. I'm not sure how complicated the settings get on advanced scanners, but I think you'd want to use scanners with close to stock settings for ease of maintenance (such as needing to replace a scanner).
I guess since this specifically mentions *mounted scanners* these are used along a packaging or production line ?
If the scanners do expose unique ids in a way that you can access in your code, you can map each ID to a position along the line. Likewise, you can map the positions to the type of data that should be reported from that position.
Then you can validate on those mappings: "This is Scanner A at position 1, so the data provided should be a Part Number", "This is Scanner B at position 2, so the data provided should be a Serial Number"