Modbus Timeout ab 30 Registereinträgen

Hi Leute,

im Grunde steht mein Problem schon im Titel, ich habe einen West 6100+ Temperaturregler, die Komunikation läuft über RS485 "2Wire-Auto". Soweit so gut, nun will ich erstmal alle Parameter
auslesen, wobei das Register einträge mit den Adressen 1-35, sowie 129-130 hat.
Allerdings bekomme ichbereits einen timeout Fehler sobald der Quantity Wert größer als 30 ist. es spielt auch keine Rolle wie groß ich den Timeout mache ab 30 Werten ist schluss, jetzt wollte ich mal fragen in wie weit es Sinn macht die Parameter einfach einzeln mittels for schleife Abzufragen, bzw. worrauf ich dann achten muss? Wäre für Tipps und Anregungen Dankbar!

PS: ich hab die NI Modbus Libary und Labview 8.0

Anzeige

Das kann ich mir schon vorstellen.
Bei MODBUS-TCP ist z.B. bei ca. 120 U16-Registern auf einmal Schluss, mehr geht. Könnte also sein, dass bei der RTU-Implementation bei 30 Registern Ende ist - alternativ gibt dein Gerät nicht mehr auf einmal zurück.

Alles einzeln abfragen geht natürlich, kostet halt Zeit. Kompromiss: Teil es doch in 3 Pakete auf, Adresse 1-17, 18-35, 129-130.

Gruß, Jens

ok habe inzwischen eine akzeptabele lösung. jeden wert einzenl mit einer for schleife abzurufen war sehr inefizient, die Zykluszeit war ca. 2,7 sek. lang. Statt dessen rufe ich nun Immer Packete von 20 Werten ab wodurch die Zykluszeit auf etwas unter 400ms gefallen ist. Auf jeden macht es keinen Sinn sich 5 oder 6 einzelne nicht zusammenhängende paramater herrauszupicken und einzelnd
abzurufen, da das bedeutend länger lauert...

falls jemand eine noch "schnellere lösung hat immer her damit.

Edit:
Hi Jens, ja da bin ich auch drauf gekommen, das schein die Beste Lösung zu sein. s.u.

Noch'n Tick schneller: Frag doch beim 2. und 3. Mal wirklich nur die Anzahl an Registern ab, die du brauchst, also 15 und 2, sind immerhin ca. 13 Bytes weniger Übertragung. Sollte bei 9600 Baud theoretisch eine Zeitersparnis von ca. 13 ms bedeuten.
Bau die U16-Arrays nicht zu einem 2D-Array zusammen, sondern zu einem 1D-Array (per Build-Array und Schieberegister in der For-Loop).

Gruß, Jens

Hey Jens,

danke für den Tipp, habe es jetzt so gemacht, dass ich 20 und 15 parameter in der schleife abrufe und anschließend noch einmal 14 ich benötige hier zwar nur ein paar der ersten und die zwei letzten, aber das aufteilen in zwei schritte kostet knapp 100 ms, so wie es jetzt ist benötigt das abrufen ca 290 ms ich denke das ist ein Wert mit dem man laben kann. So werd dann mal weiter
tüfteln. einen schönen tag noch

(11.10.2012 07:58 )Pitt schrieb:  Hey Jens,

danke für den Tipp, habe es jetzt so gemacht, dass ich 20 und 15 parameter in der schleife abrufe und anschließend noch einmal 14 ich benötige hier zwar nur ein paar der ersten und die zwei letzten, aber das aufteilen in zwei schritte kostet knapp 100 ms, so wie es jetzt ist benötigt das abrufen ca 290 ms ich denke das ist ein Wert mit dem man laben kann. So werd dann mal weiter
tüfteln. einen schönen tag noch

Eine Frage, was sind das alles für Parameter? Typischerweise haben die Teile zwar viele Register aber nur sehr wenige wo sich stetig ändernde Werte in befinden. Um die Einstellungsregister jedesmal mitzulesen macht wenig Sinn.

Eine andere Randbemerkung: West Controller sind zwar verhätnismässig billig aber damit hat sich dann schon mehr oder weniger alles über sie gesagt. Ich musste mal eine Datenloggerapplikation schreiben für ein System wo unter anderem auch West Controller in sassen. Die Dinge sind nicht nur im Ansprechen über die Kommunikationsschnittstelle relativ problematisch. Ich hatte während der Inbetriebnahme und Tests der Software zweimal, dass ich mit einem davon nicht mehr zuverlässig kommunizieren konnte, und Tests ergaben dass der entsprechende Controller auch andersweitig nicht mehr so funktionierte wie er sollte. Der Kunde bestätigte mir, dass sie per Jahr meist zwei bis drei davon ersetzen müssen weil sie nicht mehr korrekt funktionieren. Da wird ein billiger Controller im Laufe der Zeit doch ein ziemlich teures Teil, sicher in einer Testanlage die 365 Tage im Jahr ununterbrochen laufen sollte, wie es dort der Fall war.

Zitat:Eine Frage, was sind das alles für Parameter?

Also genau das war die erste Zielsetzung ich habe zunächst ein Programm geschrieben, das alle Parameter ausließt, diese habe ich dann über ihre Indices mit einer Dokumentation verknüpft, so dass man sich durchschalten kann und angezeigt bekommt um welchen Parameter es sich handelt. Außerdem kann man die Werte dann auch direkt ändern. Das ich später auch mit sehr viel weniger Werten auskomme, nachdem man die Regler konfiguriert hat ist mir natürlich auch klar, aber es musste erstmal schnell gehen... Warum ich Westregler hab, weil ich nur Praktikum mache und das Programmiere was mir gegeben wird... Emko Regler hab ich auch noch rumliegen, um die kümmere ich mich morgen... bisher wurden die Dinger alle händisch eingestellt, und das von Leuten die von Regelung nicht so viel plan haben... bzw. die Regelparameter wurden nicht an die Anforderungen angepasst, da Überschwingen eigentlich nicht statt finden darf...

Noch ein Verbesserungsvorschlag für deine Abfrage:

- Wozu erst Schleife mit 2 Durchläufen und dann nochmal eine Abfrage hinterher? Pack doch alles in eine Schleife mit 3 Durchläufen.
- Nutze die Autoindizier-Funktion, soll heißen, anstatt einer Case-Struktur IN der Schleife kommt vor die Schleife eine Array-Konstante mit deinen 3 Abfrage-Enums.
- Anstatt Insert-Into-Array würde ich mit "Build-Array" arbeiten, macht es etwas übersichtlicher. Noch performanter wäre natürlich Replace-Array-Subset, aber diese Optimierung durch Vorbelegung des Arrays kann man sich bei den paar Elementen getrost sparen.

Gruß, Jens

Enum in Array, da muss man erst mal drauf kommen das macht die sache natürlich gleich ein ganzes stück einfacher ! Danke für den Tipp. Hoffe das mit dem Replacment hab ich so richtig gemacht...

PS: nicht wundern, im vierten durchlauf werden dann die diskreten werte abgerufen...