Longshot: TI-500 Series Indicators firmware


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!)



Reply to
Don Y
Loading thread data ...

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

Reply to

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?")

Reply to
Don Y

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

formatting link

Are they really there ?


Reply to

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! :< )

Reply to
Don Y

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 
 Click to see the full signature
Reply to
Tim Wescott

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!

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.

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". :>

Reply to
Don Y

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?


Reply to

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.

"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...")

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".

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

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)

Reply to
Don Y

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.


Reply to

He is *told* (by the system) that he can move the pallet! How does the indicator know the scale can be "zeroed" (auto-zero is a common feature)? It *sees* that the scale is "stable" (no longer "in motion") and "close to 0". So, the software (in the indicator) can *set* the scale to zero when it detects this condition.

Similarly, (my) software sees weights reported by the indicator. If the report indicates that the scale is "in motion" (let's assume I trust the indicator's opinion on this), then I can just make a note of the reading and wait. After the indicator's reports have indicated "NOT in motion" for some period of time

*and* the weight looks "sensible" (e.g., if it says "3 pounds" then I know it's bogus -- an empty pallet weighs ten times that!) *and* it really does appear stable (not changing), then I can record *that* as the weight, ring a bell, watch for the indicator to show the pallet being lifted off, plus some minimum "inter pallet delay time", then wait for the indicator to once again stabilize at "0" (which I can verify and "rezero", if necessary) before waiting for the next pallet to arrive.

Because the button is part of the indicator. Because the indicator is "precious" (not particularly expensive, but, if stolen or damaged, seriously impacts the ability to perform WORK!) and needs to be protected from weather, theft, abuse (what if the forklift driver backed into the indicator "accidentally"? What if someone was careless with a pallet jack and let the jack's handle fall onto the indicator? What if some snotnose brat took a baseball bat to the indicator -- as has happened to some of the windows, security cameras, etc.?)

And, because the driver doesn't *need* to press the button! (see above)

Customer is a charity. They are *thrilled* to find someone who can actually *talk* to the indicator/scale and isn't going to charge thousands of dollars to design an interface and software to record and log these weighings over the network, etc. ("We tried to find a cable that would plug into the 'scale' and into one of our PC's. But, when we plugged it in, nothing happened!")


If you do any significant amount of "value added" work with charities (i.e., anything beyond simple "physical labor" -- even if it isn't very *taxing* physical labor!), you'll see that charities always want far more than you are "willing" to give. It's the nature of the beast -- they can't force you to do something (you aren't an employee!) but they will try REAL HARD to get as much as they can from you. The only alternative is to wait and hope that someone similar comes along, "soon".

Or, live "without" -- and accept the consequences that this entails.

[Also, "Charity B" will try to capitalize on noticing your involvement with "Charity A" to get "something for nothing" -- if they can. For much the same reason that making a cash donation to charity X will quickly put you on the "begging list" for every other charity in the world!! :< ]

The other part of being a charity/nonprofit is they tend to hold onto pennies that a business person would quickly spend in a

*logical* cost/benefit analysis. Simply because they don't *have* those pennies to spare (i.e., need them for other things -- like paying for utilities, etc.).

This often leads to really insane behaviors. E.g., having folks

*hand carry* items off a truck instead of using a forklift (because you don't have money to devote to the purchase and maintenance of a forklift -- but, can get "bodies" from unskilled volunteers, community service workers, etc.)

E.g., it will be a pitched battle getting them to realize they

*must* purchase a better indicator. And, a fair bit of my time to do the market research to identify such an indicator. Then, convincing them that they need one for each weighing platform ("Why can't we *share* one? Can't you design something that allows one indicator to service all the platforms? What do we do with the old indicators? Surely not THROW THEM AWAY???!")

Everyone should spend some time with a non-profit! It gives you a *great* appreciation for how *good* life is at your current employer/client!! :-/

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.