java parallel port program bugs

[moses]

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");
}
}
}

 

[Roedy Green]

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.

 

[moses]

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]

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");
}
}

 

[Roedy Green]

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]

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.

 

[Patricia Shanahan]

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

 

[Martin Gregorie]

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.

 

[steve]

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

 

[Lew]

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.

 

[Martin Gregorie]

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.