Hi,
I designed a system to track "weighings" at a local non-profit. I.e., "talk to" electronic pallet scales and record the weights of items on those scales.
Scales consist of a "weighing platform" (i.e., the size of a large wooden pallet) outfitted with loadcells. These are excited by the "digital indicator" and weight displayed on a set of 7seg displays.
I suspect, "as an afterthought", a serial interface was incorporated into the indicators ("Hey, there's a couple of spare I/O pins on the MCU! Why don't we add a serial interface as a FEATURE??!") In theory, this allows the indicator to convey weight information to external devices (printers, computers, etc. -- there are several different output protocols supported).
But, as proof (?) that this was an afterthought and not clearly designed in from the start, the protocols all exhibit gross shortcomings. E.g., in the "demand" (full duplex) protocol, the indicator responds to "commands" from an external host.
Unless it doesn't want to. (!)
[Fine, you can't walk and chew gum at the same time. I understand. It must be *tough* counting pulses from an integrating A/DC! The idea that you might actually have to listen to a serial port *while* doing that must be terrifying!!! :-/ ]Unfortunately (for me and anyone who wants to "talk" to such a device), the interface specification doesn't even tell you how you can *determine* if the indicator WON'T respond to your command! For example: "The indicator will respond within XXX ms of an issued command IF IT WILL RESPOND AT ALL" So, a host could implement a simple timeout and then retry the command.
[As currently written, the host has no way of knowing when it is safe to reissue the command -- or, issue a *different* command! There is no way to know if a reply is associated with command A or command B!] [Did I mention, "as an afterthought"?]There are other problems with each of the protocols supported. I.e., there is no way one could design a VALIDATABLE system that employs such an indicator. It doesn't have concrete specifications!
Ideally, I'd like to find someone who's had eyes on the actual codebase. Or, *successfully* interfaced one of these with a remote host (think "unattended operation") to see what missing details could be brought to light. I can't count on anyone with technical expertice being around to sort out why the indicator isn't responding, etc. (and I am trying to gracefully extricate myself from most of my volunteer obligations)
I've tried contacting the manufacturer but they don't even understand the nature of the questions I've posed. Something about "rising to their level of incompetence" comes to mind...
[Did I mention, "as an afterthought"?]It's just a little dinky 8051 so I could probably reverse engineer the thing in a matter of a few days. And, *add* the hooks that the product is obviously missing. But, that's a waste of time -- easier to spend that time arguing that they should purchase a different indicator (they'd need a few). Or, convince some "angel" to donate that purchase price/item. Of course, that involves money and it seems that non-profits *always* have a reason to NOT spend money.
(sigh) Heaven save us from marketeers who *specify* products! (and engineers who blindly act on those specifications!)
Thx,
--don