Longshot: TI-500 Series Indicators firmware

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

On 8/15/2013 2:05 PM, Don Y wrote:
> 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

Would it be too much to ask, whose weighting system you are using ?

Hi Hamilton,

On 8/15/2013 1:37 PM, hamilton wrote:

> Would it be too much to ask, whose weighting system you are using ?

The indicator is made by Transcell Technology (TI-500E, to be
precise).  No idea who manufactured the actual platforms
(my understanding is they just "look" like generic load cells
as far as the indicator is concerned).

I.e., prior to the introduction of my software, these were
standalone devices:  shrinkwrap a pallet, drop it on the
"scale" (weighing platform), read off the weight (with your eyes),
write it down on a piece of paper, lather, rinse, repeat...

When the folks doing this are:
- developmentally disabled
- (very!) senior citizens (can you spell Alzheimer's?)
- disinterested "citizens" performing "community service"
   in lieu of paying a fine (or jail time)
etc. you tend not to have much faith in the quality of the
measurements (weighings) they make!

Or, if they even *bother* to weigh the items!

("Gee, the shipper is billing us for 17.3 tons but the
recorded weights only total 5.6 tons... who's at fault?")

On 8/15/2013 2:45 PM, Don Y wrote:
> Hi Hamilton,
>
> On 8/15/2013 1:37 PM, hamilton wrote:
>
>> Would it be too much to ask, whose weighting system you are using ?
>
> The indicator is made by Transcell Technology (TI-500E, to be

The manual seems to indicate an RS-485 port or a 4-20ma output.

http://www.icscale.com/TI-500%20Series%20Indicators.pdf

Are they really there ?


hamilton

Hi Hamilton,

On 8/15/2013 2:01 PM, hamilton wrote:
> On 8/15/2013 2:45 PM, Don Y wrote:
>> Hi Hamilton,
>>
>> On 8/15/2013 1:37 PM, hamilton wrote:
>>
>>> Would it be too much to ask, whose weighting system you are using ?
>>
>> The indicator is made by Transcell Technology (TI-500E, to be
>
> The manual seems to indicate an RS-485 port or a 4-20ma output.
>
> http://www.icscale.com/TI-500%20Series%20Indicators.pdf
>
> Are they really there ?

It's an EIA232 port -- 2 wire (plus ground), only.  While the
TxD signal is present in each protocol configuration, the
"return" signal varies in functionality.  E.g., sometimes it
is RxD and other times it acts as a pacing lead.

[I've not checked the current loop output]

Interface is *there* and "working" - to the extent that they
claim it *will* work.

E.g., I can get "continuous" reports from the indicator in simplex
mode.  "The transmission occurs at the end of each display update"
(of course, the "display update" is poorly defined).

But, if the indicator has been configured for one of the other
two modes, there is no way for the host to determine this!
(this can happen if someone messes with the indicator.  Or, if
the indicator spontaneously decides to reconfigure itself --
which has been known to happen)

So, if the host (which expects the indicator to be operating in
simplex mode) doesn't receive a report in ??? time (whatever
the worst case "display update" cycle might be?), it can't
decide if the indicator is misconfigured, failed or disconnected!

E.g., I attempt to send a "command" to the indicator in case it
might be operating in "full duplex" mode.  If I then receive a
reply IN THE FORM OF A FDX REPLY, then I know the indicator is
operating in FDX mode.  I can display a message to that effect
and provide directions so a "responsible user" could reconfigure
the indicator, appropriately (e.g., simplex mode).  And, verify
those actions while the user is present!

Until the user arrives, I can operate in an impaired mode by
repeatedly issuing commands to the indicator that should cause
it to report the current "weight".  I.e., the system is still
usable!

But, I can never know if a command has been received or not.
Or, if the indicator was busy "chewing gum" and couldn't handle
my request at that time (so, when do I retry the command??)

If the indicator doesn't respond to *any* commands (see the
point of not having positive feedback about "dropped commands"?),
it could be configured in the "print ticket" mode.  As such,
I could prompt the user to depress the PRINT button on the
indicator.  If I then encounter a report in "print ticket
format", I would know that the printer has been erroneously
configured for that protocol and could direct the user to
change the configuration -- and verify the success of his actions!

[Or, instruct him to press PRINT each time he needs to feed a
weight to me...]

As it stands, currently, all I can do is set a timer that
will expire in some time longer than the longest display
update interval -- and display a "check engine" error if
I don't see a valid report in that time interval.

Then, wait for someone to telephone me and ask me to rush
across town because they need to get a truck loaded "by 5PM".
Needless to say, I don't want to be in this loop!

(No good deed goes unpunished!  :< )

On Thu, 15 Aug 2013 14:46:38 -0700, Don Y wrote:

> Hi Hamilton,
> 
> On 8/15/2013 2:01 PM, hamilton wrote:
>> On 8/15/2013 2:45 PM, Don Y wrote:
>>> Hi Hamilton,
>>>
>>> On 8/15/2013 1:37 PM, hamilton wrote:
>>>
>>>> Would it be too much to ask, whose weighting system you are using ?
>>>
>>> The indicator is made by Transcell Technology (TI-500E, to be
>>
>> The manual seems to indicate an RS-485 port or a 4-20ma output.
>>
>> http://www.icscale.com/TI-500%20Series%20Indicators.pdf
>>
>> Are they really there ?
> 
> It's an EIA232 port -- 2 wire (plus ground), only.  While the TxD signal
> is present in each protocol configuration, the "return" signal varies in
> functionality.  E.g., sometimes it is RxD and other times it acts as a
> pacing lead.
> 
> [I've not checked the current loop output]
> 
> Interface is *there* and "working" - to the extent that they claim it
> *will* work.
> 
> E.g., I can get "continuous" reports from the indicator in simplex mode.
>  "The transmission occurs at the end of each display update"
> (of course, the "display update" is poorly defined).
> 
> But, if the indicator has been configured for one of the other two
> modes, there is no way for the host to determine this!
> (this can happen if someone messes with the indicator.  Or, if the
> indicator spontaneously decides to reconfigure itself -- which has been
> known to happen)
> 
> So, if the host (which expects the indicator to be operating in simplex
> mode) doesn't receive a report in ??? time (whatever the worst case
> "display update" cycle might be?), it can't decide if the indicator is
> misconfigured, failed or disconnected!
> 
> E.g., I attempt to send a "command" to the indicator in case it might be
> operating in "full duplex" mode.  If I then receive a reply IN THE FORM
> OF A FDX REPLY, then I know the indicator is operating in FDX mode.  I
> can display a message to that effect and provide directions so a
> "responsible user" could reconfigure the indicator, appropriately (e.g.,
> simplex mode).  And, verify those actions while the user is present!
> 
> Until the user arrives, I can operate in an impaired mode by repeatedly
> issuing commands to the indicator that should cause it to report the
> current "weight".  I.e., the system is still usable!
> 
> But, I can never know if a command has been received or not.
> Or, if the indicator was busy "chewing gum" and couldn't handle my
> request at that time (so, when do I retry the command??)
> 
> If the indicator doesn't respond to *any* commands (see the point of not
> having positive feedback about "dropped commands"?), it could be
> configured in the "print ticket" mode.  As such,
> I could prompt the user to depress the PRINT button on the indicator. 
> If I then encounter a report in "print ticket format", I would know that
> the printer has been erroneously configured for that protocol and could
> direct the user to change the configuration -- and verify the success of
> his actions!
> 
> [Or, instruct him to press PRINT each time he needs to feed a weight to
> me...]
> 
> As it stands, currently, all I can do is set a timer that will expire in
> some time longer than the longest display update interval -- and display
> a "check engine" error if I don't see a valid report in that time
> interval.
> 
> Then, wait for someone to telephone me and ask me to rush across town
> because they need to get a truck loaded "by 5PM". Needless to say, I
> don't want to be in this loop!
> 
> (No good deed goes unpunished!  :< )

If it works OK in simplex mode, and if an interested user can reprogram 
the indicator when it's messed up, just do your "check engine light" 
thing.  Maybe post instructions above each scale in BIG LETTERS going 
through the procedure to set the scale to simplex mode.

Then move out of town.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Hi Tim,

On 8/16/2013 11:05 AM, Tim Wescott wrote:

>> As it stands, currently, all I can do is set a timer that will expire in
>> some time longer than the longest display update interval -- and display
>> a "check engine" error if I don't see a valid report in that time
>> interval.
>>
>> Then, wait for someone to telephone me and ask me to rush across town
>> because they need to get a truck loaded "by 5PM". Needless to say, I
>> don't want to be in this loop!
>>
>> (No good deed goes unpunished!  :< )
>
> If it works OK in simplex mode,

Ah, but I can't be sure!  Because nothing specifies how often a
display update cycle will occur, I can't *knowingly* determine
a timeout value.  All I can do is pick some insanely long time
and *hope*.

E.g., if the load cells are disconnected, is the display updated
at the same rate?  Or, does the display update cycle terminate
until the indicator detects the reconnection of the load cells?

There is also no way to prevent the user from pushing buttons
on the front panel and, for example, rezeroing or taring the
indicator.  And, no reliable way of detecting this from the
"report" that the indicator supplies to the host.

There is nothing that describes what the interface will report
in various error conditions:
- NVRAM read/write error
- calibration error
- disconnected load cell
etc.  (those are only the scenarios that I can *imagine* without
having a peek at the code -- none of these are formally described
wrt the interface and its reports)

[Did I mention "afterthought"?]

I have *personally* configured and calibrated the indicator.
Then, attached the access plate that guards access to these
features/modes with "painted" screws (i.e., so *I* can detect any
tampering) only to get a call a few weeks later that the "scale"
has gone screwwy.  ("Ah, someone must have gone poking around
'inside'!")  Yet, when I inspect the indicator, the paint seals
are undisturbed -- but the indicator is very definitely operating
under a different configuration!

> and if an interested user can reprogram
> the indicator when it's messed up, just do your "check engine light"
> thing.  Maybe post instructions above each scale in BIG LETTERS going
> through the procedure to set the scale to simplex mode.

I currently have located the indicator high above a doorway
(keeps people from pushing the buttons on the front panel).
This makes reconfiguration/calibration difficult (you need
to stand on a tall ladder to access the indicator).  My
software mimics the calibration, zero, tare, etc. tasks
(trivial).  But, will only work if I know how the indicator
will behave in each possible scenario.  The folks who documented
(and implemented) the interface didn't approach it as a
reliable, predictable interface.

> Then move out of town.

Easier to just convince them to "acquire" an indicator that isn't
a "toy".  Then, I can live where I want and they can still get
what they need from the "system".  :>

On 8/15/2013 5:46 PM, Don Y wrote:
>
> If the indicator doesn't respond to *any* commands (see the
> point of not having positive feedback about "dropped commands"?),
> it could be configured in the "print ticket" mode. As such,
> I could prompt the user to depress the PRINT button on the
> indicator. If I then encounter a report in "print ticket
> format", I would know that the printer has been erroneously
> configured for that protocol and could direct the user to
> change the configuration -- and verify the success of his actions!
>
> [Or, instruct him to press PRINT each time he needs to feed a
> weight to me...]

There you go, problem solved.  The user has to load the item to be 
weighed onto the scale platform and then press a button to cause the 
weight to be taken.  What could be simpler?  I'll provide an address 
where you can send the check...

As to the timeout, I think you are being a bit retentive.  If they don't 
spec a timeout, measure normal operation in every mode you can think of 
and double or triple that amount.  I assume we are talking about 
milliseconds and not seconds?  Although, a scale may take a few seconds 
to stabilize, so it might be seconds, but not 10's I hope.  So what if 
it takes 10 or 15 seconds for the system to figure out the scale isn't 
responding?

-- 

Rick

Hi Rick,

On 8/16/2013 12:47 PM, rickman wrote:
> On 8/15/2013 5:46 PM, Don Y wrote:
>>
>> If the indicator doesn't respond to *any* commands (see the
>> point of not having positive feedback about "dropped commands"?),
>> it could be configured in the "print ticket" mode. As such,
>> I could prompt the user to depress the PRINT button on the
>> indicator. If I then encounter a report in "print ticket
>> format", I would know that the printer has been erroneously
>> configured for that protocol and could direct the user to
>> change the configuration -- and verify the success of his actions!
>>
>> [Or, instruct him to press PRINT each time he needs to feed a
>> weight to me...]
>
> There you go, problem solved.  The user has to load the item to be
> weighed onto the scale platform and then press a button to cause the
> weight to be taken.  What could be simpler?  I'll provide an address
> where you can send the check...

Does the forklift operator have to position the pallet on the
scale; turn off the forklift (safety); climb down off it and
walk *inside* the building to the indicator's location just to
press a button.  (you don't want the indicator to get rained
upon; nor STOLEN!  yet, you want the 4ft x 4ft weighing platform
to remain outdoors so the forklift doesn't have to enter the
building to place pallets onto the platform...) just to press
the button.  Then, head back out, start up the forklift and remove
the pallet...

What if they *don't* press the button?  What if they press it
while the scale is still "in motion"?  Or, in overload?  Or...

I.e., none of the defined interface protocols (including the
"Print Ticket" protocol) are fully defined.

> As to the timeout, I think you are being a bit retentive.  If they don't

"Being retentive" is what gives my designs robustness and bug-free
implementations!  Making ASSUMPTIONS is what leads most software
and systems down a path of perpetual "fixes" ("Gee, I didn't
*think* that could happen...")

> spec a timeout, measure normal operation in every mode you can think of
> and double or triple that amount.

How do I *know* what the update period is?  E.g., if the scale is
configured for a long integration period, then the update interval
is slower.  What if an error condition exists?  Does the indicator
get updated at all?  How long after the error condition is rectified
does the indicator take to recover?

I.e., when you define AN INTERFACE, you define *everything* about
the interface.  Not just the "general characteristics".

> I assume we are talking about
> milliseconds and not seconds?

Think fractions of a second.  E.g., a few to dozens of updates
per second.

> Although, a scale may take a few seconds
> to stabilize, so it might be seconds, but not 10's I hope.  So what if
> it takes 10 or 15 seconds for the system to figure out the scale isn't
> responding?

So the forklift operator sits around waiting.  And wondering.
Will a message appear 10 seconds from now saying "scale inoperative"?
Does the system even *know* that I have placed something on the
weighing platform?  Is that *apparent* motion that the indicator
*thinks* it is seeing genuine "signal"?  Or, is it noise getting
into the front end because someone ran over the cable that connects
the weighing platform to the indicator?

All this because someone didn't know what they were doing when
they added a half-thought-out "feature" to a device?

Sure seems easier to just find an indicator that was designed
with these issues in mind from the start!  (Or, hack the
existing indicators so they behave predictably)

On 8/16/2013 5:05 PM, Don Y wrote:
> Hi Rick,
>
> On 8/16/2013 12:47 PM, rickman wrote:
>> On 8/15/2013 5:46 PM, Don Y wrote:
>>>
>>> If the indicator doesn't respond to *any* commands (see the
>>> point of not having positive feedback about "dropped commands"?),
>>> it could be configured in the "print ticket" mode. As such,
>>> I could prompt the user to depress the PRINT button on the
>>> indicator. If I then encounter a report in "print ticket
>>> format", I would know that the printer has been erroneously
>>> configured for that protocol and could direct the user to
>>> change the configuration -- and verify the success of his actions!
>>>
>>> [Or, instruct him to press PRINT each time he needs to feed a
>>> weight to me...]
>>
>> There you go, problem solved. The user has to load the item to be
>> weighed onto the scale platform and then press a button to cause the
>> weight to be taken. What could be simpler? I'll provide an address
>> where you can send the check...
>
> Does the forklift operator have to position the pallet on the
> scale; turn off the forklift (safety); climb down off it and
> walk *inside* the building to the indicator's location just to
> press a button. (you don't want the indicator to get rained
> upon; nor STOLEN! yet, you want the 4ft x 4ft weighing platform
> to remain outdoors so the forklift doesn't have to enter the
> building to place pallets onto the platform...) just to press
> the button. Then, head back out, start up the forklift and remove
> the pallet...
>
> What if they *don't* press the button? What if they press it
> while the scale is still "in motion"? Or, in overload? Or...
>
> I.e., none of the defined interface protocols (including the
> "Print Ticket" protocol) are fully defined.
>
>> As to the timeout, I think you are being a bit retentive. If they don't
>
> "Being retentive" is what gives my designs robustness and bug-free
> implementations! Making ASSUMPTIONS is what leads most software
> and systems down a path of perpetual "fixes" ("Gee, I didn't
> *think* that could happen...")
>
>> spec a timeout, measure normal operation in every mode you can think of
>> and double or triple that amount.
>
> How do I *know* what the update period is? E.g., if the scale is
> configured for a long integration period, then the update interval
> is slower. What if an error condition exists? Does the indicator
> get updated at all? How long after the error condition is rectified
> does the indicator take to recover?
>
> I.e., when you define AN INTERFACE, you define *everything* about
> the interface. Not just the "general characteristics".
>
>> I assume we are talking about
>> milliseconds and not seconds?
>
> Think fractions of a second. E.g., a few to dozens of updates
> per second.
>
>> Although, a scale may take a few seconds
>> to stabilize, so it might be seconds, but not 10's I hope. So what if
>> it takes 10 or 15 seconds for the system to figure out the scale isn't
>> responding?
>
> So the forklift operator sits around waiting. And wondering.
> Will a message appear 10 seconds from now saying "scale inoperative"?
> Does the system even *know* that I have placed something on the
> weighing platform? Is that *apparent* motion that the indicator
> *thinks* it is seeing genuine "signal"? Or, is it noise getting
> into the front end because someone ran over the cable that connects
> the weighing platform to the indicator?
>
> All this because someone didn't know what they were doing when
> they added a half-thought-out "feature" to a device?
>
> Sure seems easier to just find an indicator that was designed
> with these issues in mind from the start! (Or, hack the
> existing indicators so they behave predictably)

Let's talk system design here.  Ignoring the issues of the devices and 
implementation, how do you see the system working?  If the operator 
isn't going to press a button, how is he to know that the weight has 
been taken and he can move the pallet?

Before taking a weight reading, doesn't he need to back the forklift 
away from the pallet?  Why is the button in another room?

I'm going to ignore your statements about system robustness because you 
also have to make the system work.  Sometimes there are tradeoffs that 
have to be made.  If the customer wants it done some way you don't like 
(or I should say I don't like because I am projecting my work 
environment on the situation) I don't get a choice and do it the way the 
customer wants.  I let them know the issues and they have to accept 
responsibility.  End of decision.  Just make sure they know they are 
making a potentially bad decision.  God, how many times have I been in 
that position.  I've had to bite my tongue so many times because I 
warned the customer and then it went sour, but after all, they are 
always right.

-- 

Rick