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?
Kannst die Verbindung/das Kabel ja erst mal unter Win testen: http://www.keysight.com/main/software.jspx?ckey=1000001038%3Aepsg%3Asud&lc=ger&cc=DE&nid=-11143.0.00&id=1000001038%3Aepsg%3Asud
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.
Ich geh auch davon aus das der Fehler auf deiner Seite liegt, 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.