S
Stephane Belzile
Is there a way I can detect in vb.Net the power has switched to a UPS
unit in case of power failure?
Thanks
unit in case of power failure?
Thanks
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
N
Nick Malik
Most UPS vendors support a method for communicating the status of their
devices and the power supply. Most of them even have software that they
sell or give away that will monitor your UPS device for power failure, so
that you can shut down a machine.
For large networked systems, you'd use a MIB and SNMP, because the larger
UPS devices can speak over a network. The smaller devices, for personal
computers, often hook up over USB. For that, you will probably be best off
using the software that comes with the UPS. For example, if you have an APC
device, you would use Personal PowerChute, which is a free download from
their web site www.apcc.com
So, I ask, are you trying to do this for a server-sized UPS device that you
can hook to your network, or a smaller unit that you will hook to a
particular machine? If the former, SNMP is your method. If the latter, you
are doing either USB programming (proprietary, in all liklihood) or you can
configure the tools that come with the device to call your app.
Good Luck,
--- Nick
devices and the power supply. Most of them even have software that they
sell or give away that will monitor your UPS device for power failure, so
that you can shut down a machine.
For large networked systems, you'd use a MIB and SNMP, because the larger
UPS devices can speak over a network. The smaller devices, for personal
computers, often hook up over USB. For that, you will probably be best off
using the software that comes with the UPS. For example, if you have an APC
device, you would use Personal PowerChute, which is a free download from
their web site www.apcc.com
So, I ask, are you trying to do this for a server-sized UPS device that you
can hook to your network, or a smaller unit that you will hook to a
particular machine? If the former, SNMP is your method. If the latter, you
are doing either USB programming (proprietary, in all liklihood) or you can
configure the tools that come with the device to call your app.
Good Luck,
--- Nick
S
Stephane Belzile
Thank you Nick
Actually, I'm developping a device that will be connected to the
serial port of thousands of cash registers all over the country. In
fact, I don't know which UPS unit will be in used if there is any.
Since I'm dealing with very sensitive data, I don't want to loose
anything in case of a power failure. I'm know the OS gets notified
when the UPS unit start to deliver the power after a power failure
(You confirmed that). And I'm pretty sure that the OS must send a
message to all running application to let them know. My question is,
how can I pick up this message when it happens or when the power comes
back?
Actually, I'm developping a device that will be connected to the
serial port of thousands of cash registers all over the country. In
fact, I don't know which UPS unit will be in used if there is any.
Since I'm dealing with very sensitive data, I don't want to loose
anything in case of a power failure. I'm know the OS gets notified
when the UPS unit start to deliver the power after a power failure
(You confirmed that). And I'm pretty sure that the OS must send a
message to all running application to let them know. My question is,
how can I pick up this message when it happens or when the power comes
back?
N
Nick Malik
Hello Stephane,
First off, will the device be directly connected to the UPS device, or just
to the cash register? If you are connected directly to the UPS, you can be
notified by it. Otherwise, this is not a UPS question, this is a question
of how you are notified by the OS.
Secondly, is your device designed to connect to many different cash
registers, or a specific model and type of cash register? If so, you may
know what version of the OS that the register is using, and what hardware
features you can count on. Note that there is no reason to believe that all
registers are actually notified by the OS. The fact that the OS *can* be
notified does NOT mean that the register *will* be notified. These are two
radically different things.
http://support.microsoft.com/kb/q310752/
Thirdly, can you put software on the register, or are you simply connecting
to the serial port? If you are not installing software on the register,
then none of this matters, because there would be no application running on
the pc to forward the message on to the serial port where you could detect
it.
It may make more sense for your device to use a simple Lion battery backup
or USB solid state hard drive for data backup than for your device to detect
if the UPS has switched power.
--- Nick
First off, will the device be directly connected to the UPS device, or just
to the cash register? If you are connected directly to the UPS, you can be
notified by it. Otherwise, this is not a UPS question, this is a question
of how you are notified by the OS.
Secondly, is your device designed to connect to many different cash
registers, or a specific model and type of cash register? If so, you may
know what version of the OS that the register is using, and what hardware
features you can count on. Note that there is no reason to believe that all
registers are actually notified by the OS. The fact that the OS *can* be
notified does NOT mean that the register *will* be notified. These are two
radically different things.
http://support.microsoft.com/kb/q310752/
Thirdly, can you put software on the register, or are you simply connecting
to the serial port? If you are not installing software on the register,
then none of this matters, because there would be no application running on
the pc to forward the message on to the serial port where you could detect
it.
It may make more sense for your device to use a simple Lion battery backup
or USB solid state hard drive for data backup than for your device to detect
if the UPS has switched power.
--- Nick
S
Stephane Belzile
Hi Nick,
Our unit is designed to be placed between the cash register and the
printer. It has to listen on the serial communication port of the cash
register to record every transactions that are processed, record it
into a database and send it to the printer with a unique identifier
and a legal stamp. Since it will be used in thousands of stores all
over the country, we will have to support a wide variety of cash
registers models. Using regular expressions specific to each models,
we can easily understand which information is sent to the printer
through the serial port. We don't have to bother over which OS is used
inside the cash register at all. The store manager will have to make
sure his cash register and his printer are supported by our unit. If
the store has a UPS, our unit will have to be connected to it as well
as the cash register.
Since the store owner won't be forced to use a UPS and because he can
use wathever UPS unit he wants if he desires to have one, I can only
rely on my own OS (Win CE or Xp Embedded) running in my Unit to notify
my program that the UPS has started.
The best solution for us would be as you said to put in our module our
own UPS device or battery. In fact, we only need just a few seconds,
not minutes or hours, to make sure we backup everything and shut down
the process properly.
Wether we use a own power backup system or the store owner's ups, we
would like to intercept any notifications from the OS that the power
had been lost.
Stephane
Our unit is designed to be placed between the cash register and the
printer. It has to listen on the serial communication port of the cash
register to record every transactions that are processed, record it
into a database and send it to the printer with a unique identifier
and a legal stamp. Since it will be used in thousands of stores all
over the country, we will have to support a wide variety of cash
registers models. Using regular expressions specific to each models,
we can easily understand which information is sent to the printer
through the serial port. We don't have to bother over which OS is used
inside the cash register at all. The store manager will have to make
sure his cash register and his printer are supported by our unit. If
the store has a UPS, our unit will have to be connected to it as well
as the cash register.
Since the store owner won't be forced to use a UPS and because he can
use wathever UPS unit he wants if he desires to have one, I can only
rely on my own OS (Win CE or Xp Embedded) running in my Unit to notify
my program that the UPS has started.
The best solution for us would be as you said to put in our module our
own UPS device or battery. In fact, we only need just a few seconds,
not minutes or hours, to make sure we backup everything and shut down
the process properly.
Wether we use a own power backup system or the store owner's ups, we
would like to intercept any notifications from the OS that the power
had been lost.
Stephane
N
Nick Malik
Hello Stephane,
Your store owner would need to be CERTAIN that his register and printer are
supported, but will also be BETTER OFF if his UPS is also supported, because
you will have to write software to listen to each potentially different
message from a UPS.
So, call up your market base and find out what are the top one or two UPS
devices in use in the stores, and write support for them directly. I would
suggest using a "driver" software model, where your app simply registers an
event and you install a driver specific to the UPS to raise that event.
That way, you can write drivers for more UPS devices as time goes on.
You will want to get specs from the UPS manufacturers themselves. I do not
believe that there is a uniform protocol for communicating these messages.
Note: there are three hardware implications that may affect you:
(1) does the UPS actually send a data signal at all? The UPS may have no
port to send it on (smaller UPS devices, and those more than a few years
old, largely have no data message at all),
(2) what port will you receive the message on? Does your device have a type
A USB port? Most newer UPS devices, the ones with USB ports, have a type B
connection. Note that type A and type B are DIFFERENT. There are no
adapters for one to another, because the type A end, expected to appear on
computers, must provide electricity to the type B end. Therefore, your
device will need to have a type A port if you expect to communicate directly
with the USB port on the UPS.
(3) Most UPS devices have one and only one USB port. If that port is
already connected to the register (as it will be in some turn-key
installations), then you cannot connect to it. In a USB communication,
there is one A and one B. That's it. You cannot have two As and one B. It
would be irresponsible for you to tell a store owner to move the connection
from the register to your device. While you only need a second or two to
store everything, the register may need much longer than that. In this
configuration, you simply cannot succeed by directly connecting to the UPS.
In a traditional IT setting, a central computer would query individual
systems using SNMP (Simple Network Monitoring Protocol). Each system that
participates in SNMP would have a driver (usually called a MIB) that
responds to messages, gathers local events, and transmits them upstream.
The central system has the logic to send out messages when specific events
occur.
Therefore, if you were to follow standards, you would provide a MIB, for
your device, that runs on the register (you will need one for each major OS
of the registers). The MIB would query your device for status and send the
status messages to a registered listener (usually a network management
application like CA Unicenter or HP Openview). Also, the MIB would get
messages from the management application and relay them to your device.
That could be done by connecting another port from the register to your
device, or it can be done using some special interrupt sequence that the MIB
sends out by intercepting the data stream travelling over the printer port
(may not be easy to do the latter, but it costs less to manufacture the
device).
Your device can listen for the signals from the MIB, which can give
instructions like "backup now" and "systems initialization test" as relayed
from the management application.
That's the traditional way to do this. Sounds like this may be difficult in
your setting. I don't know. I'm not involved in the retail POS market.
There is another way to look at this, which is much simpler.
Let's stipulate that the power goes off and your device has a small battery
backup capability. The register will shut down. Three causes: (a) the
power went out to the register and no UPS was present... it simply quit.
(b) the register got a signal from a UPS or a MIB telling it to power down
immediately, (c) a frantic store clerk responds to the fact that she is
standing in a dark room with puzzled customers by shutting down the register
(as she was trained to do).
Once the register goes down, assuming you are still running on battery, the
register will stop sending data to the printer. If you have enough battery
to last for 15 minutes, you will last longer than the register would, which
means that the register will quit before you do. In this case, printing
will become idle.
If printing goes idle for more than 30 seconds, then you should simply save
everything, because there is a possibility that the power has gone off and
the register has gone offline.
That's as good a logic as you will likely get without installing software on
the register.
Good Luck,
--- Nick
Your store owner would need to be CERTAIN that his register and printer are
supported, but will also be BETTER OFF if his UPS is also supported, because
you will have to write software to listen to each potentially different
message from a UPS.
So, call up your market base and find out what are the top one or two UPS
devices in use in the stores, and write support for them directly. I would
suggest using a "driver" software model, where your app simply registers an
event and you install a driver specific to the UPS to raise that event.
That way, you can write drivers for more UPS devices as time goes on.
You will want to get specs from the UPS manufacturers themselves. I do not
believe that there is a uniform protocol for communicating these messages.
Note: there are three hardware implications that may affect you:
(1) does the UPS actually send a data signal at all? The UPS may have no
port to send it on (smaller UPS devices, and those more than a few years
old, largely have no data message at all),
(2) what port will you receive the message on? Does your device have a type
A USB port? Most newer UPS devices, the ones with USB ports, have a type B
connection. Note that type A and type B are DIFFERENT. There are no
adapters for one to another, because the type A end, expected to appear on
computers, must provide electricity to the type B end. Therefore, your
device will need to have a type A port if you expect to communicate directly
with the USB port on the UPS.
(3) Most UPS devices have one and only one USB port. If that port is
already connected to the register (as it will be in some turn-key
installations), then you cannot connect to it. In a USB communication,
there is one A and one B. That's it. You cannot have two As and one B. It
would be irresponsible for you to tell a store owner to move the connection
from the register to your device. While you only need a second or two to
store everything, the register may need much longer than that. In this
configuration, you simply cannot succeed by directly connecting to the UPS.
In a traditional IT setting, a central computer would query individual
systems using SNMP (Simple Network Monitoring Protocol). Each system that
participates in SNMP would have a driver (usually called a MIB) that
responds to messages, gathers local events, and transmits them upstream.
The central system has the logic to send out messages when specific events
occur.
Therefore, if you were to follow standards, you would provide a MIB, for
your device, that runs on the register (you will need one for each major OS
of the registers). The MIB would query your device for status and send the
status messages to a registered listener (usually a network management
application like CA Unicenter or HP Openview). Also, the MIB would get
messages from the management application and relay them to your device.
That could be done by connecting another port from the register to your
device, or it can be done using some special interrupt sequence that the MIB
sends out by intercepting the data stream travelling over the printer port
(may not be easy to do the latter, but it costs less to manufacture the
device).
Your device can listen for the signals from the MIB, which can give
instructions like "backup now" and "systems initialization test" as relayed
from the management application.
That's the traditional way to do this. Sounds like this may be difficult in
your setting. I don't know. I'm not involved in the retail POS market.
There is another way to look at this, which is much simpler.
Let's stipulate that the power goes off and your device has a small battery
backup capability. The register will shut down. Three causes: (a) the
power went out to the register and no UPS was present... it simply quit.
(b) the register got a signal from a UPS or a MIB telling it to power down
immediately, (c) a frantic store clerk responds to the fact that she is
standing in a dark room with puzzled customers by shutting down the register
(as she was trained to do).
Once the register goes down, assuming you are still running on battery, the
register will stop sending data to the printer. If you have enough battery
to last for 15 minutes, you will last longer than the register would, which
means that the register will quit before you do. In this case, printing
will become idle.
If printing goes idle for more than 30 seconds, then you should simply save
everything, because there is a possibility that the power has gone off and
the register has gone offline.
That's as good a logic as you will likely get without installing software on
the register.
Good Luck,
--- Nick
S
Stephane Belzile
Hi Nick,
I've learned so much with all your replies. Wow! Yesterday, I had a
meeting with my project manager and we discussed a lot about
everything that was in your message. I think the last solution, using
independant batteries inside the unit will do the job. It's fairly
easy to manage and most of all... simple and cheap to build!
That's what we thought a few weeks ago when we first put our hands on
the project and now, it seems that any effort aimed at trying to
manage every situation would be very risky. You've brought a few good
arguments to help them decide.
Some owners will have to update or change their equipment. We want to
limit as much as possible those impacts because of the costs. If we
add UPS restrictions...
Thank you very much for all your help.
Stephane Belzile
I've learned so much with all your replies. Wow! Yesterday, I had a
meeting with my project manager and we discussed a lot about
everything that was in your message. I think the last solution, using
independant batteries inside the unit will do the job. It's fairly
easy to manage and most of all... simple and cheap to build!
That's what we thought a few weeks ago when we first put our hands on
the project and now, it seems that any effort aimed at trying to
manage every situation would be very risky. You've brought a few good
arguments to help them decide.
Some owners will have to update or change their equipment. We want to
limit as much as possible those impacts because of the costs. If we
add UPS restrictions...
Thank you very much for all your help.
Stephane Belzile