+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: Hardware (/Forum-Hardware)
+---- Forum: 3rd Party Hardware (/Forum-3rd-Party-Hardware)
+---- Thema: Serieller Mess-Bus (DIN Mess-Bus) (/Thread-Serieller-Mess-Bus-DIN-Mess-Bus)
Seiten: 1 2
Serieller Mess-Bus (DIN Mess-Bus) - Lucki - 01.09.2009 14:57
' schrieb:Im Lieferumpfang des Gerätes war das passende Kabel dabei, es ist jedoch nicht aufzufinden...Wie kommst Du überhaupt auf die durch nichts belegbare Behauptung, daß das Gerät einen "DIN Mess-Bus" hat??
Ja, die Pin-Belegung ist anders, das habe ich auchs schon festgestellt. hab mir auch ein passendes Kabel zusammengelötet, bei dem ich einfach nur die kabel vertauscht habe, es funzt trotzdem nicht...
Der Gerätebeschreibung und Steckerbelegung nach ist es eine ganz normale RS232-Schnittstelle.
Auszug aus dem Flyer:
Ausgänge
Analogausgang 0 bis 8,2 V (parametrierbar) kurzschlussfest und fremdspannungssicher bis 40 V Ausgangswiderstand 2 kΩ
serielle Schnittstelle V24 (RS232), 38400 Baud, kaskadierbar mit weiteren Geräten
RS232 ist eine Zweipunkt-Schnittstelle, kein Bus. "Kaskadierbar mit weiteren Geräten" heißt: Jedes Gerät hat 2 SubD-Anschlüsse. Damit lassen sich mehrere Geräte "kaskadieren" (= in Kette schalten). Das ist ewas anderes als ein Bus.
Kontrolliere doch noch mal, ob Du den richtigen SubD-Anschluß ausgewählt hast, der zum PC gehen muß. Der Einsatz eines Schnittstellen-Testadapters kann auch hilfreich sein.
Serieller Mess-Bus (DIN Mess-Bus) - Oeric - 02.09.2009 08:22
' schrieb:Wie kommst Du überhaupt auf die durch nichts belegbare Behauptung, daß das Gerät einen "DIN Mess-Bus" hat??
Das ist eine gute Frage...
Ich habe mich natürlich versucht im INet schlau zu machen. In der Anleitung steht, dass es sich bei dem Gerät um einen SMB (serieller Mess-Bus) handelt. Speziell zum SMB habe ich INet nur diesen kleinen Artikel gefunden:
http://www.qe-online.de/qeve/fachartike...l/10016460.html
Der hilft mir aber nicht wirklich weiter. Danach habe ich mich mit der Pinbelegunge beschäftigt.
Wenn man die meines SMB mit der von http://www.pci-card.com/schnittstellen.html vergleicht, dann sieht man, dass sie anders belegt sind.
Hab jetzt bisschen gelötet um die Pinbelegung anzupassen, jedoch passiert wieder nichts, es ist zum Mäusemelken.
Wäre es denn möglich, dass das Senden des Befehls so nicht richtig ist? Wieso muss ich die Geräteadresse mit 16 multiplizieren und dann den Befehlscode für die gewünschte Information dazu addieren? So wurde es von Lucki gemacht.
Benutze ich sein Programm zum ansteuern habe ich den schon beschriebenen Time-Out-Fehler. Nehme ich das Beispiel von NI "Serial_Write_and_Read" kommt dieser Fehler nicht.
Ich habe bis dato noch keine Erfahrungen mit richtiger Mess-Hardware machen können, daher bitte ich um Nachsicht. Für meine Studi-Arbeit durfte ich einen Bluetooth-GPS-Empfänger und die WiiMote als "Sensoren" programmieren. Hab gehofft, dass sich der Programmieraufwand mit richtigem Mess-Equipment verringert...
Serieller Mess-Bus (DIN Mess-Bus) - jg - 02.09.2009 20:56
' schrieb:Der hilft mir aber nicht wirklich weiter. Danach habe ich mich mit der Pinbelegunge beschäftigt.Schau wir mal, auf Grund deines Screenshots müsste dein Verbindungskabel LA4 <-> serielle Schnittstelle 9-polig-PC so aussehen:
Wenn man die meines SMB mit der von http://www.pci-card.com/schnittstellen.html vergleicht, dann sieht man, dass sie anders belegt sind.
Hab jetzt bisschen gelötet um die Pinbelegung anzupassen, jedoch passiert wieder nichts, es ist zum Mäusemelken.
LA4-Pin 1 - PC-Pin 2
LA4-Pin 2 - PC-Pin 3
LA4-Pin 6 - PC-Pin 5
' schrieb:Wäre es denn möglich, dass das Senden des Befehls so nicht richtig ist? Wieso muss ich die Geräteadresse mit 16 multiplizieren und dann den Befehlscode für die gewünschte Information dazu addieren? So wurde es von Lucki gemacht.Weil eine Anfrage an ein LA4 laut deiner Beschreibung aus einem Byte besteht. Von diesem Byte sind 4bits die Adresse des Geräts, weitere 4 bits der Befehl. Lucki geht davon aus, dass die 4 High-Bits die Adresse sind, deshalb Adresse mal 16, und schon sind es die 4 High-Bits. Ich hätte das auch erst mal so probiert.
Könnte natürlich sein, dass da die Beschreibung nicht so toll ist, also teste einfach folgendes: Nicht die Adresse, sondern den Befehl mit 16 multiplizieren und dann addieren, dann dieses Byte senden.
Was du auch noch versuchen könntest: Vielleicht ist das mit <CR> und <LF> aus deiner Beschreibung auch nicht korrekt? Also spiel mal rum, und warte nur auf 1 oder 2 byte bei der Antwort.
Und achte darauf, die korrekte Adresse (also hex 0 bis hex F) deines LA4 einzugeben.
Gruß, Jens
Serieller Mess-Bus (DIN Mess-Bus) - Oeric - 03.09.2009 15:46
DANK EUCH, meinem gelöteten Kabel und einem Firmware-Update funktioniert nun die Datenübertragung.
Möchte ich mir jedoch den Wert für den Sauerstoffgehalt in der Luft nach der Formel aus dem Handbuch
(HighByte*256 + LowByte)/10 ausrechnen, bekomme ich nichts gescheites raus. Der Sauerstoffgehalt in der Luft ist rund 20 %, mein VI rechnet mir aber einen Wert von mehr als 1000 aus. Es reagiert auch ganz komisch wenn ich den Sauerstoffgehalt durch anpusten senke. erst steigt mein errechneter wert, dann sinkt er irgendwann auf 0, biss er wieder auf den Wert vor dem Pusten zurückgeht.
Ich danke Euch schonmal.
edit: kann das an der zweiten typenformung liegen?
LabVIEW Version 8.6
Serieller Mess-Bus (DIN Mess-Bus) - Oeric - 03.09.2009 16:45
' schrieb:edit: kann das an der zweiten typenformung liegen?
LabVIEW Version 8.6
Hab das Problem gefunden. Musste bei der zweiten Typenformung eine 0-F konstante nehmen, jetzt gehts!
JUHU
ICH DANKE EUCH VIEL MALS!!!!!
Serieller Mess-Bus (DIN Mess-Bus) - Lucki - 03.09.2009 16:53
Wie ich sehe, ist mein VI auf wenig fruchtbaren Boden gefallen. Schade. So kann es nicht funktionieren.
Vor allem: Der Sendebefehl ist ein byte, die Antwort besteht immer aus drei bytes. Diese 3 Byte mußt Du auch empfangen, auch wenn Du 2 davon (CR und LF) nicht brauchst! Du kannst die nicht einfach im Empfangspuffer stecken lassen und denken das erledigt sich von selbst.
Habe mal 2 Varianten im VI benutzt, um die beiden Bytes zusammenzubringen.
Ein typisches Anfänger-Feature ist übrigens die extensive überflüssige Verwendung von Sequenzrahmen, siehe Dein VI.
[attachment=21011]
Serieller Mess-Bus (DIN Mess-Bus) - jg - 03.09.2009 19:59
' schrieb:Vor allem: Der Sendebefehl ist ein byte, die Antwort besteht immer aus drei bytes. Diese 3 Byte mußt Du auch empfangen, auch wenn Du 2 davon (CR und LF) nicht brauchst! Du kannst die nicht einfach im Empfangspuffer stecken lassen und denken das erledigt sich von selbst.@Lucki: Daran bin vielleicht ich Schuld?! Ich habe empfohlen, wenn es mit Warten auf 3 Byte nicht klappt (schließlich gabs da mal Timeout-Fehler), es mal mit 2 oder 1 byte zu versuchen. Wie geschrieben, ich traue da der Anleitung nicht unbedingt. Ich tippe zwar auch darauf, dass 3 Byte als Antwort kommen, aber wer weiss, wer weiss. Aber das muss Oeric testen, nur er hat die Hardware.
Ansonsten ist deine Wandlung der emfangenen Bytes natürlich x-mal besser...
@Oeric: Also, nochmals, erst mit Warten auf 3 Bytes testen, wenn es klappt und keine Timeouts gibt, dann alles Paletti und Lucki hat die Anleitung komplett richtig interpretiert. NUR wenn es mit Warten auf 3 Byte nicht funzt, dann mit 2 oder 1 Byte testen!
Gruß, Jens
Serieller Mess-Bus (DIN Mess-Bus) - Oeric - 04.09.2009 16:50
so,
nun habe ich drei LAs in Kette aneinandergesetzt und neheme insgesamt 9 Werte auf. Da ich die Werte nur nacheinander aufnehmen kann, muss ich sie seriell abfragen.
Zwischen der ersten Werteaufnehme und der letzten verstreicht eine Zeit von ca. 0,1 sec, sprich, ich sollte für eine adequate Auswertung jedem aufgenommenen Wert seine eigene Aufnahmezeit zuweisen.
Mein Problem ist nun, dass ich die Werte nicht über einen Zeitstempel sondern über die verstrichene Zeit seit dem Aufnahmebeginn speichern muss. Dies ist in einem weiteren von mir verwendeten Programm begründet, dass Messungen nur über die verstrichene Zeit aufnehmen kann. Ich habe ein kleines VI geschrieben, dass einen gleichzetigen Aufnahmestart von LabVIEW und dem zusätzlichen Programm ermöglicht. So ist die Synchronisation der Daten einfacher.
Wie komme ich es nun hin die verstrichene Zeit seit Aufnahmebeginn, also seit Betätigung des Schalters, zu errechnen. Gibt es eine Möglichkeit?
Ich habe mehrere Möglichkeiten mit "Tick Count" ausprobiert, jedoch hat alles nicht gefunzt. Gibt es eine Möglichkeit sich nur den aller ersten Zeitwert nach betätigung des Schalters ausgeben zu lassen, mit dem ich dann alle weiteren verrechnen kann.
Also dass ich in jeder Sequenz einen "Tick Count" einsetze und von dem Wert den Tick-Count-Wert bei Aufnahmebeginn subtrahieren kann?
Vielen Dank für eure Mühen!
WIE IMMER MIT LabVIEW 8.6 erstellt
Serieller Mess-Bus (DIN Mess-Bus) - Oeric - 10.09.2009 12:13
hab die lösung gefunden.
schieberegister machts...
nochmals vielen dank für eure hilfe, bis zum nächsten mal
