Hi All,

I was wondering if anyone has implemented a pick/pack wireless
warehouse application using a device such as an IPAQ to connect to a
backend Universe database system. We essentially have all the code in
the backend to do the update, but unfortunately our vendor who was
supposed to do the front-end app on the IPAQ dropped out. I guess the
ideal situation would be that someone has an application already
running on a Windows 2003 mobile o.s. that we could feed our XML data
to, and that we could process the XML data sent back from that device.
If not, does any one have any leads on a vendor that could develop this
kind of application very rapidly and that isn't too expensive. We're
not looking for anything too complex, however we would like to obtain
the source code so what happened with our previous vendor does not
happen again.

Thanks.



John

On 2 May 2005 14:47:26 -0700, "johnq (AT) country-life (DOT) com"
<johnq (AT) country-life (DOT) com> wrote:


http://www.jmosystems.com

They maintain the WaveLink MV API for use with a lot of Symbol and
other brand RF terminals, palmtops, and PDAs. We've been using it for
over 8 years with PDT6840 gun-style scanner terminals. It's an
investment that needs a serious cost justification. In our case, the
RF picking and stocking app I wrote has paid for itself 100 fold along
with a regular green screen pack verification app. The initial
investment was over 15K. It took a couple years to justify the cost,
but the solution has been non-replaceable since then. You can expect
to spend arond $3K per terminal for a complete MV API solution. You'll
have to write your own app though, which is no harder than writing a
screen app with a line length limit. RF.PRINT and RF.INPUT are
basically the two main subroutines you call. If you are looking at
portable terminals, make sure you get Lithium Ion battery units
instead of NiCad. The NiCads have a charge cycle life of 100 times.
Everytime the unit is set in the cradle, it is discharged and then
recharged. I get about a year out of a battery.

Glen
http://picksource.com
http://mvdevcentral.com

Hi John

I wrote a demo application for Pick D3 and Worthington hand-held
terminals a couple of years back. These devices communicate with one or
more radio base stations (more to get coverage). Each base station
communicates with the D3 server using one serial port and can support up
to 16 terminal devices. Bar code scanning is supported and the devices
are tough enough for industrial use (misuse).

http://www.worthdata.info/rfterminal100.html

The two hard parts were:

1 - Squeezing helpful and informative application displays into the
small terminal screen.

2 - Inventing and implementing a multiplexing server protocol so that
one process could support up to 16 simultaneous stateless devices.

What is it that you are trying to do?

Kind regards


John


johnq (AT) country-life (DOT) com wrote:

We also use the Worthington hardware. We have a complete inventory
management system including cycle counts, inventory adjustments, order
picking, PO putaway, location transfers, label printing, and more. One of
our customers is a nursery. People walk around and put whatever plants they
want on a cart and push the cart up to the front. An employee then goes over
to the cart, scans each of the items (sales order entry) and prints the
invoice. This is all done outdoors. We added a relay station in order to
reach the outermost portions of the yard.

Here are a couple of pointers based on our experience:

1) Although each base station will support up to 16 terminals, we found that
once you get more than 8-10 running at the same time, such as during a full
physical inventory, the traffic is more than the base station can handle.
The terminals will time out. However, you can set up another base station on
another port with a different frequency to handle the additional traffic.
That of course uses another user license.

2) Since the communication is not persistent, we have a data file that store
all the pertinent information such as user id, which process they are
running, where they are in the process, etc. The key is the terminal
concatenated with the base station id.

3) Your base station processing program has to screen out noise and invalid
data.

4) You are limited to 6 lines with 40 char's per line. Be creating, use
abbreviations.

5) The farther away from the base station, the more latency there is. The
latency is not noticeable until you get 500 to 600 feet away.

If you are still interested, let me know and I can provide some code snips.

Jeff

"John Bend" <spam (AT) ITstuff (DOT) net> wrote

Jeffrey,

Wow, sounds like you've written a really nifty system.

Good Work.

Douglas