[Java] COM poort disconnect detecteren

[Verwijderd]

Hallo allemaal,

Ik ben voor een schoolopdracht bezig met een GPS ontvanger en een java programma. Nu heb ik het probleem dat ik op de een of andere manier moet dedecteren dat het apparaat niet meer aan de COM poort hangt. Er wordt wel een event getriggerd op het moment dat ik de GPS ontvanger van het apparaat af haal, maar ik heb geen idee hoe ik dat event moet opvangen. Ik krijg de volgende melding:

code:

WaitCommEvent: Error 5

Er is helemaal nergens iets te vinden over dat Event. Op http://java.sun.com vind je helemaal niks terug (*klik*), en op Google is het allemaal C/C++ en geen Java, dus dat schiet ook niet op.
Weet iemand hoe ik kan dedecteren of het apparaat er nog aan hangt?
Hieronder de code die ik nu heb:

code:

package gps;

import javax.comm.*;
import java.io.*;
import java.util.TooManyListenersException;
import javax.swing.JFrame;
import javax.swing.JOptionPane;

public class LegacyGps extends GpsImplementor implements SerialPortEventListener, CommPortOwnershipListener
{
    private InputStream is;
    private CommPortIdentifier portId;
    private SerialPort sPort;
    private String str_GPSData, str_COMport = "COM10";
    private int int_BaudRate = 4800, int_DataBits = 8, int_StopBits = 1, int_ParityBit = 0;

    public void run()
    {
    openConnectie();
    }

    public void openConnectie()
    {
    try
    {
        portId = CommPortIdentifier.getPortIdentifier(this.str_COMport);
        sPort = (SerialPort) portId.open("iWalk", 30000);
        sPort.setSerialPortParams(int_BaudRate, int_DataBits, int_StopBits, int_ParityBit);
        is = sPort.getInputStream();
        sPort.addEventListener(this);
        sPort.notifyOnDataAvailable(true);
        sPort.notifyOnBreakInterrupt(true);
        sPort.notifyOnFramingError(true);
        sPort.notifyOnOverrunError(true);
        sPort.notifyOnParityError(true);
        sPort.enableReceiveTimeout(30);
            sPort.notifyOnCarrierDetect(true);
        portId.addPortOwnershipListener(this);
    }
    // alle catch-statements
    }

    public void serialEvent(SerialPortEvent serialPortEvent)
    {
    // Create a StringBuffer and int to receive input data.
    StringBuffer inputBuffer = new StringBuffer();
    int newData = 0;

    // Determine type of event.
    switch (serialPortEvent.getEventType())
    {

        // Read data into inputbuffer
        refreshPosition(new String(inputBuffer));
        break;

        // If break event append BREAK RECEIVED message.
        case SerialPortEvent.BI:
        System.out.println("--- BREAK RECEIVED ---");
        System.exit(1);
        break;
        case SerialPortEvent.FE:
        case SerialPortEvent.OE:
        case SerialPortEvent.PE:
            case SerialPortEvent.CD:
                if(sPort.isCD())
                {
                  System.out.println( "Er gaat nu dus iets fout" );
                }
                else
                {
                  System.out.println( "nu gaat het goed" );
                }
        break;
    }

    }

    private void showException(Exception e)
    {
       //laat relevante info zien
    }
}

[ Voor 45% gewijzigd door Verwijderd op 21-12-2005 15:15 ]

[Verwijderd]

Heb je hier misschien iets aan?? Ik denk niet dat iemand die 250 regels code gaat doorlezen trouwens .

[NMe]

Verwijderd schreef op woensdag 21 december 2005 @ 14:56:
Ik denk niet dat iemand die 250 regels code gaat doorlezen trouwens .

Dat weet ik wel zeker. Post alleen code als die relevant is. Je maakt mij niet wijs dat al die regels code relevant zijn voor je probleem. Haal dus even de overbodige code weg, en laat alleen de relevante code staat.

offtopic:
Het is trouwens detecteren, niet dedecteren. Waarschijnlijk vind je meer als je op "detect" zoekt met Google in plaats van op "dedect".

[Verwijderd]

Verwijderd schreef op woensdag 21 december 2005 @ 14:56:
Heb je hier misschien iets aan?? Ik denk niet dat iemand die 250 regels code gaat doorlezen trouwens .

nope, staat niks tussen. Allemaal weer C/C++, en ik ben toch echt met Java bezig.

de code hoeveelheid is aangepast. Laat nu alleen nog maar de kern van de klasse zien.

[Soultaker]

Die WaitCommEvent is geen Event, maar een Windows API call ("The WaitCommEvent function waits for an event to occur for a specified communications device"). Ik neem dan ook aan dat je onder Windows werkt. Sun's implementatie roept WaitCommEvent aan (waarschijnlijk in een aparte thread) en die faalt (error 5 zou 'access denied' zijn - tenminste als het een Windows systeemfoutcode is).

Vervolgens is het maar de vraag of de Windows implementatie die foutmelding vervolgens op enige wijzige doorgeeft aan de Java omgeving. De API doet vermoeden van niet en als je hebt geverifieerd dat je listener method ook helemaal aangeroepen wordt, dan klopt dat. Het is dan waarschijnlijk geen informatie waar je over kan beschikken.

Ik denk trouwens dat COM-poorten (RS-232) ueberhaupt geen ondersteuning hebben voor het detecteren van aangesloten apparaten (zoals bijvoorbeeld USB dat wel heeft). Zo'n fout zou dus net zo goed een toevallige storing kunnen zijn.

[Verwijderd]

Ik werk idd onder Windows (Wndows XP Professional SP1 om precies te zijn). Het is geen toevallige fout. Ik krijg altijd deze fout te zien als ik de kabel eruit trek. (het is trouwens een PS/2 GPS ontvanger die, via een overloop , aan de USB poort hangt. Er wordt een COM-poort simuleert, en daarmee maak ik verbinding in Java). Wel raar dat het dan "access denied" is dan .

Heel m'n listener methode wordt aangeroepen. Althans, als ik de connector gewoon laat zitten, dan werkt hij helemaal goed, dus alles wordt aangeroepen, denk ik dan.

Waar heb je dit trouwens gevonden? Dan kan ik dat meenemen naar school, om aan te tonen dat het door een beperking in Windows\Java\RS-232 niet mogelijk is om deze functionaliteit te verwezenlijken

[ Voor 9% gewijzigd door Verwijderd op 21-12-2005 16:40 . Reden: toevoegen van informatie over de aansluiting van de GPS moduel ]

[Soultaker]

Dat het een API functie is had je zelf al via Google gevonden, toch? Hij staat ook in MSDN gedocumenteerd: http://msdn.microsoft.com...io/base/waitcommevent.asp
Het ligt voor de hand dat Sun's implementatie die functie gebruikt om de javax.comm API te realiseren onder Windows.

De RS-232 standaard ken ik niet van buiten, maar ik kan me niet voorstellen dat die archaïsche standaard onderscheid maakt tussen het loskoppelen van een apparaat en een transmissiefout. RS-232 is ontworpen om modems enzo aan te sluiten en die laat je doorgaans toch gewoon zitten zolang je er mee bezig bent (je moet dan ook voor elke transactie opnieuw handshaken).

Ik denk dat als je zou testen met een apparaat op een échte COM-poort, je geen enkele melding krijgt van het besturingssysteem. Totdat je data probeert te lezen of te schrijven natuurlijk. Ik denk dat de 'access denied' komt omdat USB wél detecteert wanneer je het apparaat loskoppelt en de driver dan die gesimuleerde (?) COM-poort verwijdert.

[elevator]

Gaat je carrier niet laag op het moment dat je je apparaat ontkoppelt en vv?

[Soultaker]

Dat is volgens mij gewoon afhankelijk van of een modem wel of niet een signaal over de telefoonlijn ontvangt - die varieert dus gewoon terwijl het apparaat er nog in zit. Andere apparaten die je op de COM-poort kan aansluiten negeren waarschijnlijk de carrier lijn helemaal, dus daar heb je ook niets aan.

[Verwijderd]

Ik heb al gelet op een Carrier Detect, maar dat gaf niet aan of er een verbinding was, dus dat werkt helaas niet
En op http://java.sun.com/produ...cs/API_users_guide_3.html is te zien dat dit eigenlijk alleen een Solaris/Linux library is, en dus niet voor Windows. Dus dat wordt niet doorgegeven. Dan geef ik het op, en ga ik m'n tijd nuttiger besteden

[ Voor 2% gewijzigd door Verwijderd op 22-12-2005 11:16 . Reden: tikfoutje verbeteren ]

[yrew]

kun je geen heartbeat methode toepassen? Heartbeat als in. Je start een apparte thread op, deze pollt om de x ms door het uitvragen van een property van het device. Als hij de property kan lezen dan is er niks aan het handje. Kan hij de property niet lezen dan is er iets mis.

[farlane]

Pollen is de enige betrouwbare methode. Op zijn minimaalst bestaat een (nul)modem kabel uit een send/receive en gnd pinnetje, en heb je geen enkel besef van 'verbinding' in je hardware.

[elevator]

Soultaker schreef op donderdag 22 december 2005 @ 01:03:
Dat is volgens mij gewoon afhankelijk van of een modem wel of niet een signaal over de telefoonlijn ontvangt - die varieert dus gewoon terwijl het apparaat er nog in zit.

Klopt - aan de andere kant als je apparaat (modem bv) je CD hoog zet, en je ontkoppelt je modem gaat die iig weer laag, mocht je dus het geluk hebben dat die GPS muis je CD hoog zet dan kan je dat gebruiken

farlane schreef op donderdag 22 december 2005 @ 15:54:
Pollen is de enige betrouwbare methode. Op zijn minimaalst bestaat een (nul)modem kabel uit een send/receive en gnd pinnetje, en heb je geen enkel besef van 'verbinding' in je hardware.

Dat is natuurlijk een andere goede optie - volgens mij zenden die GPS muizen een vrijwel continue GPS stroom uit en dat moet dus relatief makkelijk te detecteren zijn