# Simatic 840D M-Funktionen



## morphyxx (22 September 2007)

Hallo zusammen,

Ich habe folgendes Problem mit M-Funktionen:

Mein NC-Programm reagiert nicht auf die M-Funktion wie es sein sollte. Normalerweise bleibt doch die NC in dem Satz stehen, in der ich die M-Funktion gesetzt habe und wartet bis die M-Funktion von der PLC quittiert wird. Erst dann erfolgt die Satzweiterschaltung.
Bei mir wird die M-Funktion erkannt => das Programm fährt jedoch normal weiter ohne dass es die M-Funktion beachtet.
Ich denk mir dass ich eventuell irgendein Maschinendatum nicht richtig konfiguriert habe (Allgemein- / Kanal-spezifisch). Das einzige Datum das ich kenne ist $MC 22200 (Ausgabe M-Funktion vor/während/nach Verfahrbewegung)

Gibt es da noch andere relevante Maschinendaten? Oder an was könnte es noch liegen.

Vielen Dank im Voraus.

Gruß Steffen


----------



## Znarf (22 September 2007)

Hallo 
Die M-Befehle bis M99 sind normalerweise dynamische M-Befehle und werden automatisch vom Grundprogramm quittiert. Sie sind deshalb nur für einen SPS-Zyklus auf True. Willst du M-Befehle haben die quittiert werden sollen, kannst du z.B. welche mit dem DB74 oder DB75 und einigen Maschinendaten erzeugen. Ich nutze dann die zwischen 100 und 131.
Auf der DoconCD (DoconWeb) sollte auch stehen welche MDs das sind.

Gruß

Andreas


----------



## morphyxx (22 September 2007)

Hallo Andreas,

Meine Bereich liegt auch zwischen M100-M131. Am PLC-Programm liegt es mit ziemlicher Sicherheit nicht, da es schon an sehr vielen Anlagen so läuft. Da ich jedoch dieses Mal meine NC von Grund auf neu anlegen musste, liegt es hoffentlich an einem vergessenen Maschinendatum.

Die M-Funktion wird ja auch in der NC erkannt, jedoch interessiert sie es nicht.
Ich schau mal in der DocOnCD nach.

Danke dir.

Gruß Steffen


----------



## Znarf (22 September 2007)

Hallo,
ich denke wenn du ein Standard PLC-Programm hast und das bei anderen geht, solltest du dir mal MD11100 und 

AUXFU_ASSIGN_TYPE,
AUXFU_ASSIGN_EXTENTION,​AUXFU_ASSIGN_VALUE
AUXFU_ASSIGN_GROUP
 ( denke die sind kanalspezifisch so ab 22000)

anschauen.

Diese sollten im Zusammenhang mit "M-Dekodierung nach Liste" stehen.
(handbuch grundfunktione plc-grundprogramm 840Dpl FB1) 

Sollte es noch Probleme geben, kann ich dir am Montag mehr sagen.

gruß

Andreas


----------



## morphyxx (23 September 2007)

Hallo,

bei deinen genannten Maschinendaten bin ich auch schon hängen gebleiben. Jedoch das komische ist, dass ich zwei Serieninbetriebnahme-Archive von einem alten und meinem jetzigen Projekt verglichen habe. Ist zumindest in den du mir genannten Bereich identisch bis auf eine Ausnahme:

Bei $MC22060[5] steht bei meinem alten Projekt eine "1" drin. Bei meinem neuen Projekt eine "0". Anonsten ist eigentlich alles gleich, bei den relavanten Maschinendaten für die M-Funktionen.

Sobald ich eine Anstehende M-Funktion in der PLC erkannt habe gebe ich ausserdem Kanalspezifisch ein "Read-In-Disable" heraus DB21(22).dbx6.1

Ich werd am Montag das oben genannte $22060[5] anpassen und hoffen...

Gruß Steffen


----------



## Znarf (24 September 2007)

Hallo,
MD22060 habe ich gar nicht verändert.
Nur 22000, 22010 und 22030 sowie 11100.
Den Rest macht die PLC.

Gruß

Andreas


----------



## Boxy (24 September 2007)

Bei der 840D musst Du selbst eine Einlesesperre programmieren wenn eine M-Funktion ansteht.

Die NC gibt die M-Funktion dynamisch aus und diese ist ein Zykluss "true" danach wieder "false". 
Möchtest Du das das Programm solange im Satz wartet bis die Funktion ausgeführt wurde, must DU wie geschrieben eine Einlesesperre setzen.
Diese Einlesesperre ist Kanal spezifisch! D.h. für jeden NC-Kanal eine eigene.

z.B. DB21 - DB30     DB21.DBX6.1  (A_RIdisable)


Gib mal an was für ein System Du fährst.
Also HMI-Advance und HMI-TL2000 oder nur reines HMI-Advance?
Oder schau einmal ob der FC10 in deinem Programm verwendung findet!
Hier ist es abhängig ob über DB2 oder DB126 die Meldungen usw. versorgt werden.


----------



## Znarf (24 September 2007)

@Boxy
Das gilt nur für die von dir beschriebenen dynamischen Befehlen. Bei den M-Befehlen über 100 und Dekodierung nach Liste ist das nicht der Fall.
Da stoppt das NC-Programm von alleine. Zumindestens war es bei uns immer so  

Gruß

Andreas


----------



## morphyxx (24 September 2007)

Hallo zusammen,

hab das Problem zum Glück behoben. Es war wirklich der FC10 (MSG-ALARM). Hab diesen FC das erste mal in meinem neuen Projekt verwendet. Der hat mir die Einlesesperre wieder zu "0" gebügelt. Bin aber nur durch Zufall darauf gekommen.
Der FC10 wurde bei mir im OB1 nach der M-Funktion aufgerufen. Das war das ganze Problem. Laut Siemens muss er eigentlich am Anfang aufgerufen werden. Nach FC2.
Bei mir ist es aber auch so, dass die Einlesesperre von der PLC aus gesetzt werden muss. NICHT von der NC heraus. Wüsste eigentlich gar nicht wie das gehen soll => Maschinendatum?!?

Ich finde es aber wirklich sehr ärgerlich das so ein FC10 so direkt in den Kanal einwirkt.

Aber bei der 840D bekommt oftmals der Begriff "Jugend forscht" eine ganz neue Bedeutung 

Danke für eure schnelle Hilfe.

Gruß Steffen


----------



## Znarf (24 September 2007)

Hier ein Auszug aus dem Handbuch für das Grundprogramm (FB1):


> M-Dekodierung nach Liste
> Funktionsbeschreibung
> Mit dem Aktivieren der Funktion M-Dekodierung nach Liste über den GP-Parameter des
> FB 1 "ListMDecGrp" (Anzahl M-Gruppen zur Dekodierung) können bis zu 256 M-Funktionen
> ...


 
D.h., dass das Grundprogramm das setzen der Einlesesperre selbst übernimmt. Und so funktioniert das auch bei uns. 

Aber doppelt gemoppelt hält bestimmt besser  

Gruß​ 
Andreas​


----------



## Boxy (25 September 2007)

> Die Zuordnung von M-Funktion mit erweiterter Adresse und zu setzendem Bit in der Signalliste wird in der Dekodierliste festgelegt.


 
Also wir sollten erstmal zwischen normalen und erweiterten M-Funktionen unterscheiden.

Normale M-Funktion:     
Sind M-Funktionen wie M7, M8, M9  usw.

Erweiterte M-Funtkionen:
Sind M-Funktionen wie M3=2 oder M7=2 usw.
(Wobei M3=x/M4=x wiederum ein Sonderfall ist)

Bei den normalen werde diese im Kanal-DB ab DBX194.0 (99 Stück) als dynamische ausgegeben. Die Erweiterten werden am FB1 (ListMDecGrp)Parametriert welche und wieviele ausgegeben bzw. decodiert werden sollen. Diese kommen dann im DB76 raus. Hier warte die NC bis das Bit quittiert wurde (Einlesesperre). Die Decodierliste steht im DB75. Dann gibt es noch die Erweiterten M-Funktionsadressen (DInt) welche ebenfalls in Kanal DB raus kommen (Kanal DB DBB68 - DBB97).




> Aber doppelt gemoppelt hält bestimmt besser


 
Das ist ser schlecht bei der 840D. 
Entweder man verwaltet kpl. die Einlesesperen selber oder man nutzt den FC10. Beides ist eigentlich sehr schlecht, da FC10 meist am Ende des PLC-Programms aufgerufen wird und die Kanalnahtstelle beschreibt und somit Händisch programmierte Sperren (Vorschub, Einlese usw.) überschreibt!

Somit sollte dann alles über den DB2 gefahren werden. Dieser wird vom FC10 ausgewertet und die entsprechenden Signale gesetzt (Sperren, Alarme und Meldungen).

Es gibt z.B. einige Funktionen die durch DIN gegeben sind. Somit ist es erstmal einfach bzw. notwendig die normalen M-Funktionen zu nutzen und für Sonderanwendungen auf die Erweiterten zurück zu greifen.

Sicherlcih gibt es Fälle bei denen auf die Erweiterten M-Funktionen (>100) ausgewichen werden muss.


----------

