java parallel port program bugs

Discussion in 'Java' started by moses, Sep 5, 2007.

  1. moses

    moses Guest

    hi.could anyone please tell me what is wrong with my code given below?
    the port data outputs are supposed to be made low on running the
    code.but i checked the output using a digital voltmeter and it is
    staying high.i am using windows XP and jdk1.5.0.and the Rxtx package
    do i need to install any drivers to allow port communication?.it is
    showing the IOEXCEPTION:'the data was written successfully in the
    writebyte'.


    package parallelIO;
    import gnu.io.*;
    import java.io.*;

    public class ParallelIO {

    private static OutputStream outputStream;
    private static ParallelPort parallelPort;
    private static CommPortIdentifier port;


    public static final String PARALLEL_PORT = "LPT1";
    public ParallelIO()
    {
    try {
    // get the parallel port connected to the output
    port =
    CommPortIdentifier.getPortIdentifier(PARALLEL_PORT);
    // open the parallel port -- open(App name, timeout)
    parallelPort = (ParallelPort) port.open("Automator",
    50);
    outputStream = parallelPort.getOutputStream();

    byte x=5;
    outputStream.write(x);
    outputStream.flush();
    outputStream.close();

    }
    catch (NoSuchPortException nspe)
    {
    System.out.println("\nPrinter Port LPT1 not found :
    "
    + "NoSuchPortException.\nException:\n" + nspe +
    "\n");
    }
    catch (PortInUseException piue)
    {
    System.out.println("\nPrinter Port LPT1 is in use : "
    + "PortInUseException.\nException:\n" + piue +
    "\n");
    }
    catch (IOException ioe)
    {
    System.out.println("\nPrinter Port LPT1 failed to
    write : "
    + "IOException.\nException:\n" + ioe + "\n");
    }
    catch (Exception e)
    {
    System.out.println("\nFailed to open Printer Port LPT1
    with exception : "
    + e + "\n");
    }
    finally
    {
    if (port != null && port.isCurrentlyOwned())
    {
    parallelPort.close();
    }
    System.out.println("Closed all resources.\n");
    }
    }
    }
    moses, Sep 5, 2007
    #1
    1. Advertising

  2. moses

    Roedy Green Guest

    On Tue, 04 Sep 2007 19:44:28 -0700, moses <> wrote,
    quoted or indirectly quoted someone who said :

    > i checked the output using a digital voltmeter and it is
    >staying high.


    Your voltmeter may not be reacting fast enough to notice the pulses.
    See if you can find a miniature breakout box, just some lights.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Sep 5, 2007
    #2
    1. Advertising

  3. moses

    moses Guest

    On Sep 5, 9:18 am, Roedy Green <>
    wrote:

    >
    > Your voltmeter may not be reacting fast enough to notice the pulses.
    > See if you can find a miniature breakout box, just some lights.
    > --


    we already tried an LED lamp.it stayed on even after we ran the
    pgm.besides if we write something to a parallel port won't it stay tht
    way unless something new is sent?
    moses, Sep 5, 2007
    #3
  4. moses

    moses Guest

    sorry i accidentally deleted my post.here is it agin:
    hi.could anyone please tell me what is wrong with my code given below?
    the port data outputs are supposed to be made low on running the
    code.but i checked the output using a digital voltmeter and it is
    staying high.i am using windows XP and jdk1.5.0.and the Rxtx package
    do i need to install any drivers to allow port communication?.it is
    showing the IOEXCEPTION:'the data was written successfully in the
    writebyte'.

    package parallelIO;
    import gnu.io.*;
    import java.io.*;

    public class ParallelIO {

    private static OutputStream outputStream;
    private static ParallelPort parallelPort;
    private static CommPortIdentifier port;
    static byte dat=0x00;

    public static final String PARALLEL_PORT = "LPT1";
    public ParallelIO()
    {
    try {
    // get the parallel port connected to the output
    port =
    CommPortIdentifier.getPortIdentifier(PARALLEL_PORT);
    // open the parallel port --
    open(App name, timeout)
    parallelPort = (ParallelPort)
    port.open("Automator",
    50);
    outputStream =
    parallelPort.getOutputStream();

    outputStream.write(dat);
    outputStream.flush();
    outputStream.close();

    }
    catch (NoSuchPortException nspe)
    {
    System.out.println("\nPrinter Port LPT1 not
    found :
    "
    + "NoSuchPortException.\nException:\n" + nspe +
    "\n");
    }
    catch (PortInUseException piue)
    {
    System.out.println("\nPrinter Port LPT1 is
    in use : "
    + "PortInUseException.\nException:\n" + piue +
    "\n");
    }
    catch (IOException ioe)
    {
    System.out.println("\nPrinter Port LPT1
    failed to
    write : "
    + "IOException.\nException:\n" + ioe + "\n");
    }
    catch (Exception e)
    {
    System.out.println("\nFailed to open Printer
    Port LPT1
    with exception : "
    + e + "\n");
    }
    finally
    {
    if (port != null && port.isCurrentlyOwned())
    {
    parallelPort.close();
    }
    System.out.println("Closed all resources.\n");
    }
    }
    moses, Sep 5, 2007
    #4
  5. moses

    Roedy Green Guest

    On Wed, 05 Sep 2007 04:18:37 GMT, Roedy Green
    <> wrote, quoted or indirectly quoted
    someone who said :

    >Your voltmeter may not be reacting fast enough to notice the pulses.
    >See if you can find a miniature breakout box, just some lights.


    see http://mindprod.com/bgloss/breakoutbox.html
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Sep 5, 2007
    #5
  6. moses

    Roedy Green Guest

    On Tue, 04 Sep 2007 21:25:02 -0700, moses <> wrote,
    quoted or indirectly quoted someone who said :

    >we already tried an LED lamp.it stayed on even after we ran the
    >pgm.besides if we write something to a parallel port won't it stay tht
    >way unless something new is sent?


    Signals don't hang around long. They are either strobed or held only
    long enough for a handshake. I think you need to read up on how the
    parallel protocol works with all those pins. I learned back in 1979
    from some parallel chip docs from Motorola. There are a number of
    modes it can work in.

    To get started see
    http://mindprod.com/jgloss/cables.html#INTERNALPARALLEL


    I think the old XT or AT IBM technical reference may have had some
    info.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Sep 5, 2007
    #6
  7. Roedy Green wrote:
    > On Tue, 04 Sep 2007 21:25:02 -0700, moses <> wrote,
    > quoted or indirectly quoted someone who said :
    >
    >> we already tried an LED lamp.it stayed on even after we ran the
    >> pgm.besides if we write something to a parallel port won't it stay tht
    >> way unless something new is sent?

    >
    > Signals don't hang around long. They are either strobed or held only
    > long enough for a handshake. I think you need to read up on how the
    > parallel protocol works with all those pins. I learned back in 1979
    > from some parallel chip docs from Motorola. There are a number of
    > modes it can work in.
    >
    > To get started see
    > http://mindprod.com/jgloss/cables.html#INTERNALPARALLEL
    >
    >
    > I think the old XT or AT IBM technical reference may have had some
    > info.


    Depending on how much money is available to track down the problem,
    renting a small logic analyzer may make sense. It would give an easy way
    to see all transitions over an extended period.

    Patricia
    Patricia Shanahan, Sep 5, 2007
    #7
  8. Patricia Shanahan wrote:
    > Roedy Green wrote:
    >> On Tue, 04 Sep 2007 21:25:02 -0700, moses <> wrote,
    >> quoted or indirectly quoted someone who said :
    >>
    >>> we already tried an LED lamp.it stayed on even after we ran the
    >>> pgm.besides if we write something to a parallel port won't it stay tht
    >>> way unless something new is sent?

    >>
    >> Signals don't hang around long. They are either strobed or held only
    >> long enough for a handshake. I think you need to read up on how the
    >> parallel protocol works with all those pins. I learned back in 1979
    >> from some parallel chip docs from Motorola. There are a number of
    >> modes it can work in.
    >>
    >> To get started see
    >> http://mindprod.com/jgloss/cables.html#INTERNALPARALLEL
    >>
    >>
    >> I think the old XT or AT IBM technical reference may have had some
    >> info.

    >
    > Depending on how much money is available to track down the problem,
    > renting a small logic analyzer may make sense. It would give an easy way
    > to see all transitions over an extended period.
    >

    Alternatively, if you have access to an oscilloscope use that. However,
    the cheapest solution is to buy a logic probe.

    Logic probes are inexpensive, pen shaped devices with LEDs to indicate a
    static high and low level (both glow for a 50:50 pulse train and a third
    pulse stretcher LED that flashes continuously for a pulse train and
    produces a visible single flash from a short pulse. This typically
    produces a 1/2 second flash from a pulse of 30 nanoseconds or longer.

    Logic probes are the best way to spot irregularly occurring pulses or
    glitches: logic analyzers and oscilloscopes are really designed to deal
    with continuous pulse trains. The logic probe is also faster: it will
    typically trigger on a shorter pulse than either a logic analyzer or an
    oscilloscope can handle.

    Here's an example of a logic probe:

    http://www.maplin.co.uk/Search.aspx?criteria=logic probe&source=15&SD=Y

    You can discover a lot from such a cheap and versatile tool I assembled
    my first home computer from a stack of circuit boards and a heap of
    chips and other components. Needless to say, it didn't work immediately,
    but I was able to debug the hardware and get the computer working with
    just a multi-meter and a logic probe.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Sep 5, 2007
    #8
  9. moses

    steve Guest

    On Wed, 5 Sep 2007 12:25:02 +0800, moses wrote
    (in article <>):

    > On Sep 5, 9:18 am, Roedy Green <>
    > wrote:
    >
    >>
    >> Your voltmeter may not be reacting fast enough to notice the pulses.
    >> See if you can find a miniature breakout box, just some lights.
    >> --

    >
    > we already tried an LED lamp.it stayed on even after we ran the
    > pgm.besides if we write something to a parallel port won't it stay tht
    > way unless something new is sent?
    >


    Scope it (best solution) or use a small pizo speaker.

    reaction speed of human eye is 25hz , human ear is about 18,000hz , so an led
    may not show you anything.

    Steve
    steve, Sep 6, 2007
    #9
  10. moses

    Lew Guest

    steve wrote:
    > reaction speed of human eye is 25hz , human ear is about 18,000hz [sic] ,


    In children and some, not proportionately many, adults. For most adults it's
    probably nearer 15 KHz.

    Leaving your point still completely valid, of course.

    --
    Lew
    Lew, Sep 6, 2007
    #10
  11. steve wrote:
    > On Wed, 5 Sep 2007 12:25:02 +0800, moses wrote
    > (in article <>):
    >
    >> On Sep 5, 9:18 am, Roedy Green <>
    >> wrote:
    >>
    >>> Your voltmeter may not be reacting fast enough to notice the pulses.
    >>> See if you can find a miniature breakout box, just some lights.
    >>> --

    >> we already tried an LED lamp.it stayed on even after we ran the
    >> pgm.besides if we write something to a parallel port won't it stay tht
    >> way unless something new is sent?
    >>

    >
    > Scope it (best solution) or use a small pizo speaker.
    >

    If its an isolated event, which this could be during the early stages of
    testing, a scope may not be the best solution because:

    a) its not always easy to get a scope to trigger on isolated
    level changes or pulses.

    b) if its a fast event you'll have to set the timebase fast
    and then there's a good chance you'll blink and miss it

    Logic probes are much better than scopes for displaying isolated events
    because they always trigger unless the pulse is really fast, e.g. <30
    nS, and its easy to see the 500 mS flash output by its pulse stretcher.
    If you're debugging digital logic my advice would be to use the
    following in the order given. This order is the same for both cost and
    ease of use:

    1) use a DVM to see that you actually have power on the lines
    2) If its a serial port, get a break-out box and watch the pretty LEDs
    to find connectivity problems
    3) use a logic probe. If you don't have one, they are cheap and/or easy
    to make. Circuits are easy to find for DIY probes.
    4) use a scope if you're dealing with a continuous pulse train, though
    It probably needs to be dual-beam to be much use. Commodity scopes
    top out at 10 or 20 MHz and faster ones are expensive.
    5) Use a logic analyzer (not cheap!) if you need to follow more than
    two signals or you need to interpret a serial line's protocol as
    ASCII or EBCDIC. [*}

    [*] monitoring a serial line may be cheaper to do with a standard PC and
    a program that captures and/or displays traffic on the line.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Sep 6, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Perrone
    Replies:
    0
    Views:
    14,418
    Paul Perrone
    Aug 21, 2003
  2. b3ny
    Replies:
    11
    Views:
    917
    Babu Kalakrishnan
    Nov 20, 2004
  3. moses

    java parallel port program

    moses, Sep 5, 2007, in forum: Java
    Replies:
    0
    Views:
    810
    moses
    Sep 5, 2007
  4. Soren
    Replies:
    4
    Views:
    1,251
    c d saunter
    Feb 14, 2008
  5. Josef 'Jupp' Schugt

    Still use 'ruby-bugs' for Ruby bugs?

    Josef 'Jupp' Schugt, Nov 4, 2004, in forum: Ruby
    Replies:
    2
    Views:
    160
    Tom Copeland
    Nov 4, 2004
Loading...

Share This Page