Komplizierte Frage zu BLKMOV oder wie oft darf ich den pro Zyklus aufrufen

[Krumnix]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo....

Ich hab hier ein Phänomen, das ich irgendwie nicht mir erklären kann.
Kurze Info:

Anlage hat 19 Stationen. In jeder Station soll ein Arbeitsschritt jeweils zum Typ abgearbietet werden. Der Typ wird in der 1. Station festgelegt.
Jeder Typ hat aber nochmal 2-3 Untertypen.

Damit ich in jeder Station weiß, was ich machen muss, hab ich mir einen UDT erstellt, der alle Informationen beinhaltet und ihn in einem DB 19 mal programmiert.

Nun kann ich ja in dem DB von UDT 1 sozusagen (also Speicherplatz der 1. Station mit den Informationen von allen Stationen, was in welcher gemacht wird) nach UDT 2 (2. Station) schieben.
Sagen wir UDT 1 im DB fängt bei P#DB20.DBX0.0 Byte 76 an und UDT 2 bei P#DB20.DBX80.0 Byte 76 (1 DW reserve).

Damit ich beim transverieren der Daten zwischen den Stationen keinen Verlust habe, habe ich eine exakte Kopie des DBs in einen Transport-DB kopiert. Die Struktur ist somit die gleiche.

Also beim Starten vom Transfer Station 1 zu 2 wird erstmal von DB20(Bearbeitungs-DB) in DB25(Transfer-DB) kopiert. Ist das Teil bei ST2 abgekommen, wird von DB25 wieder in DB20 kopiert, aber eine Station weiter.

Soviel erstmal dazu

Jetzt kommen wir zu dem Problem.

Frage Nummer 1:
Wir oft kann ich den SFC20 in EINEM SPS-Zyklus aufrufen?
Der Schiebe-FC beinhaltet imo 180 Mal diesen SFC.

Frage/Problem Nummer 2:
Manchmal verliert das System die Daten von der vorherigen Station, dh. das nach dem Transfer die Station keine Daten hat, was sie nun machen soll, weil die DB an der Stelle leer ist. Somit hat der BLKMOV nicht funktioniert, aber die Ansteuerung war def. ok. (hab ich 10 Mal schon überprüft )
Gibt es ein Phänomen, das der BLKMOV 20 Mal sauber arbeitet und dann auf einmal nicht mehr?!

Letzte Frage:
Da ich ja nur einen DB für alle Stationen habe und einen DB für alle Transferdaten, stellt sich mir die Frage, ob das Möglich ist?!
Ein Überlappen der Daten ist 100% ausgeschlossen, aber kann ich pro Zyklus mit sagen wir mal 15 BLKMOV-Aufrufen alle auf den selben DB zugreifen, oder gib es da Einschränkungen?

Ich sage schonmal vielen Dank, wenn da jemand eine Idee hat

Gruß

 

[Ralle]

Ich kenne keine Einschränkungen. Der BLKMOV kopiert die Daten in einem Zyklus um. Die Zykluszeit der SPS kann natürlich enorm ansteigen, bei schnellen SPS (VIPA Speed7, oder S7-319) hab ich damit allerdings noch nie Probleme gehabt. Die Speed7 braucht bei ihrem BLKMOV rel. viel lokalen Stackspeicher. Bei einem Baustein, der damit arg an der Grenze war hatte ich schon einmal sehr eigenartige Ergebnisse, allerdings kann man in der Hardwarekonfig der entsprechenden Ebene mehr lokalen Speicher zuteilen und schon geht es. (Retval beachten!) Für den leeren Speicher vermute ich eher, daß du 2 oder mehrere Male z.Bsp. aus dem Transport-DB in den Bearbeitungs-DB kopierst. Beim ersten regulären Mal die Daten, beim 2. Mal, dann natürlich lauter Nullen, da du die Daten aus dem Transport-DB ja sicher gelöscht hast. Nur eine Vermutung, aber prüf mal, wann genau du die Daten umkopierst.

Wenn du Probleme mit der Zykluszeit bekommst, würde es noch einen gänzlich anderen Weg geben. Du richtest für die Bearbeitung feste Fächer ein und gibst an die Stationen nicht die kompletten Daten, sondern nur einen Zeiger in Form einer Int weiter. Die Int ist 15, also greift die Station nun auch Fach 15 zu und verwendet diese Daten. Zum Zugriff auf die Daten kann man sich wiederum Funktionen zum Schreiben und Lesen bauen, die dann mit Hilfe dieses Zeigers, die benötigten Daten manipulieren.

 

[Krumnix]

Zuviel Werbung?
-> Hier kostenlos registrieren

CPU ist eine 319. Zykluszeit liegt also imo bei 12ms als Max.
Das Kopieren wird mit Flanken, die einen zuvor gespeicherte Situation (starten des Transport) festhalten und erst rückgesetzt werden, wenn der Transport fertig ist. Der Flankenmerker wird auch nirgends ein 2. Mal verwendet.
Das Problem taucht auch nicht immer bei der gleichen Station auf. Mal bei der 3->4, mal bei 8->9 z.b.

Ich kann mich daran mal erinnern, das ich irgendwo gelesen habe, das ein DB pro Zyklus nur eine bestimmte Anzahl Aufrufe verträgt.
Ich weiß aber nicht mehr ob das noch zu S5-Zeiten gehörte....

Deine Vermutung bezüglich des Löschens des Transport-Registers ist korrekt. Aber manchmal hab ich auch das Phänomen, das die Daten der Station davor plötzlich in der nachkommenden drin stehen.
Also der Transfer garnicht gelöscht wurde....

Hier mal der Code zur Übersicht. Ist aber bissel kompliziert, wenn man sich net so gut auskennt, was die Anlage macht. Aber vielleicht ist ja noch ein Irrer hier, der das so lesen kann

NW1:

      U(    
      U(    
      U     "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
      U     "101-2M1_FrVor"
      U     "=A+101-ST4"
      S     "DB_FIFO".FLAG_101_01
      U(    
      U     "102-2M1-InPos"
      UN    "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
      O     
      U     "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
      U     "101-2M1_FrRue"
      )     
      R     "DB_FIFO".FLAG_101_01
      U     "DB_FIFO".FLAG_101_01
      )     
      FP    "DB_FIFO".FLAG_101_02
      SPBNB _001
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO".FIFO_STATION_101
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO_TRANSFER".FIFO_STATION_101
_001: U     BIE
      )     
      SPBNB _002
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO".TYP_STATION_101
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO_TRANSFER".TYP_STATION_101
_002: U     BIE
      =     #CLEAR_OLD_TYP

NW2:

      U(    
      U(    
      U     #CLEAR_OLD_TYP
      SPBNB _003
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO".FIFO_NULL
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO".FIFO_STATION_101
_003: U     BIE
      )     
      SPBNB _004
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO".TYP_NULL
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO".TYP_STATION_101
_004: U     BIE
      )     
      SPBNB _005
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO".TYP_NULL
       RET_VAL:=#RETVAL
       DSTBLK :="101_VISU".FIFO_IST_STATION
_005: NOP   0

NW3:

      U(    
      U(    
      U     "101-2K25"
      U     "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
      U     "101-2M1_FrRue"
      S     "DB_FIFO".FLAG_101_03
      U(    
      U     "101-2M1-InPos"
      UN    "101_FU_DAT".PD_101M1.STATUSWORT_1.MOTOR_DREHT
      O     "101-2M1_FrVor"
      )     
      R     "DB_FIFO".FLAG_101_03
      U     "DB_FIFO".FLAG_101_03
      )     
      FP    "DB_FIFO".FLAG_101_04
      SPBNB _006
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO_TRANSFER".FIFO_STATION_101
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO".FIFO_STATION_101
_006: U     BIE
      )     
      SPBNB _007
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO_TRANSFER".TYP_STATION_101
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO".TYP_STATION_101
_007: NOP   0

NW4:

      U(    
      U(    
      U     "102-2M1-InPos"
      UN    "102_FU_DAT".PD_102M1.STATUSWORT_1.MOTOR_DREHT
      S     "DB_FIFO".FLAG_101_05
      U     "102-2M1_VA"
      U     "=A+102-ST4"
      U     "102_FU_DAT".PD_102M1.STATUSWORT_1.MOTOR_DREHT
      R     "DB_FIFO".FLAG_101_05
      U     "DB_FIFO".FLAG_101_05
      )     
      FP    "DB_FIFO".FLAG_101_06
      SPBNB _008
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO_TRANSFER".FIFO_STATION_101
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO".FIFO_STATION_102
_008: U     BIE
      )     
      SPBNB _009
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO_TRANSFER".TYP_STATION_101
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO".TYP_STATION_102
_009: U     BIE
      =     #CLEAR_OLD_TYP

NW6:

      U(    
      U     #CLEAR_OLD_TYP
      SPBNB _00a
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO".FIFO_NULL
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO_TRANSFER".FIFO_STATION_101
_00a: U     BIE
      )     
      SPBNB _00b
      CALL  "BLKMOV"
       SRCBLK :="DB_FIFO".TYP_NULL
       RET_VAL:=#RETVAL
       DSTBLK :="DB_FIFO_TRANSFER".TYP_STATION_101
_00b: NOP   0

 

[HaDi]

Nur so´ne Idee:
Du benutzt InPos- und Motor_dreht-Signale. Könnte es sein, dass diese Signale vielleicht ab und zu mal einen zusätzlichen "Wischer" reinstreuen, weil evtl. mal ein Überschwingen auftritt ?

Grüße von HaDi

 

[o_prang]

Hallo Krumnix,

ich denke Du bist aufm richtigen Pfad wenn Du bedenken hast, dass ein DB nicht so oft benutzt werden darf pro SPS-Zyklus.
Ich hatte auch schon bemerkt, dass man sehr vorsichtig mit den DBs umgehen muss, wenn man viele Zugriffe oder über Instanzen arbeitet.
Der DB wird meiner Meinung nach nicht richtig geöffnet, geschrieben und dann geschlossen wenn Du in einem FC Netzwerkweise auf diesen zugreiffst.

In Deinem Programm finde ich keinen Fehler. Deswegen würde ich Dir wie Ralle einen anderen Weg vorschlagen:
Ich habe bei solchen Anlagen mit mehreren Station immer pro Station einen Arbeits-DB (z.B. DB101= Station1; DB102=Station2,...) genommen. Für die Transferstrecke habe ich einen DB (z.B. 100) genommen.
Wenn dann der WT aus der Station läufst, machst Du nen Blockmove vom DB101 nach DB100. Dabei würde ich an Deiner Stelle die Werte "FIFO_Station" und "TYP_Station" zusammenfassen. Dann benötigst Du nur die Hälfte der Kopierfunktionen. Das wird sich direkt auf die Zykluszeit der SPS aus. (Und man hat weniger Fehlerquellen )
Wenn der WT dann in die nächste Station einläuft, kopierst Du aus dem DB100 nach DB102.
Für diese Funktion habe ich pro Station auch immer einen extra FC geschrieben. Dann bleibt es übersichtlicher (nur ca. 5 Netzwerke und nicht 100 wie in Deiner Version ) und die verwendeten DBs werden sicher geschlossen nachdem Du den FC verlassen hast.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Krumnix,

ich denke Du bist aufm richtigen Pfad wenn Du bedenken hast, dass ein DB nicht so oft benutzt werden darf pro SPS-Zyklus.
Ich hatte auch schon bemerkt, dass man sehr vorsichtig mit den DBs umgehen muss, wenn man viele Zugriffe oder über Instanzen arbeitet.
Der DB wird meiner Meinung nach nicht richtig geöffnet, geschrieben und dann geschlossen wenn Du in einem FC Netzwerkweise auf diesen zugreiffst.

Davon habe ich noch nie gehört und das halte ich auch ehrlich gesagt eher für eine Legende. Ein Step7-Programm wird ja zyklisch als ein "Thread" abgearbeitet. Da spielt es keine Rolle, wie oft ich auf einen DB zugreife und wie oft ich innerhalb eines Zyklus seine Daten ändere. Wenn man auf solche Dinge Rücksicht nehmen müßte, könnte man das Ganze sofort vergessen, da man dann ja keinerlei Angaben zur Zuverlässigkeit eines Programmes machen kann. Wenn mehrere Prozesse mit den selben Daten parallel arbeiten würden, sähe das schon anders aus. Dann müßte man sehr darauf achten, wer, was, wann schreibt!

PS: Instanzen muß man m.E. ohnehin speziell behandeln, das hat aber nur etwas mit dem Programmierstil zu tun. Das was du beschreibst hat eindeutig mit Fehlern beim Programmieren zu tun, was aber, zugegebener Maßen, bei Step7 schnell passieren kann und manchmal auch extrem schwierig zu finden ist!

 

[o_prang]

Davon habe ich noch nie gehört und das halte ich auch ehrlich gesagt eher für eine Legende. Ein Step7-Programm wird ja zyklisch als ein "Thread" abgearbeitet. Da spielt es keine Rolle, wie oft ich auf einen DB zugreife und wie oft ich innerhalb eines Zyklus seine Daten ändere. Wenn man auf solche Dinge Rücksicht nehmen müßte, könnte man das Ganze sofort vergessen, da man dann ja keinerlei Angaben zur Zuverlässigkeit eines Programmes machen kann.

Na eine Legende sieht anders aus. Ich habe vor ca. 3 Jahren eine Aussage vom Support bekommen, dass man mit zuvielen Zugriffen auf einen DB innerhalb eines Zykluses aufpassen soll. Dies hatte damals mit einer 316er CPU zu tun. Deswegen würde ich es nicht pauschalieren, sondern nur zum Nachdenken anregen!

Natürlich kann ich alle Umwegsamkeiten bzw. Probleme damit beheben, den Programmierstil zu ändern.
Aber für den Fehler den Krumnix beschreibt sehe ich keine logischen Fehler in dem Programm. Und da keine logischen Fehler drin sind, muss es automatisch mit dem Abarbeiten der S7 zu haben, oder?!?
Wenn Krumnix jetzt hingeht und sein Programm abändert, muss er das nicht aufgrund eines offensichtlichen Fehlers in seinem Programm machen, sondern weil die S7 die Abarbeitung nicht so macht wie macht es vorstellt.

 

[Ralle]

Zuallererst sollten mal die RetVal ausgewertet werden. Das mach ich im Normalfalle bei BlkMov eigentlich auch nicht, aber hier scheint ja kein Normalfall vorzuliegen.
Des Weiteren würde ich auf jeden Fall Code einbauen, der dafür sorgt, daß es nicht möglich ist, "leere", somit ungültige Daten in die Station bzw. den Transport-DB zu kopieren, weil eine Flanke nochmals ausgelöst wird. Dafür könnte man eine Zählvariable hernehmen, die 0 oder 1 sein muß. Bool geht auch, aber mit der Zählvariablen >1 oder <0 kann man gleich noch solchen "unerwünschten" Flanken auf die Spur kommen. Ohnehin finde ich die Verkettung der Logic über SPBNB und das BIE zwar platzsparend, aber eher aus "FUP-like Programing" geboren und in AWL absolut nicht die Übersicht fördernd. Dann lieber ein paar Bitabfragen doppelt, dafür aber die Übersicht gewahrt.

Ich habe vor ca. 3 Jahren eine Aussage vom Support bekommen, dass man mit zuvielen Zugriffen auf einen DB innerhalb eines Zykluses aufpassen soll. Dies hatte damals mit einer 316er CPU zu tun.

Au weia, wenn das stimmt, sollen die ihre Bude lieber dichtmachen, ehe irgendwelche Dampferzeuger oder Generatoren in die Luft fliegen, weil man 2 mal zuviel ein Datenwort mir der Temperatur ausgelesen und angezeigt hat!

 

[jabba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich setze den Blockmove seit jahren oft ein. Genau wie in diesem fall bei Schieberegistern und Auftragsverwaltungen usw. Wenn ich dabei einen Fehler hatte, lag der bisher immer an mir. Beim Blockmove habe ich noch keinen gefunden, auch wenn ich manchmal die Vermutung hatte.

Der Code war meist auch richtig, aber das timing war halt machmal falsch.

Man muss auf jeden fall verhindern das zur falschen Zeit und nicht zu oft geschoben wird. Dies kann z.B. durch einen prellenden Endschalter/Lichtschranke kommen, oder z.B. eine falsche Flankenbildung z.B. Verknüpfen von Bereit oder Steuerung mit der Auslösenden Funktion.

Zur eigentlichen Anlage ist ja nicht viel erklärt. Was passiert bei einem NIO Bauteil, fährt das eventuell direkt durch und schiebt dadurch die Daten weiter bevor die nächste palette in der Station dahinter ankommt?

Nur so als Denkansatz, kenn da Anlage ja nicht, aber auf solche Sachen muss man genau achten. Diese passieren im normalen Ablauf halt nicht, aber hin und wieder.

 

[jabba]

.... Ich habe vor ca. 3 Jahren eine Aussage vom Support bekommen, dass man mit zuvielen Zugriffen auf einen DB innerhalb eines Zykluses aufpassen soll. Dies hatte damals mit einer 316er CPU zu tun. Deswegen würde ich es nicht pauschalieren, sondern nur zum Nachdenken anregen!
...

Das sind die Antworten von den Herstellern wenn denen nix mehr einfällt.
Wahrscheinlich hast Due damals gefragt , "kann es sein..." , dann kommt immer so eine Antwort.

Ich kann die Temporären Variablen überschreiten, oder zuviel Trafic auf dem Bus erzeugen, aber wenn ich auf einen DB im normalen OB1 (also ohne OB35 usw) zugreife da draf nix passieren. Un wenn ich 1000 Blockmove ausführe, darf die Zykluszeit in die Höhe gehen und sonst nix.

 

[Krumnix]

Da ich ja, die Signale fürs schieben speichere und der (S) als Flanke weiter verarbeite, ist von der Seite erstmal alles ok. Jedoch setze ich mit dem InPos Signal meine Flankenmerker sozusagen wieder zurück. Und da muss ich euch recht geben, das dort ggf der "Fehler" sein könnte.
Ich werde morgen mal die Signale zu entprellen und das ganze beobachten.

Der Code wurde im übrigen in KOP programmiert (Vorgabe des Auftragsgeber)!

Das mit dem Zugriff auf DBs, das die beschränkt sein soll hab ich auch schonmal gehört, wie erwähnt. Aber ich glaube, das war damals zu S5-Zeiten gewesen. Bei der S7 der neusten Generation ist das nicht mehr der Fall, aber ich war mir halt nicht sicher, obs so ist.

 

[SW-Mech]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo....

Gibt es ein Phänomen, das der BLKMOV 20 Mal sauber arbeitet und dann auf einmal nicht mehr?!

Das Phänomen gibt es:
Der SFC20 kann vom Betriebssystem unterbrochen werden (OB-Aufruf),
dann kann es sein, dass der SFC20 nicht sauber oder gar nicht beendet wird.

Alternativ gibt es den SFC81 (UBLKMOV). Dieser kann nicht vom Betriebssystem unterbrochen werden, hat allerdings Einschränkungen
betreffend Datenmenge. Dies ist aber in der Help von Step7 beschrieben.

Gruss

 

[Constantin7]

Das Phänomen hatte ich auch schon mit einer CPU319. Bei einer "ungüstigen" Konstellation des SFC20 Aufrufs meldet der Baustein "fertig", hat aber nichts kopiert. Bei mir trat es beim kopieren größerer Daten auf und nur sehr sporadisch, aber reproduzierbar. Bisher hatte ich vermutet das der SFC20 vom letzten Aufruf den "Fertig" Ausgang nicht ablöscht und so beim nächsten Aufruf fertig meldet, obwohl er gar nicht angefangen hat.

 

[Larry Laffer]

@Krummix:
Nach Durchsicht deines Code-Schnipsels halte ich den Vorschlag von HaDi noch am Besten. Nach meiner Meinung kann es durchaus zu einem Doppelschieben kommen. Das solltest du mal testen.
Der Aufruf des SFC20 in der KOP-Kette gefällt mir intuitiv gar nicht. Ich würde bei diesem Netzwerk auf die KOP-Vorgabe "was scheissen" und den Transferblock (mit AWL) komplett überspringen.

@O_Prang:
Wenn du mit deiner DB-benutzen-Geschichte Recht hättest, dann würde von meinen Programmen kaum eines funktionieren. Der DB ist vom Grundsatz her auch kein anderer Speicher, wie beispielsweise die Merker.

Gruß
LL

 

[derwestermann]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jedes Bauteil wird ja irgendwo eine eigene Kennung oder so was (Werkstücknummer) haben. Wenn Du dann noch irgendwo ein Datenbit als "Datenvorhanden"-Flag verwendest, brauchst Du nur noch abzufragen, sind am Zielplatz Daten oder ist Deine Platzkennung schon da, kopierst Du nicht. Mache ich in Förderanlagen oft und gern und mit Erfolg.

 

[jabba]

Hab mal nachgesehen , in einer Anlage schiebe ich 58*20 Byte in einem Loop ohne Probleme, das geschieht durch den Loop in einem Zyklus.

 

[Paule]

Das Thema ist zwar schon ziemlich ausgelutscht aber ich will da auch noch mein Senf dazu abgeben:

Larry hat vollkommen Recht, und das wäre bei mir auch so wenn....

@O_Prang:
Wenn du mit deiner DB-benutzen-Geschichte Recht hättest, dann würde von meinen Programmen kaum eines funktionieren. Der DB ist vom Grundsatz her auch kein anderer Speicher, wie beispielsweise die Merker.

Gruß
LL

Merker sind am aussterben !

Der einzige Nachteil von einer DB-Adressierung ist der größere MC7 Code:

U DB1.DBX 10.0 
// wird ausgeführt in
AUF DB1
U DBX 10.0

Dafür sind alle DB's remanent und das kann mir keiner in der Hardwarekonfig verstellen. :-D

PS: BLKMOV kopiert halt OnBlock was die Zykluszeit erhöht. Aber wenn deine CPU das kann, dann lass sie kopieren bis sie heiss wird.
War teuer genug das teil, soll arbeiten.
Ich hatte noch nie Probleme mit BLKMOV und nehme viele. :-D

 

[Krumnix]

Zuviel Werbung?
-> Hier kostenlos registrieren

So, nach 2 Tagen testen hab ich den "Fehler" nun gefunden. Es kann vorkommen, das in einer bestimmten Situation, das Teil von der Folgenden Station schneller in der Zielstation ankommt, als erwartet und somit das Ausfördernde Teil noch in der Station ist und ich wieder ein InPos bekomme.

Um es mal genauer zu beschreiben, wenn es wen interessiert :

Ich habe 2 Inis für InPos. Diese wurden so installiert, das sie das Werkstück erkennen aber keine überlappen zur anderen Station möglich ist.
Das Problem ist aber, wenn das Werkstück von der sagen wir mal ST3 zu ST4 fährt, dann wird der 1. Ini frei. Das Werkstück aus ST2 fährt zeitgleich in ST3, wenn ST3 anfängt zu fördern. Jetzt kommt es irgendwie durch einen dummen Zufall (warum, keine Ahnung. Der Motor ist gut gelaunt und förder mal schnell als er soll *gg) dazu, das der Ini von ST3 vom dem ausfahrenden Werkstück noch belegt ist, aber InPos ist in dem Moment auf 0 (1 frei und 2 belegt = 0). Dummerweise kommt aber das Werkstück viel zu schnell aus ST2 an und belegt mir meinen Ini in der Einfahrrichtung. Somit habe ich wieder InPos = 1.
Jetzt fährt aber das Werkstück von ST3 in die ST4 ein und der Ausfahrini wird frei. Damit wird InPos = 0 wieder. Danach kommt aber das Werkstück aus ST2 in ST3 an und InPos ist wieder 1.
Das dumme dabei ist, wenn einer genau in diesem Moment die Schütztür öffnet. Denn dann habe ich das Problem, das die Umrichter keine Laufmeldung mehr senden und mein InPos auch nicht korrekt ist.
Und genau da habe ich meine Daten immer verloren.

Also lags an mir und net am BLKMOV. Verdammt :TOOL:

Trotzdem danke an alle, die mir mit Rat und Tat zur Zeit gestanden haben.
Es wurden die Inis nun so versetzt, das ein Überschneiden der Signale in keinester Weise möglich sind. Und das waren nur 5cm ^^

 

[jabba]

Dann lag ich ja gar nicht so verkehrt.