There’s nothing in the log about the crash?
Yep. Now delete your attachment as your email is in the log.
Did the SambaPOS exception window popup?
No. It just closed after about 5 seconds.
Hmm. This should be fun to track down. I have some things to tend to this evening, so I will try and investigate tomorrow.
For shits and giggles, could you peek in the windows event log and see if there’s anything in there around the time of the crash? I assume the time it happened is the last in the log: 2022-05-18 08:33:49. Thanks.
All good, no time pressure at all.
There were a couple of events - attached.
Event Viewer.zip (1.5 KB)
Super, thanks for that. It was an IndexOutOfRangeException which means I probably fat fingered some array comparison… which I did. I’m surprised SambaPOS’ global exception handler didn’t catch it. Hmm…
I’ve fixed it in the module but what I’m going to do is back port the handling to the test app we were using so we can gather data outside the POS for now until I see what the status bytes are being sent and what not.
I’ll try and get that back to you today so we can continue testing.
Well, as you’ve guessed I didn’t get back to you the same day. Sorry to keep you hanging.
Here’s the lasted build of the test app.
Whenever you have time, snag some more test data for me, please.
Take your time as my plate is rather full in the next coming days; I most likely won’t be able to back in straight away.
TestingPosScale.zip (281.7 KB)
No worries, it’s all good. I appreciate your time and efforts.
Here’s the logs from the latest tests. The weights are all correct until I check ‘Emulate POS’. In the second log the D’s are a negative weight.
log (2).zip (10.8 KB)
log.zip (3.9 KB)
Yeah, I forgot to remove that setting 
I’ll take a look at things in the next day or two and will update then.
In addition to the weight, if the scale isn’t ready is it sends a control byte then a status byte. In that second byte are encoded 8 boolean values (0/1) (an old-school trick) relating to the devices state.
WHat I’ve done is if there’s no match to the regex, the init string will be sent again. I’ve put in place some guards to prevent runaway communication - once a menu item is added to the ticket, the possibility of a retry ceases - same if it’s in a retry loop and the ticket screen is no longer active.
Let me know how it goes.
BT.SambaModules.MettlerToledoVivaScale_0.9.0.6.zip (28.6 KB)
The weights are coming through correctly now which is awesome 
If I put something on the scale then press the ‘Scale’ button the weight in the number box changes, e.g. 00.135 will change to 0.135, 00.13, 00.135 etc. I’ll try and attach a video so you can see.
https://drive.google.com/file/d/1UAfLfVyiZlqXTDgcheR51Af7kgDAA1Tw/view?usp=drivesdk
Log file as well:
scale_log (6).zip (40.3 KB)
2022-05-25 11:10:35.120 [DEBUG] HEX string: [30 30 2E 31 33 35 0D]
0 0 . 1 3 5 CR
2022-05-25 11:10:35.122 [DEBUG] Decoded bytes: [00.135
]
--------------------------------------------------------------------
2022-05-25 11:10:36.061 [DEBUG] HEX string: [30 30 2E 31 33]
0 0 . 1 3
2022-05-25 11:10:36.062 [DEBUG] Decoded bytes: [00.13]
--------------------------------------------------------------------
2022-05-25 11:10:41.574 [DEBUG] HEX string: [30 2E 31 33 35 0D]
0 . 1 3 5 CR
2022-05-25 11:10:41.576 [DEBUG] Decoded bytes: [0.135
]
--------------------------------------------------------------------
2022-05-25 11:27:23.832 [DEBUG] HEX string: [30 30 2E 31 33 30 0D]
0 0 . 1 3 0 CR
2022-05-25 11:27:23.833 [DEBUG] Decoded bytes: [00.130
]
The hex decodes to 00.130 and 00.135 - at times the weight registered as one, sometimes the other. For the missing leading or trailing 0 that’s what was received from the scale. I’ve annotated under the HEX values the corresponding ASCII char and it all matches up.
But looking at the log, I think I messed up the retry logic. That or you’re able to hit the button every 100-200ms.
Give this a shot and see if the scale amount stays static when placed in the input text box on the POS then shoot me the log when you can.
BT.SambaModules.MettlerToledoVivaScale_0.9.0.7.zip (28.7 KB)
If this was the final build I would be happy enough 
The only issues were that 0.335 would show up as 0.33 but if I press ‘Scale’ again it comes right.
The second thing was that if I change the product on the scale (so a different weight) when I press ‘Scale’ the weight that came up was the previous one. If I pressed ‘Scale’ again it would come right. So 0.235 would change to 0.135.
scale_log (7).zip (40.9 KB)
I think I’ve got the issue sorted. The 0.33 was matched, but there was a control char at the beginning. So if a response starts with a control char, it’ll resend the init string and wait for a match. Even though, the docs say the weight sent starts with the control char. Who knows.
For the 0.235 to 0.135 the control char was found at the end of the response, so I check for that, too, and retry if found. But 0.235 was sent from the scale for whatever reason.
BT.SambaModules.MettlerToledoVivaScale_0.9.0.8.zip (29.5 KB)
1 Like
Indeed you do have it sorted!!!
It now works flawlessly!!!
Thank you so much for all your help, I owe you one. Cheers!
scale_log (8).zip (43.2 KB)
1 Like
Glad to hear it’s working.
Here’s the (hopefully) final build. I removed some rethrowing of exceptions and instead just display a popup (show message dialog box) so any communication error won’t be crashing the POS.
Also forgot to flip a bool when everything was done.
Looking at the log, the final entry was 00.00. Now, if the received amount is not greater than 0, no data will be sent to the ticket screen. Unless you’d prefer 0 to show. But that would require user input to clear it.
Let me know if anything comes up.
3 Likes
Still looking good!!!
hello@markjw i have a tma scale. I have connected via com port and its sending weight to putty. when i weigh half kg it displays 0500 continuously going down. When i connect samba am unable to capture that weight to Samba