Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Hallo!
Ich hab ein kleines Problem mit der Ansteuerung mittels mehrere RS232 Schnittstellen.
Mein Problem ist das ich ein Messgerät und einen Mikrokontroller der eine Relaiskarte schaltet, gleichzeitig ansteuern und auslesen soll. Wenn ich die Geräte einzeln ansteuere, funktioniert alles einwandfrei, versuche ich aber beide anzusteuern, wie ich es benötige, dann erkennen die Geräte die Befehle nicht.
Das komische daran ist, wenn ich die "Highlight Funktion" im Blockdiagramm einschalte, ist auch kein Problem vorhanden, deshalb vermute ich, wird es sich um ein timing Problem handelt.
Ich hoffe es kann mir jemand helfen.
Noch ein paar Infos:
Schnittstelleneinstellung Messgerät:
7 Datenbits
Parität = Gerade
2 Stopbits
keine Ablaufsteuerung
Baudrate 9600
Schnittstelleneinstellungen µP:
8 Datenbits
Parität = keine
1 Stopbits
keine Ablaufsteuerung
Baudrate 9600
Hab das Programm mal angehängt.
Anzeige
05.02.2013, 11:18 (Dieser Beitrag wurde zuletzt bearbeitet: 05.02.2013 11:23 von GerdW.)
- ich sage nur "Aufräumknopf"...
- Sequenzstrukturen sind überbewertet...
- man muss nur vom vordefinierten Standard abweichende Konstanten verdrahten...
- ich bezweifle, dass die Funktion "BytesAtPort" (mitsamt Wartezeit) die richtige Wahl bei aktiviertem TermChar ist...
- ich vermute, dass eine Wartezeit von 1s etwas lang ist, wenn man nur auf ein paar Bytes warten will...
- ich würde parallele Schleifen, eine pro Schnittstelle, bevorzugen
Funktioniert die Kommunikation, wenn du pro Schnittstelle ein eigenes VI verwendest?
- ich sage nur "Aufräumknopf"...
- Sequenzstrukturen sind überbewertet...
- man muss nur vom vordefinierten Standard abweichende Konstanten verdrahten...
- ich bezweifle, dass die Funktion "BytesAtPort" (mitsamt Wartezeit) die richtige Wahl bei aktiviertem TermChar ist...
- ich vermute, dass eine Wartezeit von 1s etwas lang ist, wenn man nur auf ein paar Bytes warten will...
- ich würde parallele Schleifen, eine pro Schnittstelle, bevorzugen
Funktioniert die Kommunikation, wenn du pro Schnittstelle ein eigenes VI verwendest?
Also hab jetzt das VI mal aufgeräumt (Entschuldige das ichs nicht gleich gemacht hab), die Sequenzen hab ich rausgenommen.
Meinst du mit den vordefinierten Standards die Werte der Bausteine die dieser besitzt, wenn man ihn ins Blockdiagramm hineinzieht?
Die Verzögerung von 1sec hab ich rausgenommen, die Funktion "Bytes at Port" benötige ich aber und hab sie deshalb drinnengelassen.
Ich hab auch nur eine Schleife verwendet, die ich nun mit einer einer Verzögerung von 1sec immer wieder durchlaufen lasse.
Die Kommunikation funktioniert wenn ich ein eigenes VI verwende, ich hatte nur Probleme, wenn ich zwei Schnittstellen verwende.
Ich danke für deine Hilfe, denn jetzt funktionierts auch mit zwei Schnittstellen.
Zitat:die Funktion "Bytes at Port" benötige ich aber
Du arbeitest mit aktivierten TermChars, also brauchst du die Funktion BytesAtPort nicht...
- Die 1s-Wartezeit wird dich früher oder später stören! Momentan fragst du mit dem VISARead eher die Antwort zum VISAWrite aus der vorherigen Iteration ab, ist das gewollt?
Probier das hier mal aus:
(Falls deine Geräte längere Antworten als 99 Byte senden, musst du dort anpassen...)
Zitat:die Funktion "Bytes at Port" benötige ich aber
Du arbeitest mit aktivierten TermChars, also brauchst du die Funktion BytesAtPort nicht...
- Die 1s-Wartezeit wird dich früher oder später stören! Momentan fragst du mit dem VISARead eher die Antwort zum VISAWrite aus der vorherigen Iteration ab, ist das gewollt?
Hallo,
Die Funktion "Bytes at Port" benötige ich noch für eine spätere Funktion die ich in meinem gesamten Projekt verwende, aber sonst hatte ich auch eine fixe einstellung (z.B. 99 Bytes).
Die Wartezeit von 1sec habe ich deshalb, da das Messgerät und mein µP die Relais schalten müssen und damit ausreichend Zeit vorhanden ist, habe ich die Wartezeit so gewählt.
Mir ist schon aufgefallen das ich immer die Antwort von der vorherigen Interation erhalte, hab aber zurzeit keine Lösung wie ich das ändern kann, grundsätzlich wärs für meine Funktion egal, da qasi der letzte Befehl den ich rüberschicke das Messgerät beendet und ich dann keine Antwort von ihm bekomme. Ich bin aber jederzeit bereit eine "saubere" Lösung zu gehen.
Was meinst du das es früher oder später stören könnte?
Wie könnte ich die nötige Zeitverzögerung für die Relais schaffen, damit diese mit bestimmter Sicherheit, alle umgeschalten haben?
05.02.2013, 16:46 (Dieser Beitrag wurde zuletzt bearbeitet: 05.02.2013 16:47 von GerdW.)
Zitat:Ich bin aber jederzeit bereit eine "saubere" Lösung zu gehen.
Die saubere Lösung besteht darin, auf BytesAtPort zu verzichten und die Antwort der Geräte (mitsamt TermChar) abzuwarten...
Zitat:Wie könnte ich die nötige Zeitverzögerung für die Relais schaffen, damit diese mit bestimmter Sicherheit, alle umgeschalten haben?
Du brauchst also diese Sequenz:
- Befehl zum Relais-Schalten abschicken
- Geräteantwort dazu abwarten
- evtl. kurze Wartezeit (100ms sollten für jedes Relais reichen - wir reden doch nicht von großen Schützen?), falls dein Gerät erst antwortet und dann schaltet...
- Messwertabfrage abschicken
- Messwert empfangen - mit TermChar, man will ja schließlich den aktuellen Messwert haben...
- wieder von vorn beginnen...
hab deine Ratschläge befolgt, die Wartezeit hab ich jetzt von einem Befehlsantwort abhängig gemacht. Die Wartezeit ist nun von der Antwort abhängig und beträgt nun so 400 bis 500ms (der µP bekommt jetzt ein hardwaremäßiges Feedback wenn die Relais durchgeschalten sind), ich hab zwar keine Schütze aber dafür schalte ich immerhin 136 Relais (braucht halt seine Zeit).
Vielen Dank für deine Hilfe und Ratschläge, hat mir enorm weitergeholfen.
12.02.2013, 09:23 (Dieser Beitrag wurde zuletzt bearbeitet: 12.02.2013 09:25 von rolfk.)
(05.02.2013 13:16 )PMG schrieb: Die Verzögerung von 1sec hab ich rausgenommen, die Funktion "Bytes at Port" benötige ich aber und hab sie deshalb drinnengelassen.
Ich hab auch nur eine Schleife verwendet, die ich nun mit einer einer Verzögerung von 1sec immer wieder durchlaufen lasse.
Bytes at Port ist in 99.9999% der Fälle garantiert nicht ideal und meist sogar total falsch!
Entweder ist die Message "TermChar" terminated und dann nimmt man einfach ein Read dem man den Auftrag gibt um mehr Characters zu lesen dann die Message je sein kann, und ein Timeout und dann lässt man das VISA Read warten bis die Message reinkommt, oder das Protokoll ist binair und hat eine bekannte Länge (selbst wenn die Daten variabel sind, hat es sicher einen fixed size Header in dem die Länge der darauf folgenden Daten steht)! Auch hier verwendet man ein VISA Read dem man den Auftrag gibt die entsprechende Anzahl Bytes zu lesen (möglicherweise zwei oder mehr VISA Reads um erst den Header und dann die Variablen Daten zu lesen). Zu keinem Zeitpunkt braucht man vorab zu wissen wieviele Daten im VISA Buffer anwesend sind.
Verwendung von Bytes at Serial Port führt über kurz oder lang zu einem absolut unwartbaren Instrumenttreiber da man immer mehr Code hinzufügen muss um zu verhindern dass man jeweils abgebrochene Messages bekommt, als auch dass man nicht Stücke von vorherigen Messages verliert.
Denn man kann nie bestimmen wann in der Message die Funktion Bytes at Port aufgerufen wird und dann liest man beinahe zwangsläufig Bruchstücke der Message. Diese muss man dann selber noch mal analysieren ob sie eine ganze Message beinhalten, und eventuel inkomplete Messages in einem eigenen Buffer abspeichern und bei der nächsten gelesenen Bruchstückmessage hinzufügen usw. Wenn man schlussendlich einen Treiber hat der keine abgebrochenen Messages zurückgibt und auch keine Bruchstücke von Messages einfach wegwirft ist man unzählige Stunden und ausgeraufte Haare weiter, und hat ein VI Monster das man nicht mal mit der Feuerzange mehr anfassen will, aus Angst dass jede kleinste Veränderung irgendwo wieder einen Fehler introduziert. Wenn man dagegen ganz ohne Bytes at Serial Port arbeitet hat man diese Probleme alle nicht, der Code ist klar und deutlich und man hat auch noch Stunden und Tage an Zeit gespart, nicht zu sprechen von Nerven und Haaren.
/
Verwendung von mehreren RS232 Schnittstellen
