Kommunikation zwischen RevPi und Siemens S7 mit dem Profinet IRT Gateway im TIA-Portal

[volker]

Du hast im TIA ja auch 16 bit WORD auf 256 liegen. Da solltest Du immer zur Sicherheit auch das zweite Byte mit ausgaben, denn ich weiß nicht, wie ProfiNet das anordnet (Big oder Little Endian). Also bitte gebe mal Input_2 aus oder gleich piTest -r 0,2 um beide bytes zu sehen.

[RevPiModIO]

Hi Peter!

Du kannst alternativ mal auf die Webseite von dem Profinet Gateway schauen, ob da die Daten zu sehen sind! Die IP für das Teil müsste TIA ihm gegeben haben. Bei uns ist das 192.168.10.98

http://192.168.10.98

Dort loggt man sich ein mit den Daten:
User: Admin (das A groß)
Pass: 1701

Und hat dann die Übersicht zum Modul um zu prüfen ob da überhaupt etwas ankommt von TIA...

Screenshot_20170303_164815.png (39.51 KiB) Viewed 8607 times

am RevPi sonst auch mal /opt/KUNBUS/piControlReset verwenden... Wir haben es schon oft gehabt, dass er nicht richtig initialisiert ist...
piTest -d
zeigt auch an ob alles richtig ist...

Gruß, Sven

[Peter]

Vielen Dank nochmals für die Hilfestellungen. Leider habe ich es immer noch nicht geschafft, eine Kommunikation herzustellen.
Es hat nichts geholfen wie von volker vorgeschlagen, mit piTest -r 0,2 auch Input_2 mit auszugeben. In meinem letzten Post kann man in der Beobachtungstabelle sehen, dass bei %AW256 der Wert 16#FFFF drin steht. Dennoch kamen auf der Kommandozeile des Pi lediglich nur Nullen an.

Es hat auch nicht geklappt, auf die Seite des Profinet Gateways zugreifen, die miprotek gepostet hat.
Ich habe es unter anderem unter der 192.168.0.9 versucht, weil ich diese im TIA-Portal ausgelesen habe:

IP_Adresse.PNG (95.7 KiB) Viewed 8586 times

Die Seite konnte nicht gefunden werden.

Zeitüberschreitung.JPG (76.15 KiB) Viewed 8586 times

Heute habe ich viel an der Netzwerkkonfiguration rumgespielt. Dabei ist mir aufgefallen, dass der Profinet Gateway beim erweiterten Laden ins Gerät gar nicht gefunden wird.
Ich weiß nicht, ob er dort überhaupt auftauchen sollte, aber es kommt mir komisch vor.

Erweitertes Laden.JPG (82.92 KiB) Viewed 8586 times

Ich ziehe in Betracht, dass das Gerät defekt sein könnte. Ich werde es morgen mal austauschen.

[volker]

Hallo Peter,
also beim erweiterten laden ins gerät wirst Du nichts finden können, denn da sind nur geräte aufgelistet, in die man mit TIA auch Programme laden kann. Des ist in der Regel Deine PLC aber nicht ein Slave, wie das Gateway.
Ein Grund dafür, dass Du keine verbindung bekomms, könnte sein, dass Du dem gateway noch keinen Namne zugewiesen hast. Unser Profinet Experte sagte mir eben zwischen Tür und Angel, dass dies Voraussetzung für einen Kontakt mit dem Gerät sei. Normalerweise siehst Du links einen gerätebaum in TIA, bei dme auch Dien Gateway aufgelistet ist. Wenn Du dort in Online & Diagnose gehst, sollte sich eine Maske öffnen, in welcher ein Gerätename vergeben werden kann. Dieser ist per Default leer und in diesem Zustand erreichst du das Gerät nicht.
Wenn Du erst wenig bis keine Erfahrung mit TIA und Profinet haben solltest, dann wäre es sicher gut, wenn dir jemand vor Ort mit TIA und profinet-Erfahrung mal helfen könnte. Wir haben aktuell keinen Testaufbau im Betrieb, bei dem wir genau die Schritte aufzeigen könnten, wie man einen Profnet Slave in TIA erfolgreich einbindet. Vor der Messe in Nürnberg kommen wir sicher auch nicht dazu, das noch zu machen...

[Peter]

Ich habe gestern nochmals den ganzen Tag versucht, irgendeine Form der Kommunikation herzustellen. Das Profinet IRT Gateway wurde ausgetauscht und es wurde ebenfalls ein neuer RevPi Core verwendet. Ich kann mittlerweile bei Eingabe der IP-Adresse des Gateway wie von miprotek vorgeschlagen (User: Admin und dem Passwort: 1701) auf die Seite des Gateway zugreifen. Dort kann ich nachvollziehen was passiert, wenn ich mit piTest -w Werte verändere. Im TIA-Portal wiederum kommt nichts davon an. Umgekehrt natürlich auch nicht. Auch TIA-erfahrene Leute, bei welchen ich Unterstützung gesucht habe, konnten das Problem nicht identifizieren. Entweder es handelt sich um eine Kleinigkeit, die wir übersehen haben. Oder es handelt sich um einen schweren Bug. Ohne weitere Hilfestellung komme ich hier nicht weiter. Ich verstehe, dass es so kurz vor der Embedded World ein denkbar schlechter Zeitpunkt ist. Vielleicht könnte ich mal mit dem TIA-Experten bei Euch telefonieren?

[volker]

Hi Peter,
lies bitte mal Deine Private Mail im Forum...

[Ingo]

Hi,

kann es sein das du unter PI Controll vergessen hast die hacken hinter den E/A zu setzen? da du ja mit einer anderen Software die Daten verabeiten willst ist dies dann zwingend erforderlich. mit Python ist das egal.
Aber dritt software braucht diese hacken.
Ich hatte das Problem auch unter LogiCad das ich dort keine werte erhalten habe obwohl sie mit PiTest -w variable,wert (zahl) gesezt wurden.

Ist nur eine Vermutung meinerseits.

gruß

[volker]

Danke Ingo für die Information, aber das gilt echt nur für logi.RTS. Außer eine Software nutzt den IOCTL, den wir für logi.RTS bereithalten. Aber die Gateways und vor alem ja unser PiControl brauchen diesen Export-Haken nicht. Sie richten sich nach der JSON-Datei, die PiCtory erzeugt.

[atstaeff]

Hallo Volker,
ich habe ein ähnliches Problem im Moment.
Nach dem das Profinet Gateway erfolgreich im TAI Portal angemeldet worden ist, bekomme ich aber noch keine Werte zugeteilt.
Ich habe die TAI Übersicht und meine Profinet Daten angegeben.
Irgendwo ist noch der Wurm drin.



PICTORY EXPORT:
GLOBALS hardwareConfig
VAR_GLOBAL

RevPiStatus AT %IB1.0: BYTE := 0; //
RevPiIOCycle AT %IB1.1: BYTE := 0; //
RevPiLED AT %QB1.6: BYTE := 0; //
Input_1 AT %IB1.11: BYTE := 0; //
Input_2 AT %IB1.12: BYTE := 0; //
Input_3 AT %IB1.13: BYTE := 0; //
Input_4 AT %IB1.14: BYTE := 0; //
Input_5 AT %IB1.15: BYTE := 0; //
Input_6 AT %IB1.16: BYTE := 0; //
Input_7 AT %IB1.17: BYTE := 0; //
Input_8 AT %IB1.18: BYTE := 0; //
Input_9 AT %IB1.19: BYTE := 0; //
Input_10 AT %IB1.20: BYTE := 0; //
Input_11 AT %IB1.21: BYTE := 0; //
Input_12 AT %IB1.22: BYTE := 0; //
Input_13 AT %IB1.23: BYTE := 0; //
Input_14 AT %IB1.24: BYTE := 0; //
Input_15 AT %IB1.25: BYTE := 0; //
Input_16 AT %IB1.26: BYTE := 0; //
Input_17 AT %IB1.27: BYTE := 0; //
Input_18 AT %IB1.28: BYTE := 0; //
Input_19 AT %IB1.29: BYTE := 0; //
Input_20 AT %IB1.30: BYTE := 0; //
Output_1 AT %QB1.523: BYTE := 0; //
Output_2 AT %QB1.524: BYTE := 0; //
Output_3 AT %QB1.525: BYTE := 0; //
Output_4 AT %QB1.526: BYTE := 0; //
Output_5 AT %QB1.527: BYTE := 0; //
Output_6 AT %QB1.528: BYTE := 0; //
Output_7 AT %QB1.529: BYTE := 0; //
Output_8 AT %QB1.530: BYTE := 0; //
Output_9 AT %QB1.531: BYTE := 0; //
Output_10 AT %QB1.532: BYTE := 0; //
Output_11 AT %QB1.533: BYTE := 0; //
Output_12 AT %QB1.534: BYTE := 0; //
Output_13 AT %QB1.535: BYTE := 0; //
Output_14 AT %QB1.536: BYTE := 0; //
Output_15 AT %QB1.537: BYTE := 0; //
Output_16 AT %QB1.538: BYTE := 0; //
Output_17 AT %QB1.539: BYTE := 0; //
Output_18 AT %QB1.540: BYTE := 0; //
Output_19 AT %QB1.541: BYTE := 0; //
Output_20 AT %QB1.542: BYTE := 0; //

END_VAR
END_GLOBALS

[volker]

Ich versuche das mit usneren Siemens-Kenern noch näher zu analysieren. Aber kannst Du mir bitte noch sagen, wie Du denn festgestellt hast, dass Du keine Werte bekommst? Was genau hast Du gemacht, um zu testen, ob Werte im RevPi ankommen?
Außerdem fällt mir auf, dass Dein Funktionsblock die Werte ja ein INputs vom Profinet Slave schreibt. Das müssen eigentlich outputs sein! Die Outputs werden dann in die Inputs vom RevPi übergeben. Könnte es sein, dass dort Dein logischer Fehler liegt? Aus der Sicht der jeweiligen SPS ist ein Input ein ankommender Wert und ein Outout ein ausgehender Wert. Das ist beim RevPi so und natürlich auch bei der S7. Daher: Für die S7 sind das outputs und für den RevPi sind es inputs.