Profinet-Kommunikation zu Teilnehmer

Zuviel Werbung?
-> Hier kostenlos registrieren
Hat sie geschrieben : ein Trumpf-Laser ... (den kenne ich aber nicht).

@Suzi: Kann das Ding denn wirklich PN ... oder geschieht die Kommunikation eigentlich mit einem ANYBus-Modul, dass dann wieder seriell mit dem Laser "spricht" ?
Vielleicht solltest du mal einen Screenshot von der HW-Konfig eines deiner Laser hier einfügen ...
Lt GSDML: Hilscher CIFX 2.2

HW_Konfig.png
 
Zuletzt bearbeitet:
Nachsatz:
Wenn der Hersteller (also Trumpf) dir aber schreibt, dass er das mit der Kommunikation selber nicht so recht weiß dann ist das schon ein Armuts-Zeugnis ...
Ich denke da ist die serielle Kommunikation und Profibus-Kommunikation noch zu sehr verbreitet. Und sicherlich hängt es mit dem Mitarbeiter zusammen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

ok dann ist schonmal klar das dieses PN Interface nicht von Trumpf ist sondern ne Hilscherkarte die im Laser verbaut ist.
Wenn es ein Integrationsbeispiel für Profibus gibt dann kann dieses ja für PROFINET verwendet werden, die Bausteine sind da ja gleich.

Leider hat Trumpf nicht wirklich einen Service Bereich im internet :(
 
Hilscher ist nur ein "Übersetzer".
Die dinger benutzen wir immer in unseren PCs zur Kommunikation mit der SPS.
Wenn Du mich fragst, dann musst Du die GSD Datei der Hilscher Karte in die HW-Konfig eintragen und beim Hersteller gucken, welche Parameter er auf welchen Adressen er erwartet.
Eine Kontrollierte Kommunikation ist bei Profinet meiner Meinung nach absolut nicht notwendig.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine Kontrollierte Kommunikation ist bei Profinet meiner Meinung nach absolut nicht notwendig.
Dem würde ich so zustimmen ... :)
Wenn Du mich fragst, dann musst Du die GSD Datei der Hilscher Karte in die HW-Konfig eintragen und beim Hersteller gucken, welche Parameter er auf welchen Adressen er erwartet.
Das müßte aber auf alle Fälle aus der GSD-Datei (HW-Konfig) hervorgehen.
Man MUSS sich hier aber sehr wahrscheinlich an eine Reihenfolge in der Zuweisung von bestimmten Daten/Werten auf bestimmte Koppelbereiche halte - so gesehen dann doch wieder eine Art Kommunikation. Als Basis sollte hier aber dann auch wieder die schon bekannte serielle Kommunikation helfen können. Über die Hilscher-Karte wird es nicht soviel anders laufen. Also auf alle Fälle mal ein bißchen Richtung "Schrittkette" beim Datenaustausch denken.

Gruß
Larry
 
Man MUSS sich hier aber sehr wahrscheinlich an eine Reihenfolge in der Zuweisung von bestimmten Daten/Werten auf bestimmte Koppelbereiche halte - so gesehen dann doch wieder eine Art Kommunikation. Als Basis sollte hier aber dann auch wieder die schon bekannte serielle Kommunikation helfen können. Über die Hilscher-Karte wird es nicht soviel anders laufen. Also auf alle Fälle mal ein bißchen Richtung "Schrittkette" beim Datenaustausch denken.


Hallo Larry, hallo Christoph,

ich denke dass ist einfach der Weg....
Danke Suzi
 
Das müßte aber auf alle Fälle aus der GSD-Datei (HW-Konfig) hervorgehen.

Jein. Die Hilscher Karten sind da ein bisschen wie ne ET200 Kopfbaugruppe. Oder ein DP/DP Koppler.
Da kann man als Unterbaugruppe noch Eingangs und Ausgangsdaten hinzufügen.


Es muss auf jeden Fall irgendjemanden geben, der im Inneren des Lasers die Kommunikation zur Hilscher Karte kreiert hat. Und daran muss man sich auf der anderen Seite der Karte auch dran halten.
Lange rede kurzer Sinn: Ich würde keine SFC/SFB Veranstaltungen machen sondern einfach die Daten, die Du hast auf entsprechende AW / PAW schreiben und fertig. Musst halt nur wissen welche Daten an welche Adressen kommen.
 
Ich habe noch nicht damit gearbeitet - also doch in etwa so, wie ein ANYBus-Modul ?

Nicht ganz.
Ist im Prinzip ne PC Einschubkarte die für das Feldbus System verwendet wird.
Über eine API kannst du dann ein eigenes Programm schreiben welches eben die Daten von der Karte weiterverarbeitet.

Ähnlich wie bei KUKA Robotern, dort wurden Siemens CP's dafür eingesetzt (CP5614 / CP1616).

Gruß
Christoph
 
@Suzi:
Ich habe jetzt gerade den von dir nachgeschobenen Screenshot gesehen. Das ist natürlich auch wieder dürftig. Ich hatte jetzt schon erwartet, dass den "4 Byte Ausgang" eine brauchbare namentliche Zuordnung gemacht wurde. Im Grunde sind das ja die Koppelbereiche, die ggf. festgelegte Funktionen haben (z.B. Kommando's , Beschriftungstext etc.)

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist es nicht so, dass der SFC 20 sich unter umständen mehrere Zyklen Zeit läßt?
Nein, der SFC20 wird immer sofort fertig (es sei denn, er verursacht eine Zykluszeitüberschreitung).
(Allerdings kann der SFC20 durch höherpriore OB unterbrochen werden, was aber nur eine Relevanz hat, wenn man in verschiedenen OB-Ebenen auf die SFC20-Quell/Zielbereiche zugreift.)

Daher habe ich die SFC 14/15 für die 64 Byte E/A gedacht wegen der Datenkonsistenz.
Die SFC14/15 kann man nur einsetzen, wenn für das Zugreifen auf die E/A-Adressen eine Konsistenz ungleich 1, 2 oder 4 Byte projektiert ist und wenn die E/A-Adressen außerhalb des E/A-Prozessabbildes liegen. Wenn die E/A-Adressen innerhalb des Prozessabbildes liegen, dann kümmert sich das Betriebssystem der CPU um das konsistente Kopieren zwischen Prozessabbild und Peripherie und die Daten liegen konsistent im Prozessabbild, so daß man einfach mit L/T auf's Prozessabbild zugreifen kann.

Harald
 
Ich hatte jetzt schon erwartet, dass den "4 Byte Ausgang" eine brauchbare namentliche Zuordnung gemacht wurde. Im Grunde sind das ja die Koppelbereiche, die ggf. festgelegte Funktionen haben (z.B. Kommando's , Beschriftungstext etc.)

Die Definition der einzelnen Bits der Ausgangsbytes gibt es im Handbuch zur Installation der Schnittstellenkarte und auch in der Zuordnungsliste. Im Groben: LASER-AblaufSteuerung/Digitale Schnittstelle
für die 64 Bytes Empfangs- / Sendepuffer Kommandos
Für die Kommandos zur Steuerung des Lasers, sowie der Rückmeldungen gibt es ein eigenes Handbuch.
Im Prinzip ist ja auch fast alles vorhanden.
 
Zuletzt bearbeitet:
Zurück
Oben