Dauertest I/O-Ebene

[Kemosch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen,

für Ideen oder Ratschläge wäre ich sehr dankbar, wie man jene Aufgabenstellung mit Codesys lösen kann. Ich habe eine elektrische Verkettung von digitalen Ausgängen zu digitalen Eingängen installiert. Ich lege am ersten Ausgang (DO0) meiner I/O-Ebene in der Steuerung in Codesys einen Dauerimpuls an (mithilfe des FUNCTION_BLOCK BLINK). Den Ausgang DO0 an der SPS habe ich elektrisch mit dem Eingang DI0 verdrahtet und frage in Codesys ab, ob der Eingang DI0 logisch 1 ist. Insofern es das ist (mit jedem High-Impuls) setze ich den Ausgang DO1 in Codesys logisch 1. Der Ausgang DO1 ist wiederum elektrisch mit dem Eingang DI1 verdrahtet und ich frage im nächsten Netzwerk ab ob der Eingang DI1 logisch 1 ist, insofern es das ist setze ich den Ausgang DO2 logisch 1 (usw.). Am letzten Eingang in der Verkettung (DI5) möchte ich nun gern wissen, ob ich bei diversen äußerlichen Bedingungen, in die ich meine Steuerung versetze (Kältekammer, Dauertest) meine I/O-Ebene nach wie vor funktionsfähig ist und die am Eingang DI5 erhaltenen Impulse anaylisiere.
Ich habe dazu zwei Counter eingebaut , die mir am Eingang DI5 jeweils alle steigenden und fallenden Flanken aufzählt und jeweils aufaddiere. Was ich aber nicht hinbekommen habe ist eine Analyse einzubauen, ob im Dauertest und immer nach einer Zeit t ( t= Time Low + Time High des Impulses) ich am letzten Eingang der EVrkettung (DI5) immer eine steigende und eine fallende Flanke erhalten habe. Wie kann ich diese Kontrollinstanz realisieren? Wie kann ich in Codesys sicherstellen, dass auch auch nach Stunden des Dauerbetriebs dieser Applikation am letzten Eingang nach wie vor nach jedem Impuls eine steigende und eine fallende Flanke erhalten habe? Für Rückfragen stehe ich gern zur Verfügung. Vielen Dank.

 

[DaPivo]

Nur so ein kleiner Gedanke von mir:
Durch die Latenz der ganzen Ein- und Ausgangskaskaden sollte doch die fallende Flanke am Ende rauskommen, wenn das Ursprungssignal LOW ist (für steigende Flanke HIGH schon da). Wenn du beide Signale zum Zeitpunkt der Flanken vergleichst (Ausgang FB_BLINK == DI5) und das TRUE ist, sollte alles in Ordnung sein. Da würde ich einen Zähler einbauen, sofern das nicht so sein sollte.

 

[Kemosch]

Zuviel Werbung?
-> Hier kostenlos registrieren

DaPivo, ja, so funktioniert es. Ich lasse ein Dauertest laufen um zu schauen, wie es sich dann verhält. Danke!

 

[PN/DP]

Den Ausgang DO0 an der SPS habe ich elektrisch mit dem Eingang DI0 verdrahtet und frage in Codesys ab, ob der Eingang DI0 logisch 1 ist. Insofern es das ist (mit jedem High-Impuls) setze ich den Ausgang DO1 in Codesys logisch 1. (...)

Das klingt reichlich umständlich. Du könntest auch (z.B. in einer Task alle 10ms) einfach die Eingangszustände unbedingt an die Ausgänge weitergeben und nur überwachen, ob die Umschaltung des DO0 innerhalb einer bestimmten Zeit an DI5 ankommt. Hier schematisch 2 Lösungen (ungetestet):

A) einfache Lösung, dauert min. 6 Zyklen bis blink-Umschaltung an DI5 ankommt.
Die Lösung analysiert nicht, welcher Ausgang/Eingang problematisch ist.

//blink: ein Takt, z.B. mit TON oder Zykluszähler erzeugt, darf nur alle > 100ms umschalten

DO0 := blink.Q;
DO1 := DI0;
DO2 := DI1;
DO3 := DI2;
DO4 := DI3;
DO5 := DI4;

xdiff := DI5 XOR blink.Q;
TONinst(IN:=xdiff, PT:=T#100ms);
xfail := TONinst.Q;
CTUInst(CU:= xfail); //Fehler zählen

B) schneller bis alle Ausgänge und Eingänge umgeschaltet haben.
Bei der Lösung kann man analysieren, welches Ausgang/Eingang-Paar ein Problem hat.

//blink: ein Takt, z.B. mit TON oder Zykluszähler erzeugt, oder jeden Zyklus invertiert

xblink1 := blink.Q;
xblink2 := NOT xblink1;

DO0 := DO2 := DO4 := xblink1;
DO1 := DO3 := DO5 := xblink2;

xdiff := (DI0 XOR blink1) OR (DI2 XOR blink1) OR (DI4 XOR blink1)
      OR (DI1 XOR blink2) OR (DI3 XOR blink2) OR (DI5 XOR blink2);
TONinst(IN:=xdiff, PT:=T#30ms);
xfail := TONinst.Q;
CTUInst(CU:= xfail); //Fehler zählen

Ich habe dazu zwei Counter eingebaut , die mir am Eingang DI5 jeweils alle steigenden und fallenden Flanken aufzählt und jeweils aufaddiere. Was ich aber nicht hinbekommen habe ist eine Analyse einzubauen (...)

Die Counter eignen sich nicht für eine Analyse, weil die beiden Zählerstände werden sich immer nur um höchstens 1 unterscheiden. (zwischen 2 steigenden Flanken ist immer eine fallende Flanke und umgekehrt)

Harald

 

[Heinileini]

Wie kann ich ... sicherstellen, dass auch auch nach Stunden des Dauerbetriebs dieser Applikation am letzten Eingang nach wie vor nach jedem Impuls eine steigende und eine fallende Flanke erhalten habe?

Wenn keine positiven Flanken mehr ankommen, kommen auch keine negativen Flanken mehr an und umgekehrt, wie Harald schon mit anderen Worten sagte .
Die ankommenden positiven und negativen Flanken getrennt zu zählen, bringt also keine so wahnsinnig unverzichtbare Information.
Um beim ZählerAnsatz zu bleiben, würde ich eher einen Zähler für den Blinktakt bzw. den ersten angesteuerten Ausgang sowie je einen Zähler für jeden beteiligten Eingang spendieren.
Dann würde ich testen, welcher Eingang als erster keine Flanken mehr meldet. Die folgenden Eingänge werden dann ohnehin das gleiche tun (diese Fehler würde ich dann nicht mehr prüfen bzw. damit keine weiteren Abspeicherungen auslösen).
Beim Auftreten eines Fehlers nach erfolgreichen Durchläufen speicherst Du dann ab, wann (Uhrzeit und Zählerstand des BlinktaktZählers) welcher Eingang das Fehlverhalten zeigt (und einen Rückschluss auf den evtl. "schuldigen" Ausgangs erlaubt).
Ebenso bei erfolgreicher Durchschleusung des Blinktaktes bis zum letzten Eingang nach einem aufgetretenen Fehler würde ich die obigen Informationen abspeichern und alle Zähler löschen.
Zusätzlich zu den bereits o.g. Informationen wird eine weitere benötigt: der Zustand, ob ein Fehler gekommen oder gegangen ist.

Der Ansatz, einen Blinktakt über mehrere Stationen weiterzureichen, ist natürlich bestens geeignet, um relativ einfach zu prüfen, ob am Ende der Kette noch Lebenszeichen ankommen.
Eine gezieltere Diagnose, wo ("ungefähr") ein Fehler aufgetreten ist, ist damit eher aufwändig bis unvollständig.
Der Prüfung, ob nur 1 Ausgangs-/Eingangs-Paar betroffen ist oder mehrere, steht im Wege, dass ein Fehler ursächlich zu FolgeFehlern führt bzw. führen kann (je nach dem, wo in der Kette der Fehler auftritt).
So gesehen gefällt mir Haralds XOR-Ansatz mit Blinktakt und der Negation des Blinktakts, die parallel ausgegeben werden, statt von einer Verkettung Gebrauch zu machen.
In diesem Fall würde ich aber komplette Bytes (oder Vielfache davon) ausgeben, einlesen und auch vergleichen.
Die Eingangs-Bytes (oder -Worte oder DoppelWorte) würde ich dann auswerten, sobald sie 2 PLC-Zyklen lang gleich (= unverändert) eingelesen wurden bzw. bei einer positiven Flanke dieser Prüfung.
Das Bitmuster des VergleichsErgebnisses kann man anzeigen und dort erkennen, welche der Bits fehlerhaft sind.
Man kann auch das niederwertigste 1-Bit ermitteln und auswerten. Bei mehreren fehlerhaften Bits kann man diese nacheinander ermitteln (niederwertigstes auswerten und löschen, dann wieder das dann niederwertigste ... u.s.w., bis keine 1-Bits mehr vorhanden sind).

 

[Kemosch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das klingt reichlich umständlich. Du könntest auch (z.B. in einer Task alle 10ms) einfach die Eingangszustände unbedingt an die Ausgänge weitergeben und nur überwachen, ob die Umschaltung des DO0 innerhalb einer bestimmten Zeit an DI5 ankommt. Hier schematisch 2 Lösungen (ungetestet):

A) einfache Lösung, dauert min. 6 Zyklen bis blink-Umschaltung an DI5 ankommt.
Die Lösung analysiert nicht, welcher Ausgang/Eingang problematisch ist.

//blink: ein Takt, z.B. mit TON oder Zykluszähler erzeugt, darf nur alle > 100ms umschalten

DO0 := blink.Q;
DO1 := DI0;
DO2 := DI1;
DO3 := DI2;
DO4 := DI3;
DO5 := DI4;

xdiff := DI5 XOR blink.Q;
TONinst(IN:=xdiff, PT:=T#100ms);
xfail := TONinst.Q;
CTUInst(CU:= xfail); //Fehler zählen

B) schneller bis alle Ausgänge und Eingänge umgeschaltet haben.
Bei der Lösung kann man analysieren, welches Ausgang/Eingang-Paar ein Problem hat.

//blink: ein Takt, z.B. mit TON oder Zykluszähler erzeugt, oder jeden Zyklus invertiert

xblink1 := blink.Q;
xblink2 := NOT xblink1;

DO0 := DO2 := DO4 := xblink1;
DO1 := DO3 := DO5 := xblink2;

xdiff := (DI0 XOR blink1) OR (DI2 XOR blink1) OR (DI4 XOR blink1)
      OR (DI1 XOR blink2) OR (DI3 XOR blink2) OR (DI5 XOR blink2);
TONinst(IN:=xdiff, PT:=T#30ms);
xfail := TONinst.Q;
CTUInst(CU:= xfail); //Fehler zählen

Die Counter eignen sich nicht für eine Analyse, weil die beiden Zählerstände werden sich immer nur um höchstens 1 unterscheiden. (zwischen 2 steigenden Flanken ist immer eine fallende Flanke und umgekehrt)

Harald

Hallo Harald,

ich habe nun sowohl Deine Lösung A als auch Deine Lösung B nachgebaut. Bei Lösung B funktioniert es noch nicht, ich nehme an, es liegt an dem Takt, den ich versuche jeden Zyklus zu invertieren. Was mache ich da noch falsch? Spricht etwas dagegen, dass ich wie bei Lösung A für das blink-signal das FB_Blink nehme? Es funktioniert damit, nur Interesseshalber ob etwas dagegen spricht? Muss die Task alle 10ms aufgerufen werden? Was spricht gegen eine längere Aufrufzeit? Vielen Dank.

 

[Heinileini]

Bei Lösung B funktioniert es noch nicht, ich nehme an, es liegt an dem Takt, den ich versuche jeden Zyklus zu invertieren.

IF NOT Blink THEN Blink := TRUE ;
END_IF ;

... wird Blink nur einmalig auf TRUE setzen, ihn aber nicht in jedem Zyklus invertieren.

Blink := NOT Blink ;

... sollte es aber tun.

 

[Kemosch]

IF NOT Blink THEN Blink := TRUE ;
END_IF ;

... wird Blink nur einmalig auf TRUE setzen, ihn aber nicht in jedem Zyklus invertieren.

Blink := NOT Blink ;

... sollte es aber tun.

Hallo,
sorry. Habe ich nicht ganz verstanden wie du es meinst. Ich versuche einen Takt selber zu generieren, indem ich ihn zu Beginn des Zyklus logisch eins

IF NOT Blink THEN Blink := TRUE ;
END_IF ;

... wird Blink nur einmalig auf TRUE setzen, ihn aber nicht in jedem Zyklus invertieren.

Blink := NOT Blink ;

... sollte es aber tun.

hab nun eine Task Zeit von 50ms gewählt. Lösung B bekomme ich nach wie vor nicht aufgelöst, Lösung A habe ich mit veränderter TASK ZEIT angepasst und zum laufen bekommen. Danke.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe ich nicht ganz verstanden wie du es meinst. Ich versuche einen Takt selber zu generieren, indem ich ihn zu Beginn des Zyklus logisch eins

Dann habe ich Dich anscheinend nicht richtig verstanden, als Du schriebst ...

Bei Lösung B funktioniert es noch nicht, ich nehme an, es liegt an dem Takt, den ich versuche jeden Zyklus zu invertieren.

Soll Dein selbst gemachtes Taktsignal nun
- in jedem Zyklus seinen Pegel wechseln oder
- konstant auf 'true' verbleiben?
Falls letzteres, wäre der Begriff 'Takt' recht irreführend.

 

[Kemosch]

Dann habe ich Dich anscheinend nicht richtig verstanden, als Du schriebst ...

Soll Dein selbst gemachtes Taktsignal nun
- in jedem Zyklus seinen Pegel wechseln oder
- konstant auf 'true' verbleiben?
Falls letzteres, wäre der Begriff 'Takt' recht irreführend.

Ich habe es so gemacht wie du es sagtest und nun wechselt mein Blink in jedem Zyklus seinen Pegel. Danke für den Rat. Damit habe ich einen Fehler ausgemerzt. Allerdings sollte der Counter hochzählen, insofern die Kette unterbrochen wurde, das tut es nach wie vor nicht bei Lösung B von Harald. ich danke Dir trotzdem für die Zeit, die Du reinsteckst um mir zu helfen.

 

[Heinileini]

Änder mal bitte bei Lösung B die Reihenfolge der drei Zeilen

OnBoardIO_DIO0_CMD := ... ;
OnBoardIO_DIO1_CMD := ... ;
xdiff := ... ;

in

xdiff := ... ;
OnBoardIO_DIO0_CMD := ... ;
OnBoardIO_DIO1_CMD := ... ;

Allerdings ist mir noch ein Rätsel, wie der Timer etwas sinnvolles bewirken soll, wenn der Takt mit jedem Zyklus wechselt.

Ich denke, Du solltest direkt den xdiff als Fehler auswerten und den Timer ignorieren.

 

[Kemosch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Änder mal bitte bei Lösung B die Reihenfolge der drei Zeilen

OnBoardIO_DIO0_CMD := ... ;
OnBoardIO_DIO1_CMD := ... ;
xdiff := ... ;

in

xdiff := ... ;
OnBoardIO_DIO0_CMD := ... ;
OnBoardIO_DIO1_CMD := ... ;

Allerdings ist mir noch ein Rätsel, wie der Timer etwas sinnvolles bewirken soll, wenn der Takt mit jedem Zyklus wechselt.

danke erledigt. doch der counter bockt nach wie vor ;-)

 

[Heinileini]

danke erledigt. doch der counter bockt nach wie vor ;-)

Das Verfahren mit dem Wechsel in jedem Zyklus ist zeitlich sehr "spitz" bzw. knapp dimensioniert.
In der Zeit zwischen Ausgeben des PAA und dem Einlesen des PAE müsste die Hardware (AusgangsKarte - VerbindungsLeitungen - EingangsKarte) schnell genug sein, um "fehlerfrei" arbeiten zu können.
Ich würde den Code in jedem zweiten PLC-Zyklus durchlaufen und somit auch das Taktsignal nur in jedem zweiten Zyklus invertieren.
Und wie bereits gesagt bzw. nachträglich angefügt (s.o.) den Timer weglassen und xdiff direkt als Fehler auswerten.

Muss mich jetzt auf die Socken machen ...

 

[Heinileini]

Den Zähler könntest Du durch eine "ZählVariable" ersetzen, z.B.:

Blink := NOT Blink ;
IF Blink THEN
    xblink1 := NOT xblink1 ;
    xblink2 := NOT xblink1 ;
    xdiff := ... ;
    OnBoardIO_DIO0_CMD := ... ;
    OnBoardIO_DIO1_CMD := ... ;
    IF xdiff THEN
        dZähler := dZähler + 1 ;
    END_IF ;
END_IF ;

Blink (BOOL), xblink1 (BOOL) und dZähler (DINT oder INT) dürfen allerdings nicht TEMP sein, sondern STATIC.

Hier wird 'Blink' in jedem Zyklus invertiert und sorgt nur dafür, dass der "Kern" des Bausteins jeden zweiten Zyklus durchlaufen wird.
'xblink1' wird jetzt jeden zweiten Zyklus invertiert und somit wird das BitMuster, das an den Ausgängen ausgegeben wird, ebenfalls nur jeden zweiten Zyklus geändert. Für die "DatenÜbertragung" von den Ausgängen zu den Eingängen steht damit 1 ganzer Zyklus zur Verfügung statt nur eines Bruchteils eines Zyklus.

 

[Kemosch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den Zähler könntest Du durch eine "ZählVariable" ersetzen, z.B.:

Blink := NOT Blink ;
IF Blink THEN
    xblink1 := NOT xblink1 ;
    xblink2 := NOT xblink1 ;
    xdiff := ... ;
    OnBoardIO_DIO0_CMD := ... ;
    OnBoardIO_DIO1_CMD := ... ;
    IF xdiff THEN
        dZähler := dZähler + 1 ;
    END_IF ;
END_IF ;

Blink (BOOL), xblink1 (BOOL) und dZähler (DINT oder INT) dürfen allerdings nicht TEMP sein, sondern STATIC.

Hier wird 'Blink' in jedem Zyklus invertiert und sorgt nur dafür, dass der "Kern" des Bausteins jeden zweiten Zyklus durchlaufen wird.
'xblink1' wird jetzt jeden zweiten Zyklus invertiert und somit wird das BitMuster, das an den Ausgängen ausgegeben wird, ebenfalls nur jeden zweiten Zyklus geändert. Für die "DatenÜbertragung" von den Ausgängen zu den Eingängen steht damit 1 ganzer Zyklus zur Verfügung statt nur eines Bruchteils eines Zyklus.

Hab nun in der Zwischenzeit Lösung A) umgebaut, so dass ich nun alle vorhandenen I/Os elektrisch verkettet habe. Somit wird Lösung B) nicht mehr dem entsprechen, wie es nun tatsächlich elektrisch verdrahtet ist. Lösung A) funktioniert nach dem elektrischen und codesys Umbau nach wie vor gut.
Ich Weiß ehrlich gesagt auch nicht wie ich Lösung B dementsprechend nach Deinem letzten Vorschlag im Programm auf die nun vorhandene elektrische Verkettung umstricken müsste. Halt Codesys Anfänger ;-) Ich bin Dir dankbar für jeden Rat. Merci!

 

[Heinileini]

Ich Weiß ehrlich gesagt auch nicht wie ich Lösung B dementsprechend nach Deinem letzten Vorschlag im Programm auf die nun vorhandene elektrische Verkettung umstricken müsste. Halt Codesys Anfänger ;-)

Lösung A ist mit Verkettung und Lösung B ohne selbige. Die Prinzipien sind ganz unterschiedlich.
A erfordert auf jeden Fall diverse Zyklen, bis eine Änderung am Anfang der Kette sich am Ende der Kette auswirken kann.
Für mein Empfinden sollten bei B 2 PLC-Zyklen pro "Test-Zyklus" ausreichen, insbesondere, wenn die PLC-Zykluszeit nicht extrem kurz ist.

Ein Umstricken der Software von Lösungsweg B nach A (oder umgekehrt) macht wenig Sinn.
Aber auf die Verdrahtung zwischen den Probanden (Ausgangs- und Eingangs-Karte) muss sich der Unterschied, ob in der Software eine Verkettung vorgenommen wird oder nicht, doch nicht auswirken.

Wie viele Ein- bzw. Ausgänge haben die Probanden eigentlich und willst Du möglichst alle testen oder nur einen Teil der Ein- und Ausgänge (sozusagen exemplarisch)?

 

[Kemosch]

Lösung A ist mit Verkettung und Lösung B ohne selbige. Die Prinzipien sind ganz unterschiedlich.
A erfordert auf jeden Fall diverse Zyklen, bis eine Änderung am Anfang der Kette sich am Ende der Kette auswirken kann.
Für mein Empfinden sollten bei B 2 PLC-Zyklen pro "Test-Zyklus" ausreichen, insbesondere, wenn die PLC-Zykluszeit nicht extrem kurz ist.

Ein Umstricken der Software von Lösungsweg B nach A (oder umgekehrt) macht wenig Sinn.
Aber auf die Verdrahtung zwischen den Probanden (Ausgangs- und Eingangs-Karte) muss sich der Unterschied, ob in der Software eine Verkettung vorgenommen wird oder nicht, doch nicht auswirken.

Wie viele Ein- bzw. Ausgänge haben die Probanden eigentlich und willst Du möglichst alle testen oder nur einen Teil der Ein- und Ausgänge (sozusagen exemplarisch)?

Im Grunde genommen möchte ich gern alle vorhandenen Probanden in einem Zug an der gemeinsamen Verkettung testen, daher habe ich es heute auch so verdrahtet und die Änderungen in Typ A) angepasst (siehe auch dazu letztes Sreenshot von mir):

1. Blink -> DO0
2. DO0 ist elektrisch mit DI0+DI1+DI2 verbunden
3. Insofern (DI0 AND DI1 AND DI2)=log 1, dann DO1=log1
4. DO1 ist elektrisch mit DI3+DI4+DI5 verbunden
5. Insofern (DI3 AND DI4 AND DI5)=log 1, dann DO2=log1
6. DO2 ist elektrisch mit DI6+DI7 verbunden
7. Insofern (DI6 AND DI7)=log 1, dann DO3=log1
8. DO3 ist elektrisch mit DI8+DI9 verbunden
7. Insofern (DI8 AND DI9)=log 1, dann DO4=log1
8. DO4 ist elektrisch mit DI10+DI11 verbunden
9. Insofern (DI10 AND DI11)=log 1, dann DO5=log1
10. DO5 ist elektrisch mit DI12 verbunden

Ich hätte nur zu gern auch Typ B) + Deine letze Anpassung) entsprechend der neuen elektrischen Verkettung mit nun allen vorhandenen I/Os in Codesys angepasst nur bin ich zu grün dafür . Einfach auch um beide Lösungswege mir parallel zu veranschaulichen.
Außerdem bin ich weg in Typ A) von einer Task von 10ms hin zu nun 50ms. Bei Typ B) strebe ich auch die Task in 50ms an.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

2. DO0 ist elektrisch mit DI0+DI1+DI2 verbunden
3. Insofern (DI0 AND DI1 AND DI2)=log 1, dann DO1=log1

Ich würde in der Elektronik-Platine nebeneinanderliegende Eingänge/Ausgänge nicht mit dem selben Testsignal sondern mit Gegentakt betreiben (alle "geraden" und alle "ungeraden" Eingänge und Ausgänge jeweils gleich), um eventuelle Signalverfälschungen durch Kriechströme (Betauung, Vereisung, Staub, Öl, Kurzschlüsse, Defekt, ...) zu erkennen.

"Insofern ...": mache keine umständliche Wissenschaft aus den Ausgabe-Verknüpfungen sondern gib gaaanz einfach erzeugte Signale aus. Du denkst und formulierst viieel zu kompliziert und am Ende findet man schwer die Ursache, wenn sich das Programm nicht wie erwartet verhält. Deshalb mein Vorschlag B mit ganz einfacher klarer Logik, die außerdem eine schnelle parallele Verarbeitung der Testsignale ermöglicht. Die ganze Testlogik läßt sich im Grunde auch noch viel kompakter mit Word- oder Byte-weiser Verknüpfung der Eingänge und Ausgänge programmieren (wie Heinileini in #5 angedeutet hat), doch dafür muß man mit Verknüpfungs-Logik und Fehlersuche wirklich sattelfest sein.

Der Timer TONinst war dafür gedacht, um auf die Schnelle noch nicht umgeschaltete Eingangssignale für einen Zyklus + Digitaleingangsverzögerung zu ignorieren, damit ich nicht darüber nachdenken muß, wie kurz Deine Zykluszeit ist, wie groß die Eingangsverzögerung Deiner Hardware ist und wann die Eingänge eingelesen werden. Wenn der Takt jeden Zyklus wechselt, dann darf da natürlich kein TON-Timer sein. Dann muß man aber auch genau über den Programmablauf nachdenken, wie man dafür sorgt, daß geänderte Ausgangssignale garantiert im nächsten Zyklus eingelesen werden und daß man nicht schneller schaltet als die Hardware folgen kann. Das habe ich in meinem schnellen schematischen Entwurf des Testszenarios B nicht gemacht. Das war lediglich ein Entwurf um das Prinzip zu zeigen.

"Der Counter zählt nicht": das klingt mir schwer danach, daß die CTU-Counter eine steigende Flanke zum zählen brauchen. Eventuell müsstest Du den Counter ggf. zweimal aufrufen (einmal mit CU:= FALSE und einmal mit CU:= xfail) oder einen selbstgemachten Zähler auf Basis "Zählvariable := Zählvariable + 1;" implementieren. Wenn das Testprogramm mit in jedem Zyklus wechselnden Testsignalen arbeiten soll, dann muß man genau drüber nachdenken, wie und in welcher Reihenfolge man programmiert.

@Heinileini
Danke daß Du dem OP bei den Details etwas unter die Arme greifst, ich komme gerade nicht dazu, das Programm Variante B zu testen und auszufeilen.

Harald

 

[Heinileini]

Ich verstehe Deinen Wunsch, beide Lösungswege parallel bzw. eigentlich per Software umschaltbar, also wahlweise realisieren zu wollen.

Das HauptProblem sehe ich darin, dass Du an den Tests 6 Ausgänge und 13 Eingänge beteiligen willst.
Egal, wie Du es anstellst, wirst Du unter dieser Voraussetzung weder ...
- einen reinen, klaren Lösungsweg A noch
- einen reinen, klaren Lösungsweg B
realisieren können.
Der Wunsch, die Verdrahtung zwischen den Aus- und Eingängen für beide Lösungswege gleich zu halten, ist eine weitere Hürde, halbwegs sinnvolle, "aufgebohrte" Varianten der beiden Lösungswege zu finden.
Eine Bewertung der "aufgebohrten" Lösungswege A und B wird schon relativ schwierig im Vergleich zur Bewertung der "unverfälschten" Lösungswege A und B.
Und eine Gegenüberstellung beider Wege in der jeweils "aufgebohrten" Variante wird daher wenig aussagekräftig sein.
Ob sie dann auch noch anschaulich sein kann?

Bist Du immer noch daran interessiert, etwas "Analyse" mit einzubauen (was ich als Dein eigentliches Ansinnen in #1 verstanden hatte)?

Sooo, ich kann jetzt hier abbrechen, da mir Harald gerade mit seinem Beitrag mehr oder weniger "die Worte von der Zunge gerissen" hat.

 

[Kemosch]

Ich verstehe Deinen Wunsch, beide Lösungswege parallel bzw. eigentlich per Software umschaltbar, also wahlweise realisieren zu wollen.

Das HauptProblem sehe ich darin, dass Du an den Tests 6 Ausgänge und 13 Eingänge beteiligen willst.
Egal, wie Du es anstellst, wirst Du unter dieser Voraussetzung weder ...
- einen reinen, klaren Lösungsweg A noch
- einen reinen, klaren Lösungsweg B
realisieren können.
Der Wunsch, die Verdrahtung zwischen den Aus- und Eingängen für beide Lösungswege gleich zu halten, ist eine weitere Hürde, halbwegs sinnvolle, "aufgebohrte" Varianten der beiden Lösungswege zu finden.
Eine Bewertung der "aufgebohrten" Lösungswege A und B wird schon relativ schwierig im Vergleich zur Bewertung der "unverfälschten" Lösungswege A und B.
Und eine Gegenüberstellung beider Wege in der jeweils "aufgebohrten" Variante wird daher wenig aussagekräftig sein.
Ob sie dann auch noch anschaulich sein kann?

Bist Du immer noch daran interessiert, etwas "Analyse" mit einzubauen (was ich als Dein eigentliches Ansinnen in #1 verstanden hatte)?

Sooo, ich kann jetzt hier abbrechen, da mir Harald gerade mit seinem Beitrag mehr oder weniger "die Worte von der Zunge gerissen" hat.

Ich bin gern daran interessiert, den Aufwand zu nehmen, um Analysen einzubauen. Auf alle Fälle. Danke euch beiden für eure bisherige Hilfestellung.