SFB4 funktioniert nicht richtig auf 416-2DP

Zu Mitsubishi:
Momentan in Ermangelung realer SPSen, nur mit GX-Simulator getestet,
aber wenigstens im Simulator funktioniert PT=0 wie gewünscht.

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das bezweifle ich nicht.
Es gilt ja auch vom Themenstarter im ertsen Beitrag:
<< Auf PLCSim funktioniert das Programm auch mit Zeitwerten T#0ms >>

Allerdings muss ich in sofern relativieren, daß meine Aussage nur für A1S CPU´s von Mitsubishi gilt. An denen hatte ich das gleiche Problem.
Wie das jetzt mit den Q´s ist - keine Ahnung.

peter(R)
 
Also bei meiner PLC-Sim Version funktioniert PT=0 auch nicht,
es könnte allerdings sein, das der TE noch eine ältere PLC-Sim-Version hat,
da war der SFB4 funktionell ja gar nicht implementiert, also nur als NOP0,
mit anderen Worten, die Zeit war praktisch immer 0.

P.S. Gerade noch mal probiert, wenn ich das Projekt für eine A1S-CPU erstelle,
funktioniert PT=0 auch nicht, bei FX und Q aber schon ...

Mfg
Manuel
 
Zuletzt bearbeitet:
@MSB
was mich mal wieder lehrt :
"Immer schön aufpassen mit den Aussagen und gaaanz genau sagen für was sie gelten sonst kanns Missverständnisse geben :ROFLMAO: ) !!

Mit Mitsubishi gehts halt manchmal doch !!! ;)

peter(R)

P.S. Wobei ich es schon etwas seltsam finde, daß es bei zwei mit der gleichen Software geschriebenen Programmen mal geht (FX) mal nicht (A1S).
Aber da gibts bei Mitsubishi ja auch noch den schönen Befehl <CHK> der geht selbst in der A1S Welt nur bei manchen CPU´s (steht aber nirgends geschrieben in welchen und warum nicht ).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also bei meiner PLC-Sim Version funktioniert PT=0 auch nicht,
es könnte allerdings sein, das der TE noch eine ältere PLC-Sim-Version hat,
da war der SFB4 funktionell ja gar nicht implementiert, also nur als NOP0,
mit anderen Worten, die Zeit war praktisch immer 0.

P.S. Gerade noch mal probiert, wenn ich das Projekt für eine A1S-CPU erstelle,
funktioniert PT=0 auch nicht, bei FX und Q aber schon ...

Mfg
Manuel

Das kuriose ist ja, ich hatte erst die PLCSim V5.3 SP1!!
Bei der Version hat der TON die Laufzeit gar nicht abgewartet, sondern bei jedem Zeitwert immer direkt durchgeschaltet. Kurz: Es waren keine Verzögerungen unter PLCSim möglich.
Dann durch Google etc das HF1 für diese Version "entdeckt", die das Problem mit dem TON beheben sollte.
Jetzt bin ich auf V5.3 SP1 HF1 und habe durch dieses Upgrade nur einen anderen Bug. Danke Siemens!!!! ;)
 
Verstehe ich jetzt nicht ganz.
Deine "alte" PLCSim hat so funktioniert wie es sollte (direkt durchgeschaltet )
aber nicht so wie die "reale" CPU also hat die Simulation falsch funktioniert weil sie ja nicht so falsch funktionierte wie die CPU die ja falsch funktioniert.

Jetzt hast du wie sich das gehört eine Simulation (die ja die CPU simulieren soll ) die genauso falsch funktioniert wie die CPU

ALSO FUNKTIONIERT SIE RICHTIG !!!! :???:ROFLMAO:roll:

(oder so ähnlich .... )

peter(R)
 
Nee, leider nicht. Nochmal kurz zur Info:

PLCSim V5.3 SP1:
TON schaltet direkt durch, auch wenn ein Zeitwert eingegeben wird (z.B. T#3s). Mit dieser Version sind überhaupt keine Verzögerungen möglich.

PLCSim V5.3 SP1 HF1:
TON funktioniert mit Zeitwerten und schaltet verzögert durch. Bei T#0ms schaltet er direkt durch.

Reale CPU:
TON funktioniert mit Zeitwerten, schaltet aber bei T#0ms gar nicht mehr durch.

Was für eine Version von PLCSim habt ihr denn?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jetzt habe ichs auch verstanden
also funktioniert ausser der
PLCSim V5.3 SP1 HF1 nix richtig



.... oder ????

( weil die geht so wie wir uns das an der CPU wünschen würden wenn wir was zu wünschen hätten ) :rolleyes: muss es wirklich der SFB4 sein ???


peter(R)
 
Genau so ist es.
Man lernt ja nie aus ... und im Nachhinein hätte ich das Programm wohl eher mit INT-Zählern programmiert die ich als Timer benutze. Damit lässt sich auch besser rechnen etc.
Aber nun ist es halt mal so das ich am Anfang für die SFB4 entschieden habe und alles fertig programmiert ist. Kann ja schlecht jetzt alles wieder umschmeissen.
Bin das Problem jetzt umgangen indem ich einen Vergleicher nach jedem Timer programmiert habe, der den Zeitwert auf >0 vergleicht. Damit setze ich mir dann einen Merker der den Timer überbrückt.
Find ich zwar Käse, aber was anderes ist mir auf die schnelle nicht eingefallen.
Oder andere / bessere Lösungsvorschläge?
 
Programmiere Dir einfach einen eigenen Schnittstellenkompatiblen TON und zwar einen der geht. Obwohl ich mich daran erinnern kann das Siemens bei einigen CPUs auch Probleme mit dem Zeit SFC hatte den man dafür verwenden würde (SFC1 oder so, kann mich die Scheiß nummern nie merken).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nee so was ähnliches hätte ich wohl auch gemacht.

Würde gerne das Gesicht des Programmierers sehen der sich das in 10 Jahren anschaut und sich fragt was für ein Penner solchen Mist programmiert hat da er ja dann wohl den Hintergrund nicht kennt *ROFL*

( ist jetzt wirklich nur spassig gemeint. Ich habe ab und an auch solche Leichen im Keller )


peter(R)
 
Programmiere Dir einfach einen eigenen Schnittstellenkompatiblen TON und zwar einen der geht.

*ACK*
der Meinung bin ich auch - für mich habe ich es auf diese Weise gelösst :
Ich habe einen Baustein, der mir unter Anderem die Systemzeit des CPU ausliest und diese dann in einer Global-Variablen zurückliefert. Diese Global-Variable verwende ich für meinen FB_Timer, der dann im Prinzip nach den gleichen Vorgaben wie der SFB4 arbeitet ...

Gruß
LL
 
*ACK*
der Meinung bin ich auch - für mich habe ich es auf diese Weise gelösst :
Ich habe einen Baustein, der mir unter Anderem die Systemzeit des CPU ausliest und diese dann in einer Global-Variablen zurückliefert. Diese Global-Variable verwende ich für meinen FB_Timer, der dann im Prinzip nach den gleichen Vorgaben wie der SFB4 arbeitet ...

Gruß
LL

Larry,
warum nimmst Du nicht einfach den SFC "TimeTicks" (habe gerade die SFC-Nummer nicht im Kopf) für deinen selbstgebauten Timer TON bzw. TOF? Der liefert ein TIME-Wert (abgelaufene ms seit CPU-Start als Doppelwort). Ist easy zu händl'n.

Gruß
Flinn
 
Aber Vorsicht bei Überlauf und CPU-Neustart mit dem SFC64 "TIME_TCK" da dieser von 0 bis 2147483647 ms zählt.

Gruss Daniel
 
Zurück
Oben