Step 7 Zickiger CP-342-5

[Aksels]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag,
ich versuche hier einen Hach-Lange SC-1000 über Profibus mit einem 342-5DA02-0XE0 / 5.0 auszulesen.
Kommunikation klappt, aber im DB kommen nur Nullen an.
Ich vermute folgendes Problem:
Ich habe den Hach Lange bei Adresse 700 starten lassen. Er stellt 88 Byte zur Verfügung (bis Adresse 787).
Zum Auslesen den 342-5 braucht man ja den DP-Receive FC2.
Diesem Baustein kann man aber nicht sagen, ab welcher Adresse er lesen soll. Er liest ab 0. Wenn ich ihm einen Baustein als Ziel mit Byte 88 füttere, dann liest er vermutlich 0-87 anstatt 700-787.
Deswegen bekomme ich nur 0en, weil bei 0-87 kein Slave was anbietet.
Meine Lösung wäre den Hach Lange Slave auf 0-87 umzustellen. Aber ich habe Eingangskarten ab EB12.
Nun die Frage, bevor ich das einspiele und nichts mehr funktioniert (Anlage ist heikel, darf nicht zu lange in stop sein):
Sind die Adressen im Profibus hinter dem CP-342-5 unabhängig von den Eingangskarten an der SPS?
Also anders als bei einem Profibus direkt an der CPU?

Gruß,
Aksels

 

[Thomas_v2.1]

Ja, so ist das beim Profibus CP, du kannst auf die Daten ja auch nicht über das Prozessabbild zugreifen, sondern bei dir über den Zielbereich im DB85.
Bei Profinet CPs an einer 300er ist das ähnlich.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die E/A-Adressbereiche im CP342-5 und in der CPU sind unabhängig voneinander. Siehe HW Konfig: Ansicht > Adressübersicht... Ctrl+U (oder das dritte Icon von rechts)
Am CP342-5 projektiert man E/A-Adressen am besten von 0 an. DP_SEND/DP_RECV kopieren immer den gesamten CP-E/A-Bereich ab E/A-Adresse 0 bis zur im ANY angegebenen Bereichslänge zum/aus dem CP.

Harald

 

[Aksels]

Guten Morgen.
Habe die Adressen ab 0 umgestellt. Nun habe ich eine Änderung im DB5. Dieses Problem ist also behoben. Leider habe ich noch nicht die gewünschten Daten (siehe Datenauszug unten). Der erste Integer heisst im Hach Lange SEK PULS. Bewegt sich aber nichts, wenn ich DB5 beobachte. Da nützt wohl auch die Datenvertauschung nichts, wenn das Ding mir nur FFF...sendet....
Irgendwelche Ideen?

DB_Status_1_1 INT 0 16
DB_Status_1_2 INT 0 5
DB_Status_1_3 INT 0 16800
DB_Status_1_4 INT 0 0
DB_Status_1_5 INT 0 0
DB_Status_1_6 INT 0 0
DB_Status_1_7 INT 0 -1
DV_Float_1_1 REAL 0.000000e+000 DW#16#FFFFFFFF
DV_Float_1_2 REAL 0.000000e+000 DW#16#FFFFFFFF
DB_Status_2_1 INT 0 -1
DB_Status_2_2 INT 0 -1
DB_Status_2_3 INT 0 -1
DB_Status_2_4 INT 0 -1
DB_Status_2_5 INT 0 -1
DB_Status_2_6 INT 0 -1
DB_Status_2_7 INT 0 -1
DV_Float_2_1 REAL 0.000000e+000 DW#16#FFFFFFFF
DV_Float_2_2 REAL 0.000000e+000 DW#16#FFFFFFFF

 

[PN/DP]

Kopiert der FC2 DP_RECV überhaupt Daten in den DB5?
Werden die Bytes im DB5 überschrieben, wenn Du da Werte manuell änderst?
Stimmt die DP_RECV.CPLADDR W#16#130? Auf welche E-Adresse hast Du den CP342-5 projektiert? W#16#130 = 304 dezimal

Ist die HW Konfig mit dem CP342-5 in die Station geladen? In die CPU und in den CP342-5 (oder in Optionen aktivieren "[x] Projektierungsdaten in der CPU speichern")
Ist der CP342-5 in RUN?
Hast Du mal die Spezialdiagnose des CP342-5 durchgesehen, ist Dein Hach-Gerät da zu sehen ? CP342-5 > Eigenschaften > Reiter: Diagnose > Start der Spezialdiagnose: Ausführen

Warum rufst Du DP_RECV nur alle 1 Sekunden auf? DP_SEND + DP_RECV ruft man üblicherweise in jedem OB1-Zyklus auf (entsprechend dem Prozessabbild OB1-PA).

16#FFFFFFFF ist kein gültiger REAL/Float-Wert (NaN), kommen diese Werte wirklich von dem Hach-Gerät?

Harald

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde mit die Float-Werte zuerst mal als Einzelbytes ablegen und später ansehen, wie man die zu Reals zusammenbauen kann. Entweder sind Byte vertauscht oder die benutzen im schlimmsten Fall ein Float-Datenformat das die SPS so nicht lesen kann.

 

[PN/DP]

Solange die Einzelbytes der Float-Werte alle FF sind, kann man schlecht sehen, ob da was vertauscht ist...

Harald

 

[hubert]

Hallo,
soweit ich das noch im Kopf habe, kann man bei Hach-Lange auswählen, ob man Motorola oder Intel-Format hat. Hier bekommt man auf jedenfalls evlt. das Problem mit dem FF, da die CPU den Datentyp REAL nicht sauber erkennen kann und deshalb hier als Fehler FF einträgt.
Ich würde wie meine Vorredner schon die "EN" am RECV-Baustein unbeschaltet lassen und so den FC in jedem Zyklus aufrufen.
Wenn du eine EA-Adressen für das Hach-Lange auf die 700er Adresssen legt, muss du einen DB mit mindesten 788 Byte erstellen.
Dabei sind die ersten 700 Byte leer. Wäre auf jedenfalls verschwendung.

Kann mal schauen, ob ich noch etwas Doku habe, wie ich das damals alles eingestellt habe.

Gruß

 

[Aksels]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen alle zusammen,
der Haken bei Projektierungsdaten in der CPU speichern ist drin.
Adresse des CP ist 304 was W#16#130 entspricht, richtig?
CPU ist eingespielt. Habe ich sehr sorgfältig gemacht (Anlage muss aufwändig heruntergefahren werden).
Werte in DB5 werden überschrieben.
Die 1 Hz habe ich nur reingemacht, um den Baustein leichter beobachten zu können. Wurde von mir wieder entfernt.
Der Baustein wechselt immer wie ich das erwarte von NDR false, Status 16#8180 DBStatus 0 zu NDR True Status 0 DBStatus 0.

 

[Aksels]

HAbe den DB5 auf Byte umgestellt. Dann sieht es so aus:

 

[PN/DP]

Moin,
und was ist jetzt noch Dein Problem?
Hast Du Dir auch die in Beitrag #5 empfohlene "Spezialdiagnose" des CP angeschaut? (siehe in Deinem zweiten Bild "Eigenschaften CP..." der letzte Reiter "Diagnose")
Wenn DP_RECV in jedem Zyklus aufgerufen wird, dann ist konstant NDR=1 und STATUS=16#0.

Harald

 

[Aksels]

Zuviel Werbung?
-> Hier kostenlos registrieren

Konstant nicht. Es wechselt immer zwischen NDR false Status 16#8180 und NDR true und Status 16#0.
Mein Problem ist, dass die Daten kaputt sind, nichts mit dem zu tun haben, was im SC-1000 konfiguriert ist.
Und wenn nur FF ankommt kann es auch nicht vertauscht sein. FFFF vertauscht bleibt FFFF.
Ich habe bereits Hach Lange kontaktiert. Habe keine Idee mehr dazu ausser, dass man mit diesem CD kein SC1000 auslesen kann, da inkompatibel.
Die Diagnose sieht so aus:

Gruß,
Axel

 

[PN/DP]

Deine GSD-Datei ist Version R3.0 von 2013?
Deine FC DP_RECV und DP_SEND sind beide Version 3.0 aus der Familie CP_300?

Im DB5 die Bytes DBB4..7: 16#41A00000 = 20.0

Harald

 

[Aksels]

Ich rufe nur den CP_RECV auf, da keine Daten zu HL gesendet werden.
Dieser ist CP-300 V 3.0
Log-Auszug:

GSD-Installation
----------------

Beginn: 25.11.2020 11:19:23
Quellverzeichnis: D:\Downloads\asset-get.download2\GSD _SC1000_New_Dec2013
Zielrechner: TERRA-AS
Benutzer: as

Datei: HALA09AC.GSD
Status: Installiert. Ursprüngliche Datei wurde nach 'C:\PROGRAM FILES (X86)\SIEMENS\STEP7\S7DATA\GSD\BACKUP_20201125_001' verschoben.

Datei: HALA09AC.bmp
Status: Installiert. Ursprüngliche Datei wurde nach 'C:\PROGRAM FILES (X86)\SIEMENS\STEP7\S7DATA\GSD\BACKUP_20201125_001' verschoben.

Wie mir gerade wieder auffällt habe ich allerdings zwei Hardware-Bausteine zur Auswahl im Katalog:

Welcher wohl der richtige ist? Wie bekomme ich das raus?
Dieser ist im Moment im Projekt:

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie mir gerade wieder auffällt habe ich allerdings zwei Hardware-Bausteine zur Auswahl im Katalog:
Anhang anzeigen 51962
Welcher wohl der richtige ist? Wie bekomme ich das raus?

Du hast den "SC-Family" projektiert. Das ist die GSD-Datei HALA09AC.GSD von 2013 für DP Ident Number 0x09AC.
Dann gibt es noch den "SC-Controller". Das dürfte die GSD-Datei LANG0671.GSD von 2006 für DP Ident Number 0x0671 sein.

Wenn Du Deinen SC-1000 mit der falschen GSD-Datei projektiert hast, dann würde der CP342-5 einen fehlenden DP-Slave melden/durchgestrichen markieren. Es sei denn, der SC-1000 reagiert auf beide DP Ident Nummern - sowas habe ich aber noch nicht erlebt.

Im Zweifelsfall: einfach ausprobieren. Projektiere 2 DP-Slaves, einen mit der einen GSD- und einen mit der anderen GSD-Datei. Auf 2 verschiedene Profibus-Adressen. Dann gib Deinem SC-1000 die eine DP-Adresse und schau ob der CP342-5 den DP-Slave als vorhanden oder fehlend markiert. Dann gib Deinem SC-1000 die andere DP-Adresse und schau wieder. Hinweis: Nach Ändern der DP-Adresse muß man normalerweise den DP-Teilnehmer spannungslos machen (ausschalten und wieder einschalten). Oder ändere nicht die DP-Adresse des SC-1000 sondern die DP-Adresse in HW Konfig. Hinweis: die Profibus DP Ident Nummer wird in der NCM S7 Diagnose als "Hersteller-Id (hex)" angezeigt. Alle vom CP342-5 am Profibus gefundenen Teilnehmer bzw. deren DP-Adressen kann man unter "PROFIBUS > Teilnehmer" sehen.

Harald

 

[Aksels]

Guten Morgen.
Habe das Problem gelöst. Es war natürlich wieder etwas ganz doofes. habe die Support-Tipps von HL umgesetzt, aber kein Erfolg. Dann bin ich nochmal alles durchgegangen. Die HW-Projektierung in Step7, das Programm, den DB, und alle Menüpunkte des SC-1000.
Dabei bin ich über die Simulation gestolpert. Beim ersten Termin dort habe ich dem Elektriker zugerufen, er soll mal bitte die Simulation einschalten, ob sich im DB was ändert. Er rief noch zurück: "Für zwei Minuten aktiv." Hat aber nichts bewirkt (damals hatten wir vermutlich noch die falsche GSD-Datei). In der Simulation stehen folgende Parameter:

Als ich heute morgen dort hineinschaute war Simulation Ja, Dauer 2min, Service deaktiviert.
Ich dachte noch: "2 Minuten, es sind ja Tage vergangen, die Simulation sollte also aus sein. Was wohl Service heisst?" Habe dann Service Aktiviert gesetzt, um zu schauen, ob sich im DB5 überhaupt was ändert. Hat es nicht. Aber ich bin misstrauisch geworden. Was, wenn die 2 Minuten nicht funktionieren, oder was ganz anderes bedeuten als ich annehme? Ich schaltete dann Service auf deaktiviert und Simulation auf false und siehe da! Werte im DB. Genau so wie sie angelegt waren.
Da kommt man sich immer so ausgetrickst vor. Warum stoppt die Simulation nicht nach den angegebenen 2 Minuten? Das ist ja fatal, wenn man dort nochmal hinfahren muss, wenn man vergisst die Simu auszuschalten. Vor allem, wenn da noch groß Dauer 2 Minuten steht.....
Man braucht übrigens keine Bytevertauschung. Zumindest bei diesem Projekt.
Vielen Dank für die Tipps.

Gruß,
Aksels

 

[DeltaMikeAir]

Der Zeitwert hat eine andere Funktion als du sie annimmst:
( nicht Dauer der Simulation sondern Zeitwert Rampe Wert von min auf max und zurück )