LogView ist mir schon bei der Suche aufgefallen, so wie ich die Beschreibung verstanden habe, funktioniert das (nur?) mit bestimmten Geräten (hauptsächlich Modellbau-Lader und Daten-Logger):

Zitat :

Sie suchen eine Visualisierungslösung für die meisten Ihrer Ladegeräte und Datenlogger? Dann sind Sie bei LogView an der richtigen Adresse.

Hallo zusammen

Ja genau!
LogView funktioniert nur mit einer bestimmten (Geräte)Liste für die es geschrieben wurde.

Gruß

Roland

Zitat :

irgend etwas Einfaches, wo man auch gesendete und empfangene Zeichen in einem Fenster gesehen hat

das hier?
http://www.elektronik-labor.de/RS232/2010Terminal.html


_________________
*..da waren sie wieder, meine 3 Probleme: 1)keiner 2)versteht 3)mich
* Immer die gültigen Vorschriften beachten und sich keinesfalls auf meine Aussagen verlassen!

Zitat : Harald73 hat am 18 Dez 2013 19:32 geschrieben :

das hier? http://www.elektronik-labor.de/RS232/2010Terminal.html

Das ist zwar nicht das, was ich meinte, habe es aber mal ausprobiert.
Eine Antwort vom Gerät kommt zwar nicht, mit Brücke RX-TX wird der gesendete Text aber gleich wieder empfangen und im Programm angezeigt.
Die PC-Schnittstelle und das Kabel sind also in Ordnung.

Irgendwas fehlt offenbar noch, aber was?

[ Diese Nachricht wurde geändert von: Tom R. am 18 Dez 2013 22:50 ]

Ist das Protokoll der Messgeräte und die Schnittstelleneinstellungen bekannt? Ist bekannt, was und wie an die Geräte gesendet werden muss, damit was vernünftiges zurückkommen kann?

Ich erinnere mich an einen digitalen Meßschieber, der eigentlich auch eine serielle Schnittstelle hatte. Über diese Schnittstelle wurden aber keinesfalls irgendwelche Zeichen mit einer bestimmten Baudrate gesendet. Es war etwas ganz wildes, ein Kollege hatte sich damit näher beschäftigt.

Rafikus

Zitat :

Irgendwas fehlt offenbar noch, aber was?

Vielleicht verwendest du schlicht das falsche Verbindungskabel.
Bei der RS-232 herrschte ja ständige Konfusion ob nun auf 2 oder auf 3 gesendet wird.
Dementsprechend brauchst du entweder ein 1:1 Kabel, oder ein gekreuztes (Nullmodem).

P.S.:

Zitat :

. Es war etwas ganz wildes, ein Kollege hatte sich damit näher beschäftigt.

Ich auch. Allerdings bei einer Mikrometerschraube von Mauser.
Das ist ein asynchroner rein binärer langer Datenblock, 14 Bit oder so, und er wird sehr schnell gesendet mit ca. 100kBaud. Außerdem ist der Pegel entsprechend der eingebauten Knopfzelle nur 1,5V.
Allerdings hat auch nie jemand behauptet, das da ASCII rauskäme, oder V24 Pegel.
Die Meßschieber aus dem Supermarkt haben übrigens auch diese Schnittstelle, nur der passende Stecker fehlt regelmäßig.



[ Diese Nachricht wurde geändert von: perl am 18 Dez 2013 23:10 ]

Ja. Die Befehle sind bekannt.

Zitat :

Gossen Netzteil: *RST (=Reset) *IDN? (=Anforderung Geräteidentifikation z.B. GOSSEN-METRAWATT,SSP32N040RU006P,XXXXXXXXX,04.001) USET 10 (=10V einstellen) USET? (=Einstellung auslesen Spannung) ISET 3 (=3A einstellen) ISET? (=Einstellung auslesen Strom) OUTPUT ON (=Ausgang einschalten) OUTPUT OFF (=Ausgang ausschalten) UOUT (=Ausgangsspannung auslesen) IOUT (=Ausgangsstrom auslesen) RS232-Kabel (ungekreuzt): RX-RX TX-TX GND-GND Terminierung der Gerätenachrichten bei RS-232-Steuerung: Beim Datenempfang werden als Endezeichen akzeptiert: NL (0Ahex) = New Line = Line Feed CR (0Dhex) = Carriage Return CR LF Carriage Return und Line Feed ETB (17hex) ETX (03hex) Beim Senden erhält der Antwortstring als Endezeichen: NL (0Ahex) = New Line = Line Feed

Zitat :

Agilent Netzteil: *RST (=Reset) *IDN? (=Anforderung Geräteidentifikation z.B. HEWLETT-PACKARD,E3632A,0,X.X-X.X-X.X) VOLT 10 (=10V einstellen) VOLT? (=Einstellung auslesen Spannung) CURR 3 (=3A einstellen) CURR? (=Einstellung auslesen Strom) APPLY 9.5,2.8 (=9,5V und 2,8A einstellen) APPLY? (=Einstellungen auslesen Spannung:Strom) OUTP ON (=Ausgang einschalten) OUTP OFF (=Ausgang ausschalten) OUTP? (=Ausgangstatus auslesen ON|OFF) RS232-Kabel (Nullmodem): RX-TX TX-RX DSR-DTR DTR-DSR CTS-RTS RTS-CTS GND-GND DCD-DCD RI-RI DTR / DSR Handshake Protocol The power supply is configured as a DTE (Data Terminal Equipment) device and uses the DTR (Data Terminal Ready) and DSR (Data Set Ready) lines of the RS-232 interface to handshake. The power supply uses the DTR line to send a hold-off signal. The DTR line must be TRUE before the power supply will accept data from the interface. When the power supply sets the DTR line FALSE, the data must cease within 10 characters. To disable the DTR/DSR handshake, do not connect the DTR line and tie the DSR line to logic TRUE. If you disable the DTR/DSR handshake, also select a slower baud rate to ensure that the data is transmitted correctly. The power supply sets the DTR line FALSE in the following cases: 1 When the power supply’s input buffer is full (when approximately 100 characters have been received), it sets the DTR line FALSE (pin 4 on the RS-232 connector). When enough characters have been removed to make space in the input buffer, the power supply sets the DTR line TRUE, unless the second case (see next) prevents this. 2 When the power supply wants to “talk” over the interface (which means that it has processed a query) and has received a <new line> message terminator, it will set the DTR line FALSE. This implies that once a query has been sent to the power supply, the bus controller should read the response before attempting to send more data. It also means that a <new line> must terminate the command string. After the response has been output, the power supply sets the DTR line TRUE again, unless the first case (see above) prevents this. The power supply monitors the DSR line to determine when the bus controller is ready to accept data over the interface. The power supply monitors the DSR line (pin 6 on the RS-232 connector) before each character is sent. The output is suspended if the DSR line is FALSE. When the DSR line goes TRUE, transmission will resume. The power supply holds the DTR line FALSE while output is suspended. A form of interface deadlock exists until the bus controller asserts the DSR line TRUE to allow the power supply to complete the transmission. You can break the interface deadlock by sending the <Ctrl-C> character, which clears the operation in progress and discards pending output (this is equivalent to the IEEE-488 device clear action).

Ich vermute, der Hund ist irgendwo in der blauen Absätzen begraben.
Nur verstehe ich nicht wirklich, was damit gemeint ist...

Zitat :

RS232-Kabel (ungekreuzt): RX-RX TX-TX GND-GND

Hast du mal kontrolliert, ob das passt?
Du brauchst nur einem Voltmeter nachzusehen, ob auf Pin2 der (negative!) Sendepegel des einen und auf Pin3 der Sendepegel des anderen Geräts anliegt.

http://de.wikipedia.org/wiki/RS232

Das 1:1-Kabel ist in Ordnung (alle 9 Pins belegt und durchgeklingelt).
Paßt also fürs Gossen.

Beim Nullmodem-Adapter sind die Pins 1-1 (DCD) und 9-9 (RI) nicht durchgeschleift. Keine Ahnung ob die überhaupt benutzt werden.
Werde morgen wohl mal sicherheitshalber ein neues Kabel zusammenlöten.

[ Diese Nachricht wurde geändert von: Tom R. am 19 Dez 2013  0:43 ]

Zitat :

Das 1:1 Kabel ist in Ordnung (alle 9 Pins belegt und durchgeklingelt).

Es geht nicht darum, ob das Kabel in Ordnung ist, sondern ob es die richtigen Pinkombinationen herstellt!

Es muss Tx des einen auf Rx des anderen Geräts landen und umgekehrt.
So lange du das aber nicht misst, oder in einer verbindlichen Quelle nachgesehen hast, weiss zumindest ich nicht, welchen Pins Tx und welchen Rx bei jedem Gerät zugeordnet ist.
Das kann (und muss sogar bei Verwendung eines 1:1 Kabels) verschieden sein!

Ob da ein Männchen oder Weibchen dran ist, ist ebenfalls kein Kriterium.

Zitat : perl hat am 19 Dez 2013 00:52 geschrieben :

Es geht nicht darum, ob das Kabel in Ordnung ist, sondern ob es die richtigen Pinkombinationen herstellt!... So lange du das aber nicht misst, oder in einer verbindlichen Quelle nachgesehen hast, weiss zumindest ich nicht, welchen Pins Tx und welchen Rx bei jedem Gerät zugeordnet ist.

Ich habe das Kabel durchgemessen UND die verbindliche Quelle (=Manuals) oben zitiert:

Gossen braucht 1:1-Kabel, Agilent Nullmodem-Kabel.

Umgekehrt habe ich es natürlich auch schon ausprobiert.






Das Gossen reagiert ja zumindest auf x-beliebige (auch unsinnige) Eingaben vom Terminal-Programm aus mit Aufleuchten der Remote-LED am Gerät.

Und das Agilent piepst kurz und zeigt Error im Display, wenn ich den Port vom Terminal aus schließe.







[ Diese Nachricht wurde geändert von: Tom R. am 19 Dez 2013  1:23 ]

Dann stimmt vermutlich die Baudrate und/oder die Parity und/oder Bitzahl nicht.
Dazu steht allerdings in den geposteten Texten nichts.

Bei vielen Geräten kann man diese Parameter an einem "Mäuseklavier" einstellen, oder daran ablesen.
Etliche Geräte bestimmen die Übertragungsgeschwindigkeit auch selbst, indem sie die Dauer des Startbits des allerersten Zeichens, das sie nach der Herstellung der Verbindung (DSR,DTR) empfangen, ermitteln.
Typischerweise ist dieses erste Zeichen ja eine Leerzeile, also nur <Enter> bzw. CR und/oder LF.
Wenn man zu diesem Zeitpunkt etwas anderes, also Text, schickt, kann diese Automatik fehlgeleitet werden.

Ansonsten ist eine gebräuchliche Einstellung 1200 Baud, 7 Bit, No Parity.
Die Zahl der Stopbits ist unwesentlich.
Bei den ganz alten Akustikkopplern wurde auch mit 300 Baud gearbeitet.

P.S.:
Wenn viele Daten zu übetragen waren, etwa bei Druckern, wurden auch 9600 Baud verwendet, aber das war normalerweise die Obergrenze für Peripheriegeräte mit bis zu 15m langen Leitungen.



[ Diese Nachricht wurde geändert von: perl am 19 Dez 2013  2:13 ]

Gossen-default:
9600 baud, 8N1 (Baudrate und Stoppbits im Gerät konfigurierbar)

Agilent-default:
9600 baud, 8N2 (Baudrate im Gerät konfigurierbar)






[ Diese Nachricht wurde geändert von: Tom R. am 19 Dez 2013  2:20 ]