Damon, Good point, keep it common if these things ever get outside your control. There are a few situations here where it just makes it easier to imbed the commands to simulate data entry into a mainframe. Sometimes we have large strings of combined data and commands that fill in multiple fields. Great timesaver. And your other point should be of interest to all - data entry errors are reduced to an extreme minimum. The Bar Code does not lie...... Bob C.
[EMAIL PROTECTED] on 08/22/2003 10:28:14 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] (RBASE-L Mailing List) cc: (bcc: Bob Castanaro/BCH) Subject: [RBASE-L] - Re: BAR CODES In a message dated 8/22/2003 08:42:19 Eastern Daylight Time, [EMAIL PROTECTED] writes: > Jim is right. Some (probably most) of the readers have a setup card that > you can program all sorts of stuff into - tabs, returns, etc. Another > method is building some of these into your bar code. There is an > "extended" ascii character set for Code 39 that allows for asterisks, pound > signs, carets, etc. I don't think the Code 39 font that comes with R:base > has these exensions. I'll have to put this in as an enhancement request > for future versions. > Bob C. > Bob, The only problem with embedding the extended code in the barcodes is it can create problems if anyone else would happen to read it into their system. As barcodes become more universal, we are beginning to use the incoming barcodes to identify items in our system, to replace the hand keying of data. MUCH more operator efficient. Everything we do uses the standard Code 39 set, and then we add and characters we need in our application commands. We even use the AIAG prefixes in our internal barcodes for data validation, so it can be sorted and validated after being loaded. Without the P (Part Number) and S (Serial Number) Prefix, we would always have the possibility of interchanging those, and having errors. And we all know an operator would NEVER do something out of sequence <g> That way, it's a simple matter of stripping the leading prefix in data validation, and getting the right information in the right place, no matter how it's ordered. I believe Worth's Data Recorder has the ability to verify data with those prefixes, and then strip them out, but it's been so long since I played with it, I'm not sure. Just my $ .02 worth Damon Damon D. Kaufman President Stalder Spring Works, Inc ISO-9002 / QS-9000 Certified 2345 S. Yellow Springs St. Springfield, Ohio 45506 Voice 937-322-6120 Fax 937-322-2126 email: [EMAIL PROTECTED]In a message dated 8/22/2003 08:42:19 Eastern Daylight Time, [EMAIL PROTECTED] writes:
Jim is right. Some (probably most) of the readers have a setup card that
you can program all sorts of stuff into - tabs, returns, etc. Another
method is building some of these into your bar code. There is an
"extended" ascii character set for Code 39 that allows for asterisks, pound
signs, carets, etc. I don't think the Code 39 font that comes with R:base
has these exensions. I'll have to put this in as an enhancement request
for future versions.
Bob C.
Bob,
The only problem with embedding the extended code in the barcodes is it can create problems if anyone else would happen to read it into their system. As barcodes become more universal, we are beginning to use the incoming barcodes to identify items in our system, to replace the hand keying of data. MUCH more operator efficient.
Everything we do uses the standard Code 39 set, and then we add and characters we need in our application commands. We even use the AIAG prefixes in our internal barcodes for data validation, so it can be sorted and validated after being loaded. Without the P (Part Number) and S (Serial Number) Prefix, we would always have the possibility of interchanging those, and having errors. And we all know an operator would NEVER do something out of sequence <g> That way, it's a simple matter of stripping the leading prefix in data validation, and getting the right information in the right place, no matter how it's ordered.
I believe Worth's Data Recorder has the ability to verify data with those prefixes, and then strip them out, but it's been so long since I played with it, I'm not sure.
Just my $ .02 worth
Damon
Damon D. Kaufman
President
Stalder Spring Works, Inc
ISO-9002 / QS-9000 Certified
2345 S. Yellow Springs St.
Springfield, Ohio 45506
Voice 937-322-6120
Fax 937-322-2126
email: [EMAIL PROTECTED]
