Forums

Longshot: TI-500 Series Indicators firmware

Started by Don Y August 15, 2013
Hi Rick,

On 8/17/2013 12:26 PM, rickman wrote:
> On 8/16/2013 5:05 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?
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.
> Before taking a weight reading, doesn't he need to back the forklift > away from the pallet? Why is the button in another room?
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)
> 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.
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!") [D'uh...] 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!! :-/