Seltsames Verhalten von Variablen und analoge Eingänge

E

Exing

Level-1
Beiträge
23
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wie in meinem ersten Beitrag unter https://www.sps-forum.de/wago/76426...t-codesys-2-3-und-wago-perspecto-cp-57-a.html schon einmal angedeutet, haben wir ein seltsames Verhalten der "normal" (also weder RETAIN noch PERSISTENT) deklarierten (globalen) Variablen festgestellt. So sprang ein analoger Messwert zwischendurch öfters mal auf 0, was die Weiterverarbeitung schwierig macht (Filter etc.). Persistent wollen wir diese Variablen nicht machen, da sie mehrmals pro Sekunde geändert werden und Filter verlangsamen das System. Durch kopieren der Quelltexte in ein neues Projekt scheinen wir diesen Fehler aber in den Griff bekommen zu haben.
Eine weiter unten deklarierte DWORD-(Test-)Variable allerdings, die wir mit 15 initiieren und dann nie mehr anfassen (KEIN Schreiben, KEIN Lesen), wird sofort auf 0 gesetzt und bleibt da. Warum ist das so? Worauf müssen wir achten? Was können wir dagegen tun?
Außerdem lesen wir zwei 4-20mA-Eingänge ein, die wir über LIN_TRAFO (aus der Util.lib) weiterverarbeiten wollen. Nun werden die 4mA-Werte auch mal als 3,9876... erkannt (z. B.), wodurch der LIN_TRAFO in den Fehlerzustand geht und nicht rechnet. Kann man da etwas machen, um dieses Problem zu umgehen (Filter bringen nicht viel, da werden - zumindest beim ersten Eingang - eher die 4mA-Werte herausgefiltert ;))?
Vielen Dank im Voraus für Eure schnelle Hilfe.

MfG
Exing
 
Hallo,
bei einem analogen Messewert kann das schon mal so sein (vor Allem, wenn er sowieso schon niedrig ist).
Dafür wäre dann ggf. Filter oder Glättungen (Mittelwertbildungen) gedacht.

Deine Variable, die du nur ein Mal zuweist ist nicht zufällig im TEMP-Bereich deines Bausteins deklariert ?
Wenn ja, dann wäre das der Grund für das beschriebene Verhalten.
Ansonsten wäre es vielleicht ganz nett, deinen Code ansehen zu können ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Larry,

vielen Dank für Deine ersten Hinweise.
Filter und Mittelwertbildungen bringen - wie oben gesagt - nicht viel, da der Wert dann unter 4mA bleiben wird. Wir prüfen gerade den Einsatz von Offset und Co. Mal sehen, welche Lösung wir finden.
Die Variable ist zwischen VAR_GLOBAL und END_VAR deklariert. In einem anderen (kleineren) Programm springt die Variable NICHT auf 0. Von daher kann es eigentlich kein TEMP sein, oder? Oder ist das bei WAGO anders oder gar zufällig, wohin die Variablen geschrieben werden?

MfG
Exing
 
Hallo Harald,

nein, mittels "AT" ist gar nichts verknüpft. Bei den Analogwerten gibt es eine Verknüpfung zum analogen Eingang und den (konstanten) Umrechnungsfaktoren, wobei der DWORD-Wert am analogen Eingang NICHT auf 0 springt. Bei unserer Testvariable gibt es GAR KEINE weitere Verknüpfung.

Noch einige Hinweise zum System:
Das Panel ist über ein CAT5-Kabel an einen Busknoten, bestehend aus
- 750-352 (1x),
- 750-601 (1x),
- 750-430 (2x),
- 750-530 (2x),
- 750-554 (1x),
- 750-606 (1x),
- 750-485 (1x) und
- 750-600 (1x)
angebunden. Vielleicht helfen diese Informationen ja weiter.

MfG
Exing
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Exing,

der FB LIN_TRAFO erfordert eine Eingangsvariable vom Typ REAL, die innerhalb der spezifizierten Grenzen IN_MIN und IN_MAX liegen muss. Die WAGO-Analogeingangsklemmen wandeln die Prozesswerte im Normalfall in einen Wert vom Typ WORD. Wenn nun am Eingang des FB LIN_TRAFO Werte auftauchen, die außerhalb des Bereiches von 4 -20 mA liegen, dann kann das eigentlich nur an einer fehlerhaften Behandlung bzw. Umwandlung dieses Prozesswertes vom Typ WORD in den Eingangswert für den LIN_TRAFO liegen.
Der Fall, dass der Eingangsstrom tatsächlich mehr oder minder deutlich unter 4 mA oder auch über 20 mA liegt, muss ggf. explizit betrachtet werden, weil hier auch ein Drahtbruch oder eine Fehlfunktion des angeschlossenen Sensors vorliegen kann. Die 4-20 mA Analogeingangsklemmen von WAGO mit 12 Bit AD-Wandler signalisieren diesen Zustand durch setzen der entsprechenden niederwertigsten Bits im Prozessabbild.
 
Hallo Exing,

habe gerade erst gesehen, dass Du die 750-485 als 4-20 mA Analogeingang verwendest. Dies ist gerade mal ein Sonderfall, weil sie die Ströme im Bereich von 0 bis 4 mA auch richtig messen kann. Sie signalisiert erst unter ca. 3,2 mA einen Drahtbruch. In diesem Fall würde ich die Grenzen für den LIN_TRAFO entsprechend etwas weiter setzen, damit der nicht sofort bei 3,9 mA mit einer Fehlermeldung antwortet. Der Bereich der OUT_MIN und OUT_MAX Werte ist dann ggf. analog anzupassen damit der Wert bei 4 mA auch stimmt.
 
Zuletzt bearbeitet:
Hallo,

das erste Problem scheint soweit gelöst zu sein: Die Variablen (Messwerte UND Testvariable) werden nicht mehr auf Null gesetzt - wir haben uns die Kommunikation mit dem Knoten noch einmal angesehen und festgestellt, dass die neu hinzugekommenen Analogausgänge im Transmit-Buffer gar nicht mit berücksichtigt waren. Nach der Erweiterung des Buffers gab es bis jetzt (nach einer Woche) keine Probleme mehr in die Richtung.

Das Problem mit dem LIN_TRAFO haben wir auch gelöst - wir haben einen eigenen LIN_TRAFO geschrieben, der auch leichte Unter- und Überschreitungen akzeptiert. Dafür kann man ihm auch zusätzliche Alarmwerte (z. B. 3.8 oder 22mA) übergeben. Berechnen tut er trotzdem mit 4-20mA und X bis Y bar (Kundeneinstellung).

Nun haben wir aber noch ein ganz anderes Problem: Die gemessenen Werte schwanken teilweise so stark, dass die aus den Werten gebildete erste Ableitung (mit DERIVATIVE) so nicht zu gebrauchen ist. Hat da jemand Erfahrung mit Filterauswahl, -Parametrierung, -Platzierung?

Außerdem ist im Panel unter Settings -> Date/Time der Punkte mit dem automatischen Berücksichtigen der Sommerzeit (Daylight Saving Time) mit einem Haken versehen - die Umstellung erfolgt(e) aber nicht automatisch? Warum nicht?

Vielen Dank schon mal im Voraus für Eure Antworten.

MfG
Exing
 
Hallo computershooter,

danke für Deinen Kommentar. Ehrlich gesagt verstehe ich den aber nicht so richtig: Das Problem mit dem LIN_TRAFO ist doch schon gelöst, indem wir einfach einen eigenen Funktionsblock entwickelt haben. Das Problem liegt jetzt darin, dass die automatische Umstellung auf Sommerzeit aktiviert ist, Windows CE aber nichts in diese Richtung tut...

MfG
Exing
 
es gibt drei zeiten im PLC maschine,
erstmahls die zeit NOW() die wird benutzt im program selber.
dan die zeit vom RTC wen die da ist.
und auch windows hat seine eigene zeit.
die RTC soll laufen auf UTC und hat kein sommerzeit in sich, man kan das aber mit software gut regeln.
die NOW() hat auch kein sommerzeit in sich aber das gleiche als oben.
die windows die hat sommerzeit, und die kan ausgeschaltet werden beim time rechtsunten auf schirm.
da gibt in einstellungen eine flag aus zu setzen.
 

Similar threads

E
Flankenerkennung und SR-Kippstufe mit CoDeSys 2.3 und WAGO Perspecto CP 57
Antworten
8
Aufrufe
4K
Exing
E
Zurück
Oben