Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 31

Thema: Auslesen eines Temperatursensors über MODBUS an WAGO SPS

  1. #1
    Registriert seit
    15.05.2013
    Beiträge
    58
    Danke
    4
    Erhielt 7 Danke für 7 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo liebe SPSler,

    ich bin seit einigen Tagen Neueinsteiger in das Thema SPS, CoDeSys etc. Einige Sachen konnte ich schon hier im Forum nachlesen, und das hat mir den ersten Einstieg auch ermöglicht. Jetzt geht es für mich darum, einen Temperatursensor an eine SPS anzuschließen und über das MODBUS Protokoll auszulesen. So ganz ans Ziel komme ich leider noch nicht. Vielleicht einmal die wichtigsten Sachen zum System und der Konfiguration:
    WAGO 750-881 Controller
    750-653 MODBUS Klemme (die frei konfigurierbare)
    Über die MODBUS Bibliothek sind die beiden notwendigen Bausteine (Extended Slave und Master) konfiguriert. Die Baudrate, Parität etc. habe ich dabei nach der Modbusmap des Herstellers für beide Bausteine eingestellt:

    http://www.datanab.com/zc/docs/datan..._ModbusMap.pdf
    Den Modbus Dienst (function code) definiere ich ja über die Extended Query Abfrage.

    Einloggen kann ich mich nach Einstellen der IP etc., das klappt soweit. Da ich in diesem Thema aber wie gesagt komplett neu bin, fehlt mir das Verständnis für das weitere Vorgehen, also dem konkreten Abfragen des Sensors. Kann mir da vielleicht jemand einen Hinweis geben? Ich bin mir auch nicht ganz im Klaren darüber, wie die register in der Codesys eingegeben werden. Und wie muss ich in den Variablen der Klemme etwas konfigurieren? Dort sind ja unter der Steuerungskonfiguration 10 Eingangs- sowie 9 Ausgangsvariablen (Transmisison acknowledgment, etc.) angegeben, aber welche wie konfiguriert werden müssen ist mir leider nicht klar.

    Ich würde mich freuen, wenn jemand Ideen hat, wie das ganze ans laufen gebracht werden kann. Ich geb natürlich auch gerne weitere notwendige Angaben zu der aktuellen Konfiguration durch.

    Vielen Dank schon mal, viele Grüße
    Zitieren Zitieren Auslesen eines Temperatursensors über MODBUS an WAGO SPS  

  2. #2
    Registriert seit
    12.07.2011
    Beiträge
    19
    Danke
    0
    Erhielt 4 Danke für 4 Beiträge

    Standard

    Hallo SPS_A,

    zum Einstieg vielleicht mal einige grundlegende Infos:

    - Die 750-653 gestattet den Aufbau einer RS485-Strecke. Die beiden Leiter sind jeweils an der 653-Klemme und dem Sensor anzuschliessen. Je nach Datenrate, Leistungslänge und Störfaktoren über die Leitungsabschlüsse/Terminierung nachdenken.
    - Der Sensor benötigt zwingend eine eindeutige UnitID für die Modbuskommunikation (RS485 ist ein Bus mit evtl. mehreren Teilnehmren).
    - Als Software benötigst du nur die Master-Variante. Der Sensor ist Slave und läßt sich vom Master befragen.
    - Das Modbus-Protokoll ist ein Frage-Antwort-Spiel, soll heißen: Der Master schickt ein Telegramm und der Slave antwortet. Das Master-Telegramm kann eine Datenabfrage sein oder ein Schreibbefehl für Parameter bzw. Daten allgemein.
    - Der Sensor kennt zwei Datenbereiche: LIVE VALUES und CONFIG VALUES. Die CONFIG VALUES sind nur einmalig einzulesen bzw. zu setzen. Im laufenden Betrieb interessieren nur noch die LIVE VALUES.
    - Zum Lesen und Schreiben kennt das Modbus-Protokoll unterschiedliche Funktionen (Funktionscodes). Zusätzlich wird unterschieden, auf welchen Registerbereich (Eingangsdaten, Merker, Ausgangsdaten) das Lesen und Schreiben angewendet werden soll. Die LIVE VALUES sind Eingangsdaten und sollen gelesen werden. Daher ist hier der Funktionscode 4 (=Read Input Register) zu verwenden. Die CONFIG VALUES liegen im Merkerbereich (Holding Register). Sie sind mit der Funktion 3 (Read Holding Register) zu lesen. Geschrieben werden die CONFIG VALUES entsprechend mit der Funktion 6 (Write Single Register). Da hier nur die Funktion 6 genannt ist, lassen sich vermutlich nicht mehrere Werte in einem Telegramm beschreiben, sondern jeder Parameter nur einzeln.
    - Je nach verwendetem Masterbaustein für Modbus werden die Adressbereiche auf dem 881 als Pointer übergeben. D.h. du definierst dir ein Variable des entsprechenden Parametertyps und übergibst diese dem Masterbaustein mit der ADR()-Funktion. Das gilt sowohl in Lese- als auch Schreibrichtung.
    - Das Handbuch zum 653 sagt: Datenübertragung und Handshake parametrierbar mit WAGO-I/O-CHECK 2. Alternativ könnte das Teil des Masterbausteins sein.

    Das erst mal zum Einstieg.

    Auf eine muntere Konversation...

    Snert

  3. Folgender Benutzer sagt Danke zu Snert für den nützlichen Beitrag:

    SPS_A (13.06.2013)

  4. #3
    SPS_A ist offline Benutzer
    Themenstarter
    Registriert seit
    15.05.2013
    Beiträge
    58
    Danke
    4
    Erhielt 7 Danke für 7 Beiträge

    Standard

    Hallo Snert,

    vielen Dank für deine ausführliche Antwort. Zu deinen beschriebenen Punkten:

    - Die Strecke habe ich so aufgebaut. Beim 2-Leiter-Anschluss werden dann die Anschlusspunkte 1-2 und 5-6 überbrückt, und das Datenkabel geht dann von 1 und 5 an den Sensor. Die Strecke ist derzeit zum Testen nur ~0,5m lang.
    - Im vorliegenden Fall habe ich ja erst einmal einen Teilnehmer. Daher habe ich dem Slave einfach mal die Adresse "0" zugewiesen in der CoDeSys. Oder muss da an dem Slave ansich noch etwas eingestellt werden?
    - Ok, ich dachte das einerseits der Master konfiguriert wird und dann der Slave dementsprechend, damit baudrate etc. übereinstimmen. Es reicht also, in der CoDeSys den Master-Baustein zu konfigurieren?
    - So hatte ich mir das Protokoll auch ungefähr vorgestellt. Ich will ja im ersten Schritt, dass der Master eine Abfrage (zB aktuelle Temperatur) absendet, und die angeschlossenen Slaves antworten.
    - Über die Config Values wird also der Slave eingestellt? Also konkrekt bei dem Sensor die Farbübergänge zum Beispiel? Mein Einsatz war, über den Live Value mit entsprechender Funktion (4 - Read Input Register) überhaupt erst einmal einen Wert zu bekommen.
    - Das mit den Eingangs-/Ausgangsdaten bzw. dem Merker ist mir noch nicht ganz klar. Das es verschiedene Funktionscodes gibt, kann ich so nachvollziehen. Über die "Modbus Extended Query Abfrage" aus dem baustein habe ich als FunctionCode die 4 für Register lesen eingetragen
    - Den Punkt müste ich mir noch mal anschauen, da sind bei mir zugegebenermaßen noch viele Fragezeichen.
    - Genau, die FlowControl etc. kann sowohl im Masterbaustein als auch im I/O-Check eingetragen werden. Da habe ich für die 2-Leiter-Übertragung half-duplex (bekommt den Wert 4) eingetragen.

    Das waren auf jeden Fall sehr interessante Infos. So ganz habe ich aber noch nicht die zündende Idee, wie ich praktisch voran kommen könnte. Ich glaub der Knackpunkt ist derzeit der Teil mit dem Eintragen der Register. Ich versteh denke ich nicht wirklich den Zusammenhang bzw. die Einstellung zwischen der Klemme und dem Slave, bzw. welche Einstellungen dort noch wo zu treffen sind. Kannst du mir da vielleicht einen Gedankenanstoß geben?

    Vielen Dank nochmals, viele Grüße

  5. #4
    Registriert seit
    12.07.2011
    Beiträge
    19
    Danke
    0
    Erhielt 4 Danke für 4 Beiträge

    Standard

    Der Slave (Sensor) muss eine eigene UnitID eingestellt haben, entweder hardwaremäßig über DIP-Schalter oder Drehschalter oder softwaremäßig (vermutlich weniger der Fall). Diese UnitID ist dem Masterbaustein als Ziel-ID anzugeben, damit der Master die Telegramme auch richtig addressieren kann. Einfach so mal die "0" annehmen ist nicht zielführend!

    Konfiguriert wird nur der Master in der CoDeSys. Der Slave liegt ja "konfiguriert" als Hardware vor. Sichergestellt sein muss nur, dass beide die gleichen Parameter verwenden. Um es einfach zu halten, würde ich die Defaulteinstellungen des Sensors (UnitID=1, Baudrate=4800bps, Parity=keine, Stoppbits=2) verwenden. Wenn die Werte im Masterbaustein einstellbar sind, brauchst du womöglich kein i/O-Check verwenden.

    Die LIVE-Werte kannst du dann mit Funktionscode 4 einlesen. Der Datentyp ist "Float inverse", d.h. deine Variable ist grundsätzlich vom Typ REAL. Es kann sein, dass du die beiden Worte, aus denen der REAL-Wert besteht, umdrehen musst. Zu erkennen daran, dass die gelesen Werte keinen Sinn ergeben

    Du verwendest CoDeSys 2.3 (wegen des 881). Welche Bibliothek verwendest du, die deinen Masterbaustein enthält?

  6. #5
    SPS_A ist offline Benutzer
    Themenstarter
    Registriert seit
    15.05.2013
    Beiträge
    58
    Danke
    4
    Erhielt 7 Danke für 7 Beiträge

    Standard

    Hallo Snert,

    vielen Dank wieder für deine schnelle und ausführliche Antwort.

    Genau, verwendet wird CoDeSys 2.3, die Version 3 läuft ja soweit ich weiss nicht mit dem Controller. Für diese Zwecke ist die 2.3 aber hoff ich ganz gut und ausreichend. Verwendet wird die Bibliothek "Modb_l05" mit dem Masterbaustein "MODBUS_EXTENDED_MASTER", der ja laut Anleitung empfohlen wird. Die 0 anzunehmen war natürlich nicht so clever, da hab ich nicht richtig nachgedacht. Defaultmässig muss es ja die 1 sein (laut dem Datenblatt), genauso lassen sich dann ja die Bbaudrate (19200bps), keine Parität und 2 Stop Bit einstellen, wie auch von dir geschildert. Die erste Klemme müsste ja laut Anleitung bei "bCOM_PORT" eine 2 bekommen, ich hab auch nur eine Klemme in der Konfiguration. Aufgrund der 2-Leiter-Übertragung dann für Halfduplex die 4. Ich habe mal einen Screenshot von den Eingaben gemacht, die ich bisher reingepackt hab. Unbenannt.jpg

    Wie genau würde ich denn dann nun den Wert auslesen? Ich definiere eine Variable, zB. "Temperatur" des Typen REAL. Aber was genau hat es dann mit dem "Float Inverse" auf sich? Und wie stelle ich die Verbindung von FunctionCode zu dem was der Sensor liefert her? In dem Programm wird der functionCode abgefragt, und soll dann über RESP.functionCode ausgegeben werden. Aber da ist mir noch nicht ganz klar wie da die Verknüpfung ist, diese Abfrage hatte ich in einem beispiel gesehen.

    Vielleicht nochmal zum Verständnis was ich bisher dank deiner Hilfe hab: Der Master (Die SPS bzw. die Klemme) ist so konfiguriert, dass die Parameter mit den Default-Werten des Slave (Tempsensor) übereinstimmen. Prinzipiell kann nun also eine Abfrage zB. des Temperaturwerts gestartet werden. Dazu muss ja die Abfrage in irgendeiner Form definiert sein, dass der Slave damit was anfangen kann. Der knackpunkt in meinem Verständnis scheint somit grade zu sein, woher der Slave die Abfrage bekommt und wo das Register definiert wird, damit zwischen den unterschiedlichen Messwerten (CO2, Feuchte, Temp.) "unterschieden" werden kann.

    Ich kann mir gut vorstellen, dass diese Probleme für jemanden mit Erfahrungen in dem Bereich unverständlich sind. Für mich als absolutem Neuling auf dem gesamten Gebiet (MODBUS, serielle Schnittstellen allgemein, SPS) ist dies aber nicht immer so einfach zu durchdringen. Deswegen würd ich mich natürlich freuen wenn du mir noch weitere entscheidende Hinweise geben kannst.

    Vielen Dank aber nochmals für die bisherigen Antworten, Grüße

  7. #6
    Registriert seit
    12.07.2011
    Beiträge
    19
    Danke
    0
    Erhielt 4 Danke für 4 Beiträge

    Standard

    Ok, CoDeSys 2.3 mit MODBUS_EXTENDED_MASTER aus aktueller Modb_I05.lib - bin im Bilde.

    Dein Screenshot ist schon fast korrekt:

    - Statt 1920 als Baudrate ist als Defaultwert laut Datenblatt 480 zu nehmen.
    - Die cbsCOM_BYTESIZE mit 8 und cfCOM_FLOW_CONTROL mit 4 können richtig sein. Wenn es nicht funktioniert, muss man hier vielleicht noch einmal etwas anderes probieren.
    - Beim Timeout würde dem Baustein (gerade im Anfang) eine Chance geben und die Zeit auf den Defaultwert von min. t#500ms setzen.
    - Damit der Baustein anläuft solltest du "Start" mit TRUE vorbelegen in der Definition, also: Start:BOOL:=TRUE;
    - Ganz entscheidend für die Funktionalität des Ganzen ist die richtige Abarbeitungsreihenfolge der Anweisungen. Du solltest die Anweisungen untereinander setzen, beginnend mit der Extended-Query, dann den Master-Baustein und schließlich die Response. Danach rechter Mausklick -> Ausführungsreihenfolge -> nach Datenfluss wählen.

    Nach dem Herunterladen auf die Steuerung und dem Starten (F5) sollte in der Variable "Wert" (Elemente 0 und 1 des Arrays) etwas zu lesen sein. Wenn ein Fehler aufgetreten ist, dann steht in "Fehler", "ERROR" und/oder "ERROR2" etwas Interessantes.

    Zum Wiederholen der Modbus-Abfrage kannst du die Variable "Start" auf TRUE forcen (Doppelklick + F7) und das Forcen sofort wieder aufheben (SHIFT-F7).

    Den Temperaturwert erhälst du, wenn du die beiden Worte "Wert[0]" und "Wert[1]" zu einem REAL zusammenfügst. Dazu später mehr, wenn alles andere läuft

    Zum Verständnis:

    Mit den Werten am Eingang des Masterbausteins wird die Strecke "RS485" beschrieben. Die "ExtQuery" beschreibt mit SlaveAddress, FunctionCode, StartAddress und Quantity das Anfragetelegramm. Das Antworttelegramm wird entgegengenommen und als Einzelbestandteile in der "Response" abgelegt. Die abgefragten Werte stehen in "Response.Data". Physikalisch sorgt die 750-653 dafür, dass die Infos auf den beiden Drähten zwischen Sensor und Steuerung hin- und herwandern. Die anderen abfragbaren Werte bekommt man, wenn man die Read_StartAddress variiert zwischen 0 (CO2), 2 (Temperatur) und 4 (Feuchtigkeit).

  8. #7
    SPS_A ist offline Benutzer
    Themenstarter
    Registriert seit
    15.05.2013
    Beiträge
    58
    Danke
    4
    Erhielt 7 Danke für 7 Beiträge

    Standard

    Hallo Snert,

    vielen Dank erstmal wieder für deine schnelle und ausführliche Antwort.

    - Muss man sich bei der baudrate nicht auf den Slave beziehen? Die Klemme kann ja sozusagen "alles". laut der Modbus Map ist Default doch 4, was bei dem Device 19200 entspricht, oder?
    - Alles klar, könnte man dann ja, je nach Ergebnis anpassen.
    - Alles klar, hab den Wert angepasst.
    - ist vorbelegt
    - Alles klar, auch das ist erledigt.
    - das herunterladen und Starten hat geklappt. Fehler und ERROR 2 geben eine 0 aus. ERROR gibt MB_NO_ERROR aus, also sollten die Sachen soweit fehlerfrei sein. RESP.Data mit dem ausgang Wert ist grau hinterlegt, und oben in den lokalen Variablen ist das gesamte Array mit "0"en ausgefüllt.
    Das wäre ja super, wenn die Lösung zum tatsächlichen Ausgeben eines Wertes nicht mehr so fern wäre.

    Vielen Dank auch für die Verständniserweiterung. So in etwa habe ich das auch gedacht, ohne das mir die Abfragen "ExtQuery" und "Response" so ganz klar waren. Was ich nicht wusste ist, dass die 0/2/4 dann sozusagen die Register darstellen.

    Was mir noch einfällt: Die beiden Datenleitungseingänge von dem Sensor sind einfach mit "A" und "B" benannt. ich konnte noch nicht wirklich rausfinden, in welcher Reihenfolge die beiden an die Klemme müssen. Da fällt mir eigentlich nur das Ausprobieren ein, was ja nur eben das Kabel umklemmen ist. Der Hersteller hielt anscheinend nichts davon das konform zu der Klemme mit TxD zu beschriften. Oder gibt es da eine Konvention?

    Vielen Dank nochmals, ich freue mich sehr das du mir da so geholfen hast und hoffentlich noch bei den nächsten Schritten unterstützt.

    Viele Grüße

  9. #8
    Registriert seit
    12.07.2011
    Beiträge
    19
    Danke
    0
    Erhielt 4 Danke für 4 Beiträge

    Standard

    Die Baudrate ist natürlich 1920. Sorry, wer lesen kann, ist klar im Vorteil...

    Die Leitungen zu tauschen kann man ja mal probieren. Wenn es dann geht, ist ok.

    Dass ohne Fehler nur Nullen erscheinen könnte bedeuten, dass das Telegramm nicht gesendet wurde oder die Werte tatsächlich Null sind. Arbeitet der Sensor denn? Einfach mal mehrfach die Startfunktion forcen und schauen was passiert.

    Bei Neuigkeiten helfe ich gern weiter.

    Gruß,
    Snert

  10. Folgender Benutzer sagt Danke zu Snert für den nützlichen Beitrag:

    SPS_A (13.06.2013)

  11. #9
    SPS_A ist offline Benutzer
    Themenstarter
    Registriert seit
    15.05.2013
    Beiträge
    58
    Danke
    4
    Erhielt 7 Danke für 7 Beiträge

    Standard

    Hallo Snert,

    also, arbeiten tut der Sensor würd ich sagen einwandfrei. Das Display zeigt Werte für Feuchte/Temperatur/CO2 an, die auf jeden Fall realistisch sind. Auch das verfärben des Displays bei Überschreiten funktioniert. ich habe die kabel gerade eben getauscht und ein paar Durchläufe "geforct", und jetzt hat er tatsächlich einen Wert im ersten Feld des Array "Ausgespuckt". Für Wert [0] gibt er 17584 aus, bzw. beim neuen Versuch dann 17466 (StartAdress ist 0, also Anzeige von Co2, das muss dann noch umgerechnet werden, oder?). wie lange darf man diesen "Force" denn laufen lassen, oder ist das nicht "schlimmes"? Aber ich freu mich gerade schon, dass wenigstens ein Wert übertragen wird. Auch für die anderen register gibt er Werte um 17000 aus.

    Ich freu mich schon auf die nächsten Schritte, vielen lieben Dank bis hierhin

  12. #10
    Registriert seit
    12.07.2011
    Beiträge
    19
    Danke
    0
    Erhielt 4 Danke für 4 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Erste Erfolge! Sehr schön.

    Die Read_Quantity im Request muss noch auf 2 gesetzt werden, da der REAL-Wert aus zwei Worten besteht. Dann sollten Wert[0] und Wert[1] ungleich Null sein.

    Das Forcen ist nur eine Krücke. Eigentlich braucht man eine Mimik, die Start wieder auf TRUE setzt, wenn der Masterbaustein Start auf FALSE setzt. Bei serieller Kommunikation am besten mit einer kleinen Verzögerung. Dann läuft die Kommunikation kontinuierlich.

    Du könntest mal versuchen, eine Variable pTemperatur vom Typ POINTER_TO_REAL anzulegen. Dieser Variable weist du dann den Wert "ADR(Wert)". Im oberen Teil der Variablen sollte dann zur Laufzeit ein REAL-Wert sichtbar sein. Bin mir allerdings im Augenblick nicht ganz sicher, ob das so geht. Muss ich noch mal drüber nachdenken.

Ähnliche Themen

  1. Energiezähler über Modbus auslesen
    Von arkeq im Forum CODESYS und IEC61131
    Antworten: 5
    Letzter Beitrag: 16.01.2017, 09:01
  2. Antworten: 10
    Letzter Beitrag: 30.10.2012, 13:06
  3. WAGO-SPS und Modbus-Protokoll?
    Von Oxy im Forum Sonstige Steuerungen
    Antworten: 6
    Letzter Beitrag: 22.08.2011, 02:09
  4. Anbindung KBR-Multimess WAGO über Modbus
    Von fraggle-m im Forum CODESYS und IEC61131
    Antworten: 1
    Letzter Beitrag: 29.06.2011, 15:57
  5. Antworten: 0
    Letzter Beitrag: 05.08.2010, 08:14

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •