Wie erzwinge ich eine serielle Methode Port Schreib für die Linie zu warten, bevor das Senden seiner Daten zu löschen?

Question

Hier ist ein Hintergrund auf, was ich zu tun werde versuchen:

1. Öffnen Sie eine serielle Schnittstelle von einem mobilen Gerät mit einem Bluetooth-Drucker.
2. Senden Sie ein EPL / 2 Formular an den Bluetooth-Drucker, so dass er versteht, wie die Daten zu behandeln, es im Begriff ist, zu erhalten.
3. Sobald das Formular empfangen wurde, einige Daten an den Drucker senden, die auf Etiketten gedruckt werden.
4. Wiederholen Sie Schritt 3 so oft wie nötig, für jedes Etikett gedruckt werden.

Schritt 2 geschieht nur beim ersten Mal, da die Form muss nicht jedes Etikett vorangestellt werden. Mein Problem ist, dass, wenn ich das Formular abzuschicken, wenn ich die Etikettendaten zu schnell senden wird es nicht drucken. Manchmal erhalte ich „Bluetooth Failure: Radio Non-Operational“. Gedruckt auf dem Etikett anstelle der Daten, die ich gesendet

Ich habe einen Weg, um das Problem zu finden, indem Sie folgendermaßen vorgehen:

for (int attempt = 0; attempt < 3; attempt++)
{
    try
    {
        serialPort.Write(labelData);
        break;
    }
    catch (TimeoutException ex)
    {
        // Log info or display info based on ex.Message
        Thread.Sleep(3000);
    }
}

Also im Grunde kann ich einen Timeout fangen und das Schreibverfahren wiederholen, nachdem ein gewisse Zeit warten (3 Sekunden scheinen die ganze Zeit zu arbeiten, aber nicht weniger, und es scheint die Ausnahme jeden Versuch zu werfen). Nach drei Versuchen gehe ich davon nur die serielle Schnittstelle hat etwas falsch und lassen den Benutzer wissen.

Auf diese Weise scheint ok zu arbeiten, aber ich bin sicher, dass es ein besserer Weg, dies zu handhaben. Es gibt ein paar Eigenschaften in der Serialport-Klasse, die ich glaube, ich verwenden müssen, aber ich kann wirklich keine gute Dokumentation oder Beispiele finden, wie sie zu nutzen. Ich habe versucht, mit einigen der Eigenschaften herumgespielt, aber keiner von ihnen scheint zu tun, was ich versuche zu erreichen.

Hier ist eine Liste der Eigenschaften die ich gespielt habe mit:

• CDHolding
• CtsHolding
• DsrHolding
• DTREnable
• Hände schütteln
• RTSEnable

Ich bin sicher, dass eine Kombination von diesen wird handhaben, was ich versuche mehr anmutig zu tun.

Ich bin mit C # (2.0 Framework), ein Zebra QL 220 + Bluetooth-Drucker und ein Windows Mobile 6 Handheld-Gerät, wenn das einen Unterschied für Lösungen macht.

würde Irgendwelche Vorschläge geschätzt.

[UPDATE]

Ich sollte auch beachten, dass das mobile Gerät mit Bluetooth 2.0, während der Drucker nur in der Version 1.1 ist. Ich gehe davon aus der Geschwindigkeitsdifferenz ist, was der Drucker verursacht zurückzubleiben in die Daten zu empfangen.

Answer 1

Die Flusssteuerung ist die richtige Antwort hier, und es kann nicht vorhanden / umgesetzt / für Ihre Bluetooth-Verbindung sein.

Überprüfen Sie die Zebra-Spezifikation und sehen, ob sie implementieren, oder wenn Sie einschalten können, Software-Flusssteuerung (XON, XOFF), die es Ihnen erlaubt, um zu sehen, wenn die verschiedenen Puffer voll bekommen.

Ferner ist der Bluetooth-Funk unwahrscheinlich zu übertragen schneller als 250k am Maximum der Lage sein. Sie sollten erwägen künstlich es 9,600bps Begrenzung -. Dies wird das Radio viel Raum zum Atmen für Retransmits, Fehlerkorrektur, Erkennung und seine eigene Flusssteuerung erlauben

Wenn alles andere fehlschlägt, der Hack Sie jetzt verwenden ist nicht schlecht, aber ich würde Zebra-Tech-Support anrufen und herausfinden, was sie empfehlen, bevor er aufgibt.

-Adam

Answer 2

Nun, ich habe einen Weg gefunden, dies bereits gegeben auf den beiden Vorschläge auf der Grundlage zu tun. Ich brauche mein serielles Port-Objekt mit dem folgenden einzurichten:

serialPort.Handshake = Handshake.RequestToSendXOnXOff;
serialPort.WriteTimeout = 10000; // Could use a lower value here.

Dann muß ich tun, nur den Schreibaufruf:

serialPort.Write(labelData);

Da der Zebra-Drucker Software-Flusssteuerung unterstützt, wird es einen XOff Wert auf das mobile Gerät senden, wenn der Puffer fast voll ist. Dies bewirkt, dass das mobile Gerät für einen XOn Wert zu warten, aus dem Drucker gesendet werden sollen, effektiv das mobile Gerät darüber informiert, dass es Sende fortgesetzt werden kann.

Durch die Schreibzeit out-Eigenschaft, ich bin eine Gesamtzeit für die Übertragung erlaubt zu geben, bevor eine Schreib Timeout Ausnahme ausgelöst. Sie wollen immer noch die Schreib Timeout zu fangen, wie ich in meinem Beispielcode in der Frage getan hatte. Allerdings wäre es nicht Schleife 3 (oder eine beliebige Menge) gegebenenfalls erforderlich sein, versucht, jedes Mal zu schreiben, da würde die Software-Flusssteuerung starten und die serielle Schnittstelle Schreib Übertragung stoppen.

Answer 3

Das Problem nicht mit dem seriellen Schnittstelle Code wahrscheinlich ist, aber mit dem zugrunde liegenden Bluetooth-Stack. Die Port Sie verwenden ist rein virtuell, und es ist unwahrscheinlich, dass der Handshaking wird auch umgesetzt (wie es weitgehend bedeutungslos wäre). CTS / RTS DTR / DSR sind einfach nicht anwendbar für das, was Sie gerade arbeiten.

Das zugrunde liegende Problem ist, dass, wenn Sie den virtuell Port zu erstellen, darunter an den Bluetooth-Stack zu binden und zu dem gekoppelten seriellen Gerät verbinden. Der Hafen selbst hat keine Ahnung, wie lange das dauern könnte und es ist wahrscheinlich aufgebaut dies asynchron tun (obwohl es rein bis zu dem Gerät würde OEM, wie das gemacht wird) von dem Anrufer zu verhindern, für einen langen Zeitraum Perren, wenn es keine ist abgeglichene Gerät oder das gekoppelte Gerät außer Reichweite ist.

Während Ihr Code wie ein Hack fühlen kann, ist es wahrscheinlich die beste, tragbare Art und Weise zu tun, was Sie tun.

Sie können eine Bluetooth-Stack-API, um zu versuchen, um zu sehen, ob das Gerät dort und am Leben ist vor dem Anschluss, aber es gibt keine Standardisierung der Stack APIs, so dass die Widcom und Microsoft APIs unterscheiden sich, wie Sie das tun würde, dass und Widcom ist proprietär und teuer. Was Sie am Ende mit würde, ist ein Durcheinander zu versuchen, den Stapel zu entdecken, dynamisch einen geeigneten Prüfer Klasse geladen, mit den Stapel aufrufen und für das Gerät suchen. Im Lichte, dass Ihre einfache Umfrage scheint viel sauberer, und Sie müssen nicht ein paar $ k für die Widcom SDK berappen.