V.24 oder USB ?

Technik Elektronik & Elektrotechnik
1

Hallo Gemeinde,

Die folgende Frage gehört eigentlich in mehrere Bretter, aber hier werden die meisten Fachleute zum Thema zu finden sein. Ich hoffe der MOD vertreibt mich jetzt nicht aus dem Brett :wink:

Es geht um ein neu zu entwickelndes Gerät mit einem abgesetzten Bedienteil. Vom Konzept her, kann das Bedienteil auch durch einen PC ersetzt werden. Das Bedienteil umfasst ein paar Knöpfe, ein LCD einen µP und wird eigentlich nur die die Menüführung und die Anzeige von Istwerten enthalten

Über das Verbindungskabel muss die Stromversorgung und die bidirektionale Datenverbindung.

Für USB spricht eigentlich nur, dass heute alle damit arbeiten.
Dagegen spricht:

  1. Die Spannungsversorgung für das Bedienteil vom Slave (also vom Gerät) aus erfolgen muss.
  2. Der etwas höhere Entwicklungsaufwand
  3. Die Stecker. Es müssen verriegelbare und einigermassen dichte Steckverbindungen verwendet werden. Das Gerät wird zwar in einer Laborumgebung eingesetzt, es wird aber mit Lacken gearbeitet und da kanns mal auf den Stecker tropfen.
  4. Wie sieht es mit den Treibern für Vista, insbesonders Vista64, aus? Muss der Gerätespezifische Treiber auch von MS signiert sein ?

V.24 hat nur den Nachteil, dass man einen USB V.24 Adapter benötigt, das Treiberproblem müssen dann andere lösen :wink:
Allerdings sollten solche Adapter die nächsten 5 bis 10 Jahre wohl noch zu haben sein.

Stückzahlen sind so 20 bis 50 pro Jahr und das Ganze ist nicht so sehr kostensensibel.

Wie schätzt ihr das ganze ein ?

MfG Peter(TOO)

2

Es geht um ein neu zu entwickelndes Gerät mit einem
abgesetzten Bedienteil. Vom Konzept her, kann das Bedienteil
auch durch einen PC ersetzt werden. Das Bedienteil umfasst ein
paar Knöpfe, ein LCD einen µP und wird eigentlich nur die die
Menüführung und die Anzeige von Istwerten enthalten

Über das Verbindungskabel muss die Stromversorgung und die
bidirektionale Datenverbindung.
…

Hallo Peter,

USB ist als Bus für eine Punkt zu Punkt Verbindung Overkill, ausserdem bin ich mir sicher, du würdest ja eh nur die darüber transportierte Funktion eines COMx-Ports benutzen - was auch sonst, dein Bedienteil ist ja kein Memorystick oder Drucker.

SubD-Stecker sind nicht sonderlich geeignet für Industrieeinsatz, obwohl sie vom Militär erfunden wurden, und USB-Stecker noch weniger, ich würde mir daher einen der vielen verfügbaren wasserdichten Rundstecker aussuchen, GND,VCC, Txd und RxD reichen ja. Einen Standard 9pol. PC-Stecker könntest du nur verwenden, wenn dein Bedienteil so wenig Strom braucht, dass es den aus den Statussignalen des Modems entnehmen kann, und wenn du eine andere Belegung brauchst, kannst du auch gleich einen anderen Stecker nehmen, ist sogar besser.

Dass PCs von Haus aus keine V24-Schnittstelle mehr haben, ist bedauerlich, aber nicht zu ändern, in Zukunft muss man eben USB-To-V24 einsetzen, für solche Zwecke am besten gleich innerhalb des PC-Gehäuses.

Für V24 spricht auch, dass es Alternativen gibt: ich schliesse gerade alte Geräte mit V24-over-Ethernet an. Da dies fast völlig transparent ist (virtuelles COM), würde dein Bedienteil es softwaremässig nicht einmal merken, wenn man es über ein Patchkabel anschliesst (da gibts auch wasserdichte) und mit Power-Over-Ethernet versorgt. Es wäre also ziemlich zukunftssicher.

Du solltest bei der Software allerdings darauf achten, ausreichende Timeout- und Antworts-Zeiten vorzusehen, es gibt ja keine direkte physikalische Verbindung mehr. Eine Antwort in 5 msec wäre nicht mehr garantiert.

Ich verwende übrigens Lantronix XPort. Damit könnte man meine Analysegeräte auch vom Strand in Florida aus steuern, aber die Netzwerkadmins in der chemischen Industrie waren davon noch nicht so recht zu überzeugen und wollten doch lieber ein eigenes lokales Netz dafür.

Gruss Reinhard

3

Hallo Peter,

Du schreibst unten:

  1. Die Spannungsversorgung für das Bedienteil vom Slave (also
    vom Gerät) aus erfolgen muss.

Das ist prinzipiell bei USB nicht vorgesehen.

Gilt die Frage dem abgesetzten Gerät oder dem Bedienteil? Was ist Deine Aufgabe? Beides?

Bedienteil: Wenn das Bedienteil durch einen PC ersetzt werden kann, müsste es, wie der PC, den USB-Host enthalten. Einen USB-Slave einzusetzen ist nicht zu schwierig, aber einen Host bzw. Master in ein uC-gesteuertes Gerät? Ich würde das nicht in Erwägung ziehen, weil ich es für zu aussichtslos halte. Es sei denn, statt uC kommt da gleich ein embedded PC 'rein. Vielleicht sehe ich auch zu schwarz. Das gleiche gilt für USB-OTG.

Abgesetzten Gerät: Wenn Dich das Bedienteil nicht interessiert (denn da müsste jetzt der Host drin sein), sollte ein USB-Slave im Gerät nicht zu tragisch sein. Wer keine USB-Controller konfigurieren (programmieren) mag, könnte eins der USB-auf-Seriell-ICs einsetzen, so dass intern wieder seriell ist (nur teilweise V.24, weil die Pegeltreiber nicht benötigt werden). Allerdings gerade heute habe ich wieder Ärger mit einem solchen Kabel gehabt: Bei ECHO xxxxxx >COM5 gingen 1 bis 3 Zeilen 'raus, dann war der Port abgestürzt, aber bei ECHO xxxxxx >COM1 gab’s keine Probleme. Also: Ich tät’s nicht. Wenn schon, dann die harte Tour, uC mit USB-Controller. Ist aber auch Mist, weil da braucht man eine Vendor-ID, dafür muss man Mitglied im USB.ORG sein (sind wir), kostet einen Haufen Geld, ein eigener Treiber muss her, der ist auch nicht garantiert stabil (aber man kann ihn wenigstens korrigieren)… Haben wir bei uns so gemacht (allerdings mit einer wesentlich komplizierteren Anwendung, bei der der USB 2.0 unter Volldampf steht).

Über das Verbindungskabel muss die Stromversorgung und die
bidirektionale Datenverbindung.

Die Spannungsversorgung für das Bedienteil vom Slave (also
vom Gerät) aus erfolgen muss.

Das Gerät versorgt das Bedienteil. Dann sind wir wieder beim USB-Host im Gerät. Dann kann der PC nicht das Bedienteil ersetzen, weil der auch Host bzw. Master ist. Oder USB-Specs ignorieren, das könnte auch gehen, weil vielleicht sowieso ein Adapterkabel gebraucht wird (s. u.).

  1. Der etwas höhere Entwicklungsaufwand

Siehe die harte und die leichte Tour

  1. Die Stecker. Es müssen verriegelbare und einigermassen
    dichte Steckverbindungen verwendet werden. Das Gerät wird zwar
    in einer Laborumgebung eingesetzt, es wird aber mit Lacken
    gearbeitet und da kanns mal auf den Stecker tropfen.

Scheint mir eher ein kleines Problem. Bei Full Speed kannst Du jeden Stecker nehmen (nur High Speed ist kritisch), aber zum PC müsste ein Adapter her. Der könnte auch gleich den Spannungsausgang des Geräts vom Spannungsausgang des PCs trennen.

  1. Wie sieht es mit den Treibern für Vista, insbesonders
    Vista64, aus? Muss der Gerätespezifische Treiber auch von MS
    signiert sein ?

Bei der harten Tour: Ja, Treiber erforderlich. Unsere Treiber arbeiten unsigniert, kein Problem. Aber die Sache mit der Vendor-ID!

V.24 hat nur den Nachteil, dass man einen USB V.24
Adapter benötigt, das Treiberproblem müssen dann andere lösen
:wink:

Haben die auch, aber nach meiner und der Erfahrung Anderer eher schlecht als recht. Risiko! Plan B zurecht legen! (Z. B. andere Adapter-ICs vorbereiten und testen.)

Wie schätzt ihr das ganze ein ?

Schei… Nachteile bei jedem Lösungsansatz. Die Wahl zwischen Teufel und Belzebub.

Reinhards Ansatz mit dem XPort und Ethernet: Den XPort setzen wir auch ein. Man ist „nicht sehr glücklich“ mit dem erforderlichen Parametrierungsaufwand, der für „unsereins seine Versuche“ kein Problem ist, aber beim Kunden schon. Ich habe ein Manual für die Kunden dafür geschrieben, 10 Seiten, und bevor das fertig war, musste ich es wegen geänderter Firm- und Software überarbeiten. Jetzt verhandeln wir mit Lantronix, eine Funktion, die im Rahmen des Firmwareupdates gestrichen wurde, wieder zu bekommen (bis dahin müssen wir alle XPorts downgraden) - 'ne Menge Theater. Ich bin gegen XPort in einem solchen Projekt, weil wir genau das schon haben.

Grüße, viel Erfolg

Uwe

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

4

Reinhards Ansatz mit dem XPort und Ethernet: Den XPort setzen
wir auch ein. Man ist „nicht sehr glücklich“ mit dem
erforderlichen Parametrierungsaufwand, der für „unsereins
seine Versuche“ kein Problem ist, aber beim Kunden schon. Ich
habe ein Manual für die Kunden dafür geschrieben, 10 Seiten,
und bevor das fertig war, musste ich es wegen geänderter Firm-
und Software überarbeiten. Jetzt verhandeln wir mit Lantronix,
eine Funktion, die im Rahmen des Firmwareupdates gestrichen
wurde, wieder zu bekommen (bis dahin müssen wir alle XPorts
downgraden) - 'ne Menge Theater. Ich bin gegen XPort in einem
solchen Projekt, weil wir genau das schon haben.
…

Hallo Uwe,

das man am XPort hunderte Sachen einstellen kann, ist schon richtig. Mein Ansatz, damit fertig zu werden:

  1. Der Kunde kauft sein Interface bei mir und bekommt ein fertig konfiguriertes XPort.

  2. (Daran arbeite ich im Moment) Die pro Gerät individuell einzustellenden Parameter werden in die Geräte-Einstellungen aufgenommen, d.h. die Software wird erweitert um die Eingabe von IP-Adresse, Maske und Portnummer, das wird dann beim Start eingestellt.

  3. Die PC-seitige Software arbeitet nicht mit virtuellen Com-Ports, sondern baut selbst TCP-Verbindungen zu den Geräten auf.

Fazit: der Kunde kommt mit Lantronix-Software überhaupt nicht mehr in Berührung. Die Alternative über ein reales Com-Port erhalte ich in der Software allerdings bis auf weiteres, da dafür von mir Hardware mit Lichtleitern und optischen Multiplexern (extrem betriebsicher) zur Verfügung steht.

Gruss Reinhard

5

Hallo Reinhards,

ja, ich muss Dir Recht geben. Jetzt, wo Du es schreibst, fällt’s mir auch wieder ein. Die ganze unbefriedigende Situation ergibt bzw. ergab sich bei uns dadurch, dass mehrere unterschiedliche Applikationen mit mehreren Geräten betroffen waren, und alle nur RS-232 kannten und konnten. Die Softwareabteilung hat, aus welchem Grund auch immer, „abgelehnt“, alles auf Win-Socks (so heißt das, glaube ich) umzustellen, obwohl das für eine einzelne Applikation kein Problem ist. Eine entwicklungsinterne Applikation haben wir auch, bei der das läuft. Konsequenz bei uns: COM-Port-Redirektoren und der ganze Stress damit.

Also, zur Ehrenrettung des XPort: Es geht auch ohne Stress.

Punkt-zu-Punkt-Verbindungen (Gerät - Bedienteil), also ohne einen PC oder ein Netzwerk, in das die zwei XPorts eingebettet wären, haben wir noch nicht getestet, aber es müsste auch gehen.

Grüße

Uwe

das man am XPort hunderte Sachen einstellen kann, ist schon
richtig. Mein Ansatz, damit fertig zu werden:

  1. Der Kunde kauft sein Interface bei mir und bekommt ein
    fertig konfiguriertes XPort.

  2. (Daran arbeite ich im Moment) Die pro Gerät individuell
    einzustellenden Parameter werden in die Geräte-Einstellungen
    aufgenommen, d.h. die Software wird erweitert um die Eingabe
    von IP-Adresse, Maske und Portnummer, das wird dann beim Start
    eingestellt.

  3. Die PC-seitige Software arbeitet nicht mit virtuellen
    Com-Ports, sondern baut selbst TCP-Verbindungen zu den Geräten
    auf.

Fazit: der Kunde kommt mit Lantronix-Software überhaupt nicht
mehr in Berührung. Die Alternative über ein reales Com-Port
erhalte ich in der Software allerdings bis auf weiteres, da
dafür von mir Hardware mit Lichtleitern und optischen
Multiplexern (extrem betriebsicher) zur Verfügung steht.

Gruss Reinhard