-> Hier kostenlos registrieren
Die Antwort lautet nein.
Aber einen gleitenden Mittelwert berechnen geht auch in F-KOP. Ist etwas Arbeit und solange du nicht 30 Werte mitteln willst auch überschaubar.
TIA Aufruf von Standard FB/FC aus Main_Safety_RTG
- Ersteller Guettl
- Erstellt am
-> Hier kostenlos registrieren
Aber einen gleitenden Mittelwert berechnen geht auch in F-KOP. Ist etwas Arbeit und solange du nicht 30 Werte mitteln willst auch überschaubar.
NBerger
Level-3
- Beiträge
- 1.680
- Reaktionspunkte
- 513
Warum sollte es denn nötig sein einen "sicheren" Analogwert zu verfälschen bevor man ihn auswertet???
Wird damit der Analogwert nicht unbrauchbar im Safety?
Liegt das Problem nicht im Analogwert selber? Muss dieser nicht den aktuellen "sicheren" Wert entsprechen?
Wird damit der Analogwert nicht unbrauchbar im Safety?
Liegt das Problem nicht im Analogwert selber? Muss dieser nicht den aktuellen "sicheren" Wert entsprechen?
-> Hier kostenlos registrieren
Sicher wird er schon sein, aber verrauscht.
Die Art und Weise der Analogwerterzeugung, die elektrische Übertragung, die AD-Wandlung, die Übertragung zur Steuerung, die Art und Weise wie der Messwert weiterverarbeitet wird.....
Bei "sicher" gehts um die Beurteilung des Verhaltens im Fehlerfall und nicht darum "sobald eine Klitzekleinigkeit für 5ms nicht passt alles stillsetzen".
NBerger
Level-3
- Beiträge
- 1.680
- Reaktionspunkte
- 513
-> Hier kostenlos registrieren
Ich mach doch auch nicht um ein Digitales Not-Halt Signal einen gleitenden Mittelwert und schau dann ob er diesen dann verlässst...
Bitte nicht falsch verstehen, aber wenn ich einen Analogen Wert im Safety verarbeiten soll der angeblich "sicher" ist dann habe ich diesen auch so zu verwenden und nicht irgendwie zeitlich oder im Wert zu manipulieren.
Ich könnt dann ja auch einfach sagen: Ich begrenze den Analogwert, da wenn er einen bestimmten bereich verlässt wäre das schlecht für meine Anlage.
Bitte nicht falsch verstehen, aber wenn ich einen Analogen Wert im Safety verarbeiten soll der angeblich "sicher" ist dann habe ich diesen auch so zu verwenden und nicht irgendwie zeitlich oder im Wert zu manipulieren.
Ich könnt dann ja auch einfach sagen: Ich begrenze den Analogwert, da wenn er einen bestimmten bereich verlässt wäre das schlecht für meine Anlage.
- Beiträge
- 12.315
- Reaktionspunkte
- 4.497
s
Ist eigentlich auch nix anderes.
Hast du noch nie eine (sichere) Ein- oder Ausschaltverzögerung an einem sicheren Positionsschalter verwendet um z.B. Prellen auszublenden?
Ist eigentlich auch nix anderes.
- Beiträge
- 11.111
- Reaktionspunkte
- 3.744
-> Hier kostenlos registrieren
Was ist das denn für ein Sensor? Oft kann man auch im Sensor selber ne Glättung einstellen...
Dafür gibts bei F-DIs die Entprellzeit in der Hwconfig. Von daher kann ich deine Frage auch nur mit Nein beantworten.
Und danke an Euch für die hervorragende Hilfe zum Ursprungsanliegen.
Übrigens hatte die neue KI im Siemens Service Request meine Frage mit "Kannste beruhigt machen" beantwortet...
Zuletzt bearbeitet:
-> Hier kostenlos registrieren
Zu 3.9 habe ich mal ne Frage :
Das mit einem Schnittstellen DB zwischen Safety-teil und Normal-Teil mache ich auch immer.
Habe letztens in irgendeinem Fremdprogamm gesehen dass dieser Schnittstellen DB ein Safety-DB war. Muss das so sein? Oder kann das so sein?
Finde icn der Safety Doku dazu keine Aussage.
Gruß Wilhelm
Muss nicht.
Ob man ohne Warnung direkt aus grauen Bausteinen in Safety-DBs schreiben kann, kann ich adhoc nicht beantworten.
Ich hab das lange Zeit so praktiziert:
ST->F war ein Standard-DB, abgeleitet von einem Safety-UDT
Hat aber den Reiz, dass man in einem Safety-UDT ausschließlich Datentypen deklarieren kann, welche auch in Safety verarbeitet werden können.
Kann man nicht. Spätestens beim Übersetzen des Sicherheitsprogrammes scherbelt es.
Umgedreht geht es aber: In grauen Bausteinen aus Safety-DBs lesen ist immer herzlich willkommen.
-> Hier kostenlos registrieren
Ok, das erklärt warum ich seinerzeit den Umweg über die UDTs gegangen bin.
