Hi MathTalk. I would like to know if we can institute the process for
using 3 different color lights on the same room- When an order is
entered the first light would go on (Green), 10 min later the the
green would shut off and an orange light would go on, 20 min later the
orange light would go off and a red light would go on. let me know
what you think.
Thank you very much mathtalk |
Request for Question Clarification by
mathtalk-ga
on
22 Apr 2004 07:53 PDT
Hi, Amy:
A very interesting challenge!
As the application design is evolving, we've been increasingly putting
functionality into a client/server (two-tier) architecture. Although
we introduced the Access database for password management, this is
local to the client at this point. In principle we can continue to
manage three colored lights per room on a similar basis, though in my
opinion the increasingly complex "state" for rooms adds to the
argument using a shared database to store this information.
Do you have some ideas for the hardware to run these colored lights?
A simple approach would be to use three "ports" on the World 1 box per
room, but I suspect you've already done some legwork to find
alternatives.
regards, mathtalk
|
Clarification of Question by
amy123456-ga
on
22 Apr 2004 14:17 PDT
Hi Mathtalk. i like simple. Do you think your suggestion is possible?
Thank you
|
Request for Question Clarification by
mathtalk-ga
on
22 Apr 2004 14:30 PDT
I think we'd need about three times as many ports on the World 1/2
box, but let's revisit their product line and see what they've got.
In the meantime I post a Comment tonight on what needs to be modified.
For example the "worldmap" will change because we're storing more
information about the status of a room/patient/light. In particular
we'll need to store some time information (when the order is entered)
to track the progression of colors.
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
22 Apr 2004 19:34 PDT
Hi MathTalk. Just so you know, the LED's that i am looking at has build in
the 3 colors, green, orange and red, so it will only be one light and not 3.
|
Request for Question Clarification by
mathtalk-ga
on
23 Apr 2004 09:24 PDT
Hi, Amy:
Maybe you could point me to a Web page where these are spec'd.
In principle only two bits of information are need to dictate the
state of the light "cluster" per room:
Off, Green, Orange, Red
(four possibilities = 2 bits)
So clever hardware packaging would allow such a unit to be controlled
with two digital lines, rather than three.
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
23 Apr 2004 13:39 PDT
http://www.superbrightleds.com/
|
Request for Question Clarification by
mathtalk-ga
on
23 Apr 2004 16:21 PDT
Hi, Amy:
I'm guessing that you have in mind a red-green bicolor (or possibly
RGB tricolor) LED package.
Mixing of red and green signals results in a kind of orange/yellow
appearance (the absence of blue).
This would allow for two digital lines per room/light.
I saw a tricolor RGB package at the site you linked above, but not a bicolor one.
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
24 Apr 2004 17:24 PDT
Hi MathTalk. What do you think of maybe just making the lights that
we currently have blink after a determined time of being on. Would
that be a more visible approach? Please let me know thoughts.
Thank you
|
Request for Question Clarification by
mathtalk-ga
on
25 Apr 2004 09:31 PDT
Hi, Amy:
That's a pretty neat idea, which would amount to trading off extra
programming vs. extra hardware.
In most cases the rule is "hardware is cheap" and my guess is that the
extra effort of programming to do the blinking is truly "greater" than
the cost and effort associated with the extra hardware to do color.
If I were going to do the blinking, my first thought is to create one
or more threads which are responsible for managing the serial port.
This would allow us to encapsulate the "blinking" response in a layer
outside the text extract/file processing which dominates the switchbox
(textextract1) application currently.
In comparison the color progression would not require such a big
change in the program structure, but more of an adjustment to the
"mapping" of rooms & colors to bytes sent down the serial port.
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
26 Apr 2004 14:37 PDT
I do not know what to do now!
|
Request for Question Clarification by
mathtalk-ga
on
26 Apr 2004 15:38 PDT
Hi, Amy:
In project management we talk about the "iron triangle" of quality,
resources, and time. [Sometimes the resources can be further broken
into separate dimensions of people (e.g. programmers) and capital
budget (e.g. hardware acquisitions).]
It's hard for me to give you advice because I'm poorly informed about
the constraints and objectives you are dealing with. But to be fair
to yourself in trying to manage this project, you should get some
answers for your own planning to the "iron triangle" questions:
Quality: How well does this work need to be done? Certainly you want
the system, to work pretty well once installed, without especially
heavy intervention on your part to keep it running, but it's not as
critical as a heart/lung machine or any of a number of other systems
that might be found in a hospital. So it's only worthwhile to design
and execute a reasonably useful system, not a "six sigma" quality
assurance deal.
Resources: What resources do you have for this project?
Time: Some tasks have hard deadlines, like turning in a proposal for
a government contract. If the proposal is a minute late, you might as
well throw it in the trash. But this is not the usual circumstance.
In the "real world" every problem has an existing solution, and the
project's aim to provide an improved solution, hopefully a substantial
improvement in relation to the resources being expended. But as a
rule it's more important to provide more quality at the expense of
more time, because the "solution" warts and all will presumably be in
place a long time. As a practical matter there will be tweaks to the
performance of a system as inconveniences/bugs are discovered (as with
the request to change to user ID/password textbox handling).
You are in the best position to gather all the information and make a
plan. Some of the decisions, of course, have to be made in concert
with your supervisors/clients for this project. I'll be happy
contribute some ideas, but I want you to be aware of my limited
perspective.
If you want to do the blinking lights, it will certainly involve more
programming. The colored lights are actually some additional
programming but more so a matter of duplicating some of the existing
code and the existing hardware to provide the suggested functionality.
You will need to help your "customers" understand where the greatest
benefit for their investment of time and resources lies, within a
parameter of acceptable risk.
Your idea potentially provides measureable improvements in patient
care for a limited outlay. Part of your challenge is to wait until
next steps are clearly beneficial before committing to additional
outlays. If the system is useful as is, then it may be wise to give
it a little "breathing room" until it is clear whether the colored
lights (or blinking lights) will have a "payback" in whatever terms
you consider realistic. Once you have a vision of the next steps, I'm
sure you'll be able to convince others to follow your lead!
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
27 Apr 2004 03:52 PDT
Hi mathTalk. What do you think of just making the lights blink from
the start instead of just lighting up.
thank you
|
Request for Question Clarification by
mathtalk-ga
on
27 Apr 2004 06:28 PDT
Hi, Amy:
The blinking of lights can either be controlled by the computer
(adding some new programming) or by installing new lights that blink
on their own (the hardware solution!).
I'll assume you're asking about the first approach. To keep the
software structure "clean" we need to delegate the cycles of light
on/light off to a separate "task" (thread), which shares information
with the main program thread about the status of rooms but maintains
its own timing for cycling through the lights. All the lights on the
board can be updated in less than 1/10 second by writing five bytes to
the serial port, so in the simplest case it will appear that all the
lights that are on are blinking together.
This sort of programming raises (well-understood) issues about how two
threads can share data without stepping on one another. Here the main
thread needs to both read and write information about the status of
(outstanding orders for) rooms, while the "worker" thread only needs
read access to that data. Even in this simple case it's best to set
up a "latch" to protect the data from being written and read by both
threads in an overlapping and potentially inconsistent state (although
the consequences of inconsistency here would be very minor).
Once the code for the separate "worker" thread is set up to manage
blinking, it would be possible to enhance that function to provide
blinking lights at various rates.
If you still have your "test platform" equipment, it might be a good
idea to start with a simple program that creates a worker thread and
manages the blinking of one light (depending on a simple data item
shared with the main program that determines off or on). This would
probably give you a good deal of insight into how the Switchbox
application will need to be modified (by adding one or more worker
threads) to support blinking.
On the other hand one can buy light bulbs that blink at their own
rates. In some ways this might be a more attractive solution as the
blinking of lights would be unsynchronized. And no programming!
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
28 Apr 2004 14:28 PDT
I might just use your suggestion, blicking lights. unless we can come
up with something different.
Thank you
|
Clarification of Question by
amy123456-ga
on
29 Apr 2004 04:17 PDT
Hi MathTalk. How much work is involed in your approach as far as
coding is concerned. I will arrange for 3 world 1 and i am going to
buy the 3 different color lights, for each light color. If your ok
with this, please let me know and we will move forward.
Thank you very much MathTalk.
|
Clarification of Question by
amy123456-ga
on
29 Apr 2004 10:08 PDT
Hi MathaTalk. question in reference to the txtxtrct.log.
4/29/2004 12:38:07: Lights On - 16|EVELYN|COLEMAN|
4/29/2004 12:40:10: Room number 16 cleared by amy
4/29/2004 12:51:18: Lights On - 16|EVELYN|COLEMAN|
On the interface to turn the ligts off, The txtxtrct.log line 2, how
can i change the text from room number to lights off.
I was able to change the text when an order is processed (line 1) to lights on.
Thank you mathTalk
|
Request for Question Clarification by
mathtalk-ga
on
29 Apr 2004 11:12 PDT
Hi, Amy:
As far as changing the wording for the "Lights off" log entries, the
simplest thing would be to change the Order Fulfillment application.
If you look there, you'll see that the time & text that winds up in
the log (after textextract/switchbox has FolderSearch'd it) is just
the line that was written into a .PRN file by Order Fulfillment.
Change it there and nothing extra will need to be changed in the
textextract code.
I'll spend some time tonight estimating how much work would be needed
to revise the switchbox application to manage the time and color
dimensions.
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
30 Apr 2004 05:13 PDT
Hi MathTalk. Is this the location in order Fulfillment
string textToWrite = dt.ToString("G")
+ ":Lights Off - " + ss + " cleared by "
+ userid + "\r\n";
I changed it, but it still prints out as Room number.
Thank you
|
Request for Question Clarification by
mathtalk-ga
on
30 Apr 2004 06:43 PDT
That looks like it. Of course after you recompile, you may need to
move the executable to where the user's are running it (on various
machines). It will not change the appearance of any pre-existing log
entries.
You can test your change as a "stand alone" by running Order
Fulfillment and viewing the contents of the .prn files that it
produces.
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
30 Apr 2004 08:07 PDT
Thank you
|
Request for Question Clarification by
mathtalk-ga
on
02 May 2004 17:32 PDT
Hi, Amy:
See bottom Comment for a more detailed "plan of attack".
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
02 May 2004 18:59 PDT
Hi mathTalk. I spoke to the people at world 1 about the problem and
they have suggested some solutions, Please look at this web page that
was created with
what they sugest.
http://www.ccielectronics.com/ch_files/ch_frames.htm
Please let me know your thoughts
thank you
|
Request for Question Clarification by
mathtalk-ga
on
04 May 2004 07:50 PDT
Hi, amy123456-ga:
The proposed hardware approach (manufacturing some custom cards that
would manage the lights, including color/timing, autonomously
downstream of the World 1/serial port connection) would certainly
minimize any programming changes; I think it would obviate them.
I'm not sure what your budget is. Typically the setup costs, which I
must say in this proposal seem modest, almost to the point of being
too low, are too high for a "one-off" project. The hardware/custom
manufacturing route has in the past been the preserve of projects that
plan to roll-out at least several dozen systems (or a smaller number
of systems with sufficiently high price tags). I'll have to let you
be the judge of the cost/value constraints here.
One disadvantage of an early decision to put functionality into
hardware rather than software is that it limits flexibility as a
project progresses. I lack much perspective on how far the requested
changes to the order fulfillment/light switchbox project can be
expected to go, so I'll just make the point that while functionality
is being managed in the software, it is relatively easy to change, at
least compared with "dedicated" hardware that can only perform the
functionality in one way (or with a set range of options).
Perhaps the "prototyping in software" phase has reached the point in
your project where it makes sense to begin migrating functionality to
custom hardware? My impression of the project was that of a fairly
limited implementation, involving perhaps a dozen stations but not
more than that. One often gets a benefit, for much larger projects,
from an initial small rollout that provides a chance to fit the
technology to needs of the users. Scale is an important factor here.
So if I were in your situation I'd be A) reviewing the budget, and B)
trying to anticipate how much future flexibility will be required in
the system design.
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
04 May 2004 10:04 PDT
Hi MathTalk. I see your point. But that does not limit us from advancing the
application for futher anhancements. I am compering the cost of
application versus hardware.
Appication- 1-Code - 200.00
2-World1 - 3 per unit 176x3 = 548.00
3-lights/Wire- 100.00
----------
828.00
Harware - 1-world1 1 per unit 176.00
2-lights/chip/board. 336.00 for 28 lights
3-Design 131.50 total cost 750.00/12=131.50
---------
643.50
Please let me know your thoughts
Thank you
|
Request for Question Clarification by
mathtalk-ga
on
04 May 2004 11:59 PDT
Hi, Amy:
I think the analysis might be clearer if it were divided into "fixed"
and "per unit" costs. By the way, I think that _two_ World 1 boxes
per multi-light switchboard are sufficient; see my most recent Comment
for details. As I envisioned the wiring of the "software based"
multi-light switchboards, there would be a ground wire for each
lamp/LED, and two "live" wires for each (one from either World 1 box).
So under "fixed" costs we could put (for hardware approach) the setup
for printed circuit lamp cards ($750) and on the other hand (for
software approach) the coding costs ($200 is I think the value you've
used for planning).
Under "per unit" costs we would have one World 1 box if the printed
circuit lamp cards are used versus two World 1 boxes if the control is
done in software. We would have some wiring/construction effort in
either case, so for the moment let's treat that (your labor) as a
sunken cost. That leaves as the final big ticket item, I think, the
different materials for the multi-light switchboards. There the
"hardware" approach involves 28 printed circuit cards, while the
"software" approach involves just the bulbs.
Of course this omits such details as how the wiring is done or the
costs of mounting hardware and reflectors, etc. But wire is cheap and
to a large extent the mounting of the printed circuit boards and bulbs
should go quickly, one the first half-dozen or so have been "test
cases".
Supposing that the hardware setup/design and the software development
were even, it would come down mostly to the cost of 28 printed circuit
lamp cards vs. one extra World 1 box. Even in kit form the price they
quoted you for 28 cards was $406, while from the numbers you've cited
it appears a World 1 box is $176. (Note that the multi-color LED
bulbs tend to be priced at a few dollars apiece, at most. In the
quantity you'll need you could certainly get them for $2 apiece or
less.) We can even throw in the cost of a double serial port card for
the "software" side of the analysis, which would be on the order of
$100, if the PC's did not have two serial ports available.
$406 vs. $176 + $56(at most) + $100(if needed)
Hopefully you'll find the analysis a little bit easier with the
"fixed" vs. "per unit" distinction in mind. It appears my cost
analysis for the hardware approach is not as favorable as yours, even
if some extra hardware is added to the software approach. It might be
that maintenance costs are lower for the hardware approach, though it
would be difficult to predict that without a baseline of experience to
back it up.
regards, mathtalk-ga
|
Clarification of Question by
amy123456-ga
on
14 May 2004 11:00 PDT
Hi MathTalk. I am sorry about not getting back to you, I have been
busy building the light boxes for the other floors.
We decide to move ahead with the hardware peice. I would like to open
another question for you about this project again, are you willing? I
hope you are.
You will find the new question posted.
Thank you
|
