06.08.2019, 13:44
Hallo zusammen,
ich beschäftige mich seit einiger Zeit mit seriellen Schnittstellen und verwende aktuell eine Nantotec C5-E Motorsteuerung mit einem NEMA-23 Schrittmotor. Die Steuerung ist über USB und einer RS485 (mit DS402) Schnittstelle mit dem PC verbunden, Betriebssystem ist Windows 7.
Ich bau an einem umfangreichen VI indem ich mehrere subVI's aufrufe und ausführe. Jedoch bereitet mir das read VI öfter Probleme.
Kurze Erläuterung zum Programm: Ich schreibe in die Steuerung den Befehl "Motor fahren" (bei CANopen mittels Controlword ist es eine Befehlskette) -> solange der Motor fährt und keine Befehle geschrieben werden, führe ich das im Anhang aufgeführte read_ever.VI aus, welches mir die aktuelle Motorposition ausgibt. Das VI read_ever funktioniert auch anfangs.
Jedoch, aus einem mir unbekannten Grund, liefert die Funktion "VISA Read" ein offensichtlich falschen String im "read buffer"
Geschrieben wird der String (als Beispiel):
4E54 000F 052B 0D00 0001 6062 0000 0000 04F8 6D
dabei ist 6062 00 das Register für die Position
Als Antwort kommt üblicherweise dieser String:
4E54 0013 052B 0D00 001 6062 0000 0000 04EA FEFF FFF4 E5
dabei ist der Anfang des Strings der Header und bleibt immer gleich, dann das Register 6062 00, dann die Antwortlänge 0000 0004, dann die Antwort in Hex-Dezimal für die Position FEFF FFF4 E5
(Der letzte Teil ist der, der sich üblicherweise mit der Taktrate ändert) -> soweit funktioniert alles
JETZT ABER gibt das VISA Read plötzlich folgendes aus:
0000 AEE9 4E54 0013 052B 0D00 001 6062 0000 0000 049B FF
Der Header stimmt nichtmehr, sodass meine Positionsantwort eine null ergibt. Insgesamt sieht die Antwort verschoben aus.
Ich habe bereits versucht die Zeit zwischen VISA Write und VISA Read zu verlängern, jedoch ohne erfolg. Die Taktrate von 250ms sollte mehr als genug sein um die Schnittstelle nicht zu "überladen".
Kann mir bitte jmd helfen und sagen wie ich diese Fehlantwort umgehen kann?
PS: im VI: das setzen der Konstanten und die Indicator-Array dienten einem anderen Zweck, der hier jetzt nicht so relevant ist.
LG
Markus
ich beschäftige mich seit einiger Zeit mit seriellen Schnittstellen und verwende aktuell eine Nantotec C5-E Motorsteuerung mit einem NEMA-23 Schrittmotor. Die Steuerung ist über USB und einer RS485 (mit DS402) Schnittstelle mit dem PC verbunden, Betriebssystem ist Windows 7.
Ich bau an einem umfangreichen VI indem ich mehrere subVI's aufrufe und ausführe. Jedoch bereitet mir das read VI öfter Probleme.
Kurze Erläuterung zum Programm: Ich schreibe in die Steuerung den Befehl "Motor fahren" (bei CANopen mittels Controlword ist es eine Befehlskette) -> solange der Motor fährt und keine Befehle geschrieben werden, führe ich das im Anhang aufgeführte read_ever.VI aus, welches mir die aktuelle Motorposition ausgibt. Das VI read_ever funktioniert auch anfangs.
Jedoch, aus einem mir unbekannten Grund, liefert die Funktion "VISA Read" ein offensichtlich falschen String im "read buffer"
Geschrieben wird der String (als Beispiel):
4E54 000F 052B 0D00 0001 6062 0000 0000 04F8 6D
dabei ist 6062 00 das Register für die Position
Als Antwort kommt üblicherweise dieser String:
4E54 0013 052B 0D00 001 6062 0000 0000 04EA FEFF FFF4 E5
dabei ist der Anfang des Strings der Header und bleibt immer gleich, dann das Register 6062 00, dann die Antwortlänge 0000 0004, dann die Antwort in Hex-Dezimal für die Position FEFF FFF4 E5
(Der letzte Teil ist der, der sich üblicherweise mit der Taktrate ändert) -> soweit funktioniert alles
JETZT ABER gibt das VISA Read plötzlich folgendes aus:
0000 AEE9 4E54 0013 052B 0D00 001 6062 0000 0000 049B FF
Der Header stimmt nichtmehr, sodass meine Positionsantwort eine null ergibt. Insgesamt sieht die Antwort verschoben aus.
Ich habe bereits versucht die Zeit zwischen VISA Write und VISA Read zu verlängern, jedoch ohne erfolg. Die Taktrate von 250ms sollte mehr als genug sein um die Schnittstelle nicht zu "überladen".
Kann mir bitte jmd helfen und sagen wie ich diese Fehlantwort umgehen kann?
PS: im VI: das setzen der Konstanten und die Indicator-Array dienten einem anderen Zweck, der hier jetzt nicht so relevant ist.
LG
Markus