Hallo,
weiß von euch jemand wie man RS232 zu einem Agilent Netzteil hinbekommt?
Ich habe mir einen Logilink FTDI RS232 Adapter + Nullmodemkabel besorgt
und versuche das Ganze unter Linux mit minicom zu verbinden.
Als Verbindungsparameter habe ich 9600 Baud, None 8 Bits konfiguriert.
Alles was ich vom Agilent da bekomme ist ein Piepsen und ERROR.
Ich tippe schon langsam darauf dass das Agilent Netzteil nicht mit einem
gewöhnlichen Nullmodemkabel funktioniert?
Thomas schrieb:> Ich tippe schon langsam darauf dass das Agilent Netzteil nicht mit einem> gewöhnlichen Nullmodemkabel funktioniert?
Im Manual
http://www.utsc.utoronto.ca/~quick/PSCB01H3S/Documentation/HPE3640.pdf
ist auf Seite 60 das Kabel beschrieben.
Leider gibt es manchmal unterschiedliche "Interpretationen" von
"Nullmodemkabel". Klingel dein Kabel doch mal durch, ob es mit dem
beschriebenen übereinstimmt.
Weitere mögliche Probleme, die mit spontan einfallen:
- die Baudrate ist verändert und nicht mehr auf "factory setting".
- wahrscheinlich arbeitet die Schnittstelle mit Hardware Handshake. Ist
das so eingestellt?
- Probleme mit Logilink?
- ...
Gruß Dietrich
Die USB Adapter sind ja klasse... liefern eine CD mit aber mein Notebook
hat kein Laufwerk mehr. Online findet man alle möglichen verseuchten
Treiber-Installer-Viren.
Agilent sollte da besser anfangen etwas nachzubessern und ihre Netzteile
kompatibel machen ... RS232 bewerben und dann nicht mit Standard-RS232
Hardware funktionieren besser geht's nicht :-(
Dietrich L. schrieb:> - wahrscheinlich arbeitet die Schnittstelle mit Hardware Handshake. Ist> das so eingestellt?
das "wahrscheinlich" nehme ich zurück: im Manual steht, das es wirklich
so ist.
Gruß Dietrich
> Agilent sollte da besser anfangen etwas nachzubessern und ihre Netzteile> kompatibel machen ... RS232 bewerben und dann nicht mit Standard-RS232> Hardware funktionieren besser geht's nicht :-(
Laut Diagramm und Speck im Handbuch ist das standardkonformes RS-232.
Wenns nicht funktioniert hast Du ein kaputtes Kabel oder einen kaputten
USB-RS232-Wandler erwischt. Oder einfach die falschen Einstellungen.
Oder das Gerät ist defekt.
Nix für ungut.
Hallo,
Thomas schrieb:> Die USB Adapter sind ja klasse... liefern eine CD mit aber mein Notebook> hat kein Laufwerk mehr. Online findet man alle möglichen verseuchten> Treiber-Installer-Viren.
Hol Dir die Treiber vom der Seite des Chipherstellers
http://www.ftdichip.com/Products/Cables/USBRS232.htm> Agilent sollte da besser anfangen etwas nachzubessern und ihre Netzteile> kompatibel machen ... RS232 bewerben und dann nicht mit Standard-RS232> Hardware funktionieren besser geht's nicht :-(
Jammer nicht rum, überprüfe lieber die Belegung Deines Nullmodemkabels,
setzte die Übertragungseinstellungen am PC und am Netzteil auf gleiche
Werte und schicke die richtigen Befehle an das Netzteil, dann geht's.
Mit freundlichen Grüßen
Selbsternannter Weltverbesserer
Es funktioniert mit dem Connection Expert.
Deren Samplecode für Linux funktioniert anscheinend nicht oder es
benötigt irgendeine komische Initialisierung die ich noch nicht kenne.
Anscheinend macht der Connection Expert genau das richtige ... habe
aber auch über den Connection Manager schon ERRORS am Netzteil
getriggert....
Nach einigem rumspielen funktioniert es jetzt auch so halbwegs unter
Linux.
Die Ansteuerung ist grausam, erinnert mehr an irgendwelche
unzuverlässige Schnittstellen von diversen Firmen von vor 15 Jahren.
Aktuell hängt die Kommunikation einfach nach einiger Zeit, es wird wohl
noch irgendwelche Timing Probleme geben.
Am Besten wäre es wohl wenn Keysight dafür eine Bibliothek ausliefern
würde welche die ganzen Kommunikations-Fehler auf der Softwareseite
überdeckt - wenn sie RS232 schon nicht ordentlich hinbekommen.
So richtig zufrieden macht das alles nicht, da gibt's deutlich bessere
und billigere Lösungen um das zu erledigen was ich möchte. Zudem das
Netzteil auch ein lästiges 50Hz Brummen und einen Lüfter mit sich bringt
(das günstigere China NT das ich hier habe ist passiv gekühlt und hat
auch kein Brummen).
Die Agilent Ausführung finde ich für den Preis sehr schwach...
Die Lösung für das Problem:
http://stackoverflow.com/questions/17073969/agilent-66332a-dc-source-rs232-ubuntu-12-04-scpi
while :; do echo -en ':MEASURE:VOLT:DC?\n' > /dev/ttyUSB0; sleep 0.5;
done
in einem anderen Fenster
cat /dev/ttyUSB0
Es werden einige Befehle einfach nicht ausgeführt.
Auch in den Kommentaren von dem nicht funktionierenden Beispiel findet
sich
// Receives a character from the serial port,
// or times out after 10 seconds.
// success = 0 if timeout, 1 if successful
Sprich die Kommunikation ist unzuverlässig, habe es in einem C Programm
implementiert - dort ist das Verhalten gleich.
g457 schrieb:> Wenns nicht funktioniert hast Du ein kaputtes Kabel oder einen kaputten> USB-RS232-Wandler erwischt.
Der USB-RS232-Wandler muss gar nicht kaputt sein. Schon wenn er kein
Hardware-Handshake unterstützt, wird die Kommunikation unzuverlässig
oder funktioniert gar nicht.
Entweder man benutzt die Buttons am NT oder die RS232 Schnittstelle,
beides benutzt wohl den gleichen Pfad intern und kann sich in die Quere
kommen.
Ich habe die Auslese-Geschwindigkeit noch etwas runtergesetzt jetzt
scheint's besser zu funktionieren.
Als Adapter verwende ich diesen hier:
[134836.631129] usb 8-1: Product: USB-Serial Controller D
[134836.631134] usb 8-1: Manufacturer: Prolific Technology Inc.
[134836.633215] pl2303 8-1:1.0: pl2303 converter detected
[134836.645370] usb 8-1: pl2303 converter now attached to ttyUSB0
Thomas schrieb:> Als Adapter verwende ich diesen hier:
Du darfst hier auch Links verwenden :-(
Google findet nichts ( z.B. "[134836.631134]")
Steht da explizit bei, dass die die vom Agilent verwendeten
Handshake-Leitungen Treiber- und Hardwareseitig unterstützen? Die
Fähigkeiten der verwendeten Bausteine und der Aufbau des Adapters sind
noch zwei verschiedene Dinge.
> Der USB-RS232-Wandler muss gar nicht kaputt sein. Schon wenn er kein> Hardware-Handshake unterstützt [..]
Das fällt in die Kategorie 'kaputt', Hardwareflusskontrolle ist
Bestandteil von RS-232.
> Es werden einige Befehle einfach nicht ausgeführt.
Hast Du das Timing beachtet? Einfach wild drauflosballern wie in einer
while-schleife z.B. ist nicht vorgesehen, zumindest nicht mit allen
Kommandos. Wo kommt bei Dir der führende Doppelpunkt her? Der hat dort
üblicherweise auch nichts verloren.
> Sprich die Kommunikation ist unzuverlässig,
Ja, auf ∗Deiner∗ Seite :-)
Nachtrag: Frag auch regelmäßig mal die Fehlerschlange ab, die gibt u.U.
Hinweise, was Du flasch machst. Und zum Üben solltest mit was einfachem
wie IDN anfangen, erst wenn Du das hundert mal hintereinander
zuverlässig abfragen kannst, hast Du die Kommunikation auf Deiner Seite
halbwegs im Griff.
HTH
</ingrid>
Thomas schrieb:> Auch in den Kommentaren von dem nicht funktionierenden Beispiel findet> sich> // Receives a character from the serial port,> // or times out after 10 seconds.> // success = 0 if timeout, 1 if successful>> Sprich die Kommunikation ist unzuverlässig
Das spricht für vollkommenes Unverständnis: dass ein Programm zur
Datenübertragung eine Fehlerbehandlung hat, ist ein Zeichen für die
Qualität des Programms, bzw. eigentlich selbstverständlich, und beweist
keineswegs dass die Kommunikation nicht funktioniert.
Georg
g457 schrieb:> Das fällt in die Kategorie 'kaputt', Hardwareflusskontrolle ist> Bestandteil von RS-232.
'kaputt' ist er nur, wenn er sich nicht so wie die anderen "heilen"
Geräte einer Serie verhält. In deinem Sinne wäre USB-RS232-Wandler, die
die Hardware-Handshake-Leitungen nicht unterstützen, gar keine
USB-RS232-Wandler. Nur kommen damit Millionen von Geräten gut zurecht,
weil sie SW-Handshake benutzen und damit nur einen Teil der möglichen
Übertragungsarten. So 'kaputt' können die dann wohl nicht sein.
> In deinem Sinne wäre USB-RS232-Wandler, die die Hardware-Handshake-> Leitungen nicht unterstützen, gar keine USB-RS232-Wandler. Nur kommen> damit Millionen von Geräten gut zurecht [..]
Wie Du siehst eben nicht. Wer RS-232 daufstehen hat soll als
universeller Controller auch RS-232 vollständig unterstützen. Teilmengen
davon kann man immernoch vereinbaren. Ein Controller, der das trotzdem
draufstehen hat obwohl er es nicht kann ist ab Werk kaputt (nicht
notwendigerweise defekt). Endgeräte dürfen jederzeit eine Teilmenge
implementieren.
Aber wir schweifen vom eigentlichen Thema ab, den programmatischen
Fehlern bei der Kommunikation beim TO.
g457 schrieb:> Wer RS-232 daufstehen hat soll als> universeller Controller auch RS-232 vollständig unterstützen
Das ist Unsinn, denn eine solche Definition gibt es schlicht nicht.
Serielle Schnittstellen können eine ganze Menge Statussignale haben,
oder eben auch nicht - RI z.B. kann einem Modem melden, dass jemand
anruft, das geht aber auch ohne das Signal mit dem Hayes-Kommandosatz,
bloss ist der genausowenig genormt, und ausserdem war er zu Zeiten der
Bundespost in Deutschland verboten. Andere Normen waren z.B. X25, aber
eben für Modems und nicht für irgendein "RS232". Heute vermisst niemand
RI und auch nicht eineges andere, was es auf dem 25poligen Stecker gab.
Georg
> Serielle Schnittstellen können eine ganze Menge Statussignale haben [..]
Klar, heissen dann aber nicht notwendigerweise RS-232. SPI zum
Bleistift. Oder TWI. Oder SATA.
> Andere Normen waren z.B. X25 [..]
Da steht nicht nur zufällig nicht RS-232 drauf ;-)
Aber lass uns endlich zum Thema zurückkehren und gespannt auf des TOs
Entwicklungen warten. Falls Du weiter über serielles diskutieren
möchtest und warum eine UART alleine kein RS-232 macht, dann mach doch
bitte einen eigenen Fred in OT auf.
Nach dem pl2303 Adapter hab ich's noch mit dem FTDI RS232 Adapter
versucht, bei beiden gibt's derzeit nach ca 2-3 Stunden Fehler wenn die
Stromstärke alle 200ms ausgelesen wird. Als Error bekomme ich invalid
character. Wenn der Intervall auf 100ms gesetzt wird gibt's nur noch
Fehler.
Werde versuchen das Delay noch etwas hochzusetzen, zuverlässig sieht für
mich aber anders aus. Das sind doch nur 9600 Baud, die Adapter werden
üblicherweise mit embedded Geräten und 56k verwendet und da gibt's
keinerlei Probleme..
Nur 9600 Baud, dafür 20 (10 hin, 10 zurück) Datensätze/Sekunde? Da
dürfen schon mal (theoretisch!) max. 48 Bytes pro Datensatz anfallen.
Verarbeitungszeit am jeweiligen Ende nicht mit eingerechnet.
Dazu noch geschätzt 10 ms Delay im Adapterchip pro Richtungswechsel.
Diese Chips versuchen intelligenter als der Benutzer zu sein und
speichern z.B. erst mal in einen Puffer.
Das dann noch aus der relativ lahmen Shell heraus? Bei einer anderen
Anwendung, die nur Datensätze schickt und auf ein "ok" wartet, bevor sie
den nächsten Satz schickt, komme ich auf bestenfalls 5
Datensätze/Sekunde, trotz 115200 Baud. Die Shell (Bash) ist für solche
Zwecke relativ lahm. Aus einem Python-Skript heraus geht's deutlich
schneller, doch immer noch weit unter dem theoretischen Maximum.
Ausserdem ist 1 fehlerhaftes Zeichen von einer Million nicht so völlig
aus der Welt. Solche Geschichten sind auch oft für GND-Schleifen
anfällig, da Sender und Emfänger zwar an verschiedenen Netzteilen
hängen, aber auf der Übertragungsstrecke nicht galvanisch getrennt sind.
Es ist also Fehlertoleranz gefragt.
Mit einem 250ms Intervall scheint es nun stabil zu sein 9 Stunden ohne
Fehler.
Somit ist mein Problem gelöst, schade das Agilent/Keysight das nicht
besser gelöst hat. Für den Preis doch etwas schwach.
Thomas schrieb:> schade das Agilent/Keysight das nicht> besser gelöst hat.
Auf das Problem zwischen Stuhl und Bildschirm haben die relativ wenig
Einfluss.
Ich geb auf, das Netzteil bereitet irgendwie schon wieder Probleme hin
und wieder liefert es jetzt Werte; Aber meist meldet es invalid
character.
Es hat mal ne Zeit lang funktioniert aber jetzt nach einer Woche wo ich
es wieder benötigen würde geht's wieder nicht.
Kennt jemand ein Labornetzteil mit USB oder RS232 und das auch
funktioniert?
Von Agilent will ich nichts mehr, ich hatte in den letzten Jahren sehr
viel mit RS232 und Embedded Systemen zu tun und hatte noch nie solche
Probleme. Für die Schwierigkeiten ist Agilent einfach zu teuer.
Agilent ist unfähig RS232 funktionabel zu implementieren, wenn der
Puffer voll ist sollten sie einfach einen Errorcode zurückliefern aber
nein sie überschreiben den internen Puffer. Die Knöpfe sind zudem nicht
vom RS232 Port entkoppelt.
Das NT an sich ist nett aber RS232 wurde von den größten Pfuschern bei
Agilent implementiert.
Es wundert mich doch immer wieder wenn ich dieses Agilent Netzteil
anrühren muss.
Sind die Agilent Netzteile wirklich so unzuverlässig und sollte man in
Wirklichkeit eher die Finger von Netzteilprodukten dieser Firma lassen?
Eigentlich hatte ich den Eindruck das die Firma einen guten Ruf hat
(aber auch teuer ist), die Erfahrungen mit dem Netzteil sind derart
schlecht das ich praktisch gesehen das Ganze Jahr über mein billiges
chinesisches Netzteil verwendet habe.
Ich würd's ja einsehen wenn das Problem vor dem Bildschirm sitzen würde,
aber die ganzen RS232 Adapter welche ich besitze funktionieren nun mal
einwandfrei mit anderen Systemen - nur Agilent zickt da rum, man darf
diese Netzteile blos nicht überfordern (und das ist nicht das erste
Agilent Netzteil das ich getestet habe).
Selbst Biterror durch Masseschleifen (wenn das Notebook über die
Batterie läuft) sind zu 100% ausgeschlossen. Das einzige Problem das
hier noch sein könnte wäre dass das Agilent Netzteil für Störungen
sorgt.
Kann diese seriellen Probleme mit Agilent Netzteilen jemand bestätigen?
Dann kann ich die Fehlersuche endgültig aufgeben.
Hier ein schönes Beispiel bei 9600 baud:
mehrmals *IDN?
Alent Tehnologies,E3640A,01.8-5.0-.0
Agilent Technologies,E3640,0,1.8-5.0-1.0
Agilent TechnologesE3640A,0,1.8-5.0-1.0
Agilent Tchnolges,E3640A,0,1.85.-10
Agilen Technologies,E3640A,0,1.8-5.0-1.0
Was Agilent hier produziert hat (und Keysight übernommen hat) ist
absoluter Schrott der sein Geld nicht wert ist, mit jedem Arduino
schwätze ich ohne Verlust 115kbit. Diese Netzteile schaffen ja nicht mal
9600 ordentlich (und das ist bereits das Maximum). Es ist nicht nur ein
Netzteil sondern es sind wohl alle Netzteile dieser Serie davon
betroffen. Da ich das bei mindestens 3 getestet habe und alle das
gleiche Resultat liefern.
Das Netzteil wird von einem Notebook angesteuert, also nichts da mit
Groundloop, alle anderen Geräte funktionieren ja auch.
