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