These are chat archives for CORE-POS/IS4C

3rd
Aug 2016
Asa
@asapdx
Aug 03 2016 23:12
So, I think these gatorade bottle's UPC codes are just good at being misinterpreted
Also, when I add the 08 prefix, the scale gets less reliable
2 out of every 5 times it'kk either drop the 0 or the 8 or both
*it'll
Note: this is Dan btw
Andy Theuninck
@gohanman
Aug 03 2016 23:22
It'll meaning what, the SPH_NCR_Scale module? I'm not sure how SerialPort.ReadByte() would work reliably across multiple versions of multiple linux distros with a Magellan scale on the other end of the cable but not with an NCR scale.
Asa
@asapdx
Aug 03 2016 23:24
without the 08 prefix, the barcode has only been misread once on this bag of lettuce
yeah, this is with SPH_NCR_Scale
and its a scale isuse
err, scanner issue. I have 4 of them here, and they all act the same
when I add the 08 prefix, they become derpy and are much more error prone
its definitely not an issue with the serial port driver
Andy Theuninck
@gohanman
Aug 03 2016 23:28
It'd make sense to tailor the default to whatever the scanner/scale sends most reliably, but the NCR info up thread(chat?) seems like the STX byte should be followed by a 0 or 1 (0x30/0x31) to differentiate between scanner and scale. So to differentiate between the two I think it'd need to be STX+0+barcode instead of STX+08A+barcode, not just STX+barcode
Asa
@asapdx
Aug 03 2016 23:30
By default the scale/scanner sends STX+A+barcode+0x03
For UPC A barcodes at least
diifferent barcodes have different prefixes by default
For PCAmerica, we actually disable the A prefix and that is all that needs to be done
Andy Theuninck
@gohanman
Aug 03 2016 23:32
I don't disbelieve you not having hardware myself, just the only NCR documentation I've seen says the byte following STX is an ASCII 0 or 1 to indicate scanner or scale (in single cable; dual cable wouldn't need to specify)
But if the scale messages are e.g. 0x2+11+weight+0x3 or 0x2+144+weight+0x3 and barcode scans have no prefixes it seems like barcodes with certain leading digits could be misidentified as weights
^^ that is the raw data I'm getting over the serial port
from scanning two items
Andy Theuninck
@gohanman
Aug 03 2016 23:36
STX omitted on purpose, of scale doesn't send STX/0x2?
*or
Asa
@asapdx
Aug 03 2016 23:36
Scale doesn't send STX afaict
let me have Finn or Asa double check my interceptty tho
Andy Theuninck
@gohanman
Aug 03 2016 23:45
FWIW, I think the basic logic here is pretty universal. The driver accumulates bytes until an ETX, then passes it to a parse function to figure out what the individual message means. if/else and substring in C# behave basically the same as Javascript, PHP, Java, etc. In the not-Magellan case it's just a matter of taking an input string and [if appropriate] returning an equivalent Magellan string https://github.com/CORE-POS/IS4C/blob/master/pos/is4c-nf/scale-drivers/drivers/NewMagellan/SPH_NCR_Scale.cs#L160-L247
Added Console.WriteLine(b); then recompiled and restarted the driver
Andy Theuninck
@gohanman
Aug 03 2016 23:56
That's simple enough in theory (if (s.Substring(0,1)=="A") return s.Substring(1);) but there are probably at least a couple more cases that need to be handled for non UPC-A barcode
Asa
@asapdx
Aug 03 2016 23:57
yeah
Andy Theuninck
@gohanman
Aug 03 2016 23:57
I'm assuming weight 12.34lb still comes through as either 111234 or 1441234
Asa
@asapdx
Aug 03 2016 23:57
I can test non-UPC-A barcodes too