AI und Anlogwert-Umrechnungen

F

Finn

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

ich habe mal eine Frage. Ich finde einfach den Fehler nicht.

Früher hat die Umrechnung ein OP3 gemacht. (Umrechnung = X *0,1 + 450 )
Da ich soeine Funktion im OP73 nicht gefunden habe, mache ich das jetzt in der SPS.
Aber die Werte sind nur am springen.

Hardware ist i.O.
Verwendet werden sie nur:
FC2 - Direkt das PEW - Temperaturüberwachung (>12400)
FC4 - Umrechnung - Dient dem Display - Flammentemperatur bis ca. 1700°C.

Der Wert 12400 entspricht ca. 1650°C.

Jetzt zu meiner Frage:
Woran liegt das, dass meine Werte nicht umgerechnet werden.

Vielen Dank und liebe Grüße,
Finn

(Screenshot im Anhang)
 

Anhänge

  • Tempfüler.JPG
    Tempfüler.JPG
    199,8 KB · Aufrufe: 65
die wesentlichen probleme vermute ich in der verwendung von festpunktarithmetik mit gleitkommazahlen... das kann erfahrungsgemäß nicht funktionieren
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es muss wohl in die Hose gehen, wenn du DI mit R wahllos mischt.
Wenn deine Typenprüfung aktiv wäre, würde dir die Entwicklungsumgebung den Hinweis geben.


bike
 
... soll dann heißen, dass man das PEW erst in eine REAL-Zahl umwandeln muß damit man es mit einer REAL-Zahl multiplizieren kann.
Das gilt dann auch für alle anderen Rechnenvorgänge : INT nur mit INT verrechnen, REAL nur mit REAL verrechnen usw.

[ich habe das deshalb noch mal nachgelegt da ich vermute, dass der TE den Beitrag von 4L nicht wird deuten können ...]
 
Finn schrieb:
Alles klar, danke.
Wie wandel ich das denn um? Ich finde keine Baustein für Ganzzahl zu Gleitpunkt.
Zum Vergrößern anklicken....

aber du benutzt schon die online-hilfe im editor, oder?

DI_R : Ganzzahl (32 Bit) in Gleitpunktzahl wandeln
Zum Vergrößern anklicken....

jetzt machste dir aber bitte noch gedanken zum thema 16bit vs. 32bit ganzzahl ... besonders empfehle ich, sich über negative zahlen gedanken zu machen. und dann evtl. nochmal los ziehen und einen weiteren block suchen. Tipp: vorne steht meist der ausgangstyp, gefolgt von einem unterstrich, dann der zieltyp
 
... und als nächstes solltest Du AWL lernen. Da kannst Du Dir bei so Sachen 2/3 des Codes sparen.
Da kriegt man ja Augenkrebs, bei solchen FUP-Netzwerken!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
M-Ott schrieb:
... und als nächstes solltest Du AWL lernen. Da kannst Du Dir bei so Sachen 2/3 des Codes sparen.
Da kriegt man ja Augenkrebs, bei solchen FUP-Netzwerken!
Zum Vergrößern anklicken....

aber auch nur, weil es nicht strukturiert ist, sondern alle PEWs in einem netzwerk abgehandelt werden sollen ...
die augenkrebsverursachung liegt hier eindeutig in der verantwortung des "programmierers"
 
Stimmt, wenn du AWL verwenden darfst.
Aber nicht immer ist alles erlaubt und dann? Eben KOP.

Bei uns gibt der Kunde vor, was verwendet werden darf.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
gibt der kunde auch vor, in welcher form der fb/fc in seinem basiscode vorliegt? wenn ja würde ich sagen, mein lieber kunde, ich soll alles in fup/kop machen und darf nicht eine unterlagerte programmierung verwenden, ist ok, aber kostet ebend extra.

mal im ernst das die logischne funktionen im fup/kop abgebildet werden, lasse ich mir eingehen, aber nicht das kernfunktionen oder komplexe mathematische funktionen mit solch umständlichen werkzeugen zu erstellen sind.

ich würde auch nie auf die idee kommen meine PEW/PAW einzeln umzurechnen oder zu normieren, die fehler sind doch vorprogrammiert, ne schleife mit 2 kernfunktionen und nem db als zielspeicher für die ergebnisse sind da für meinen geschmack viel besser geeignet.

@finn:

neben 4l und Larrys anmerkungen empfehle ich dir noch für die Anzeige im Display nen Filter mit einzuprogrammieren, der einzelne BIT-Schwankungen filtert, je nach messbereich kann das schwanken eines bits im datenregister zu dauerhaften schwankungen an der anzeige führen.

Grüße Rupp
 
Rupp schrieb:
gibt der kunde auch vor, in welcher form der fb/fc in seinem basiscode vorliegt? wenn ja würde ich sagen, mein lieber kunde, ich soll alles in fup/kop machen und darf nicht eine unterlagerte programmierung verwenden, ist ok, aber kostet ebend extra.
Zum Vergrößern anklicken....


Dann bist du bei den Autoherstellern eben draussen.
Aber das ist eine Grundsatzdiskussion, die hierher nicht gehört, denke ich.



bike
 
bike schrieb:
Dann bist du bei den Autoherstellern eben draussen.
Aber das ist eine Grundsatzdiskussion, die hierher nicht gehört, denke ich.



bike
Zum Vergrößern anklicken....

das sehe ich nicht so, wir bauen prüf- und isolations-geräte für automobil-hersteller, welche solche vorgaben nicht beinhalten, soll heißen das auch hier kein grundsatzurteil gefällt werden kann, ich sagte ja auch nicht das es mit fup/kop nicht geht, ebend nur das ich es als persönlichen irrsinn empfinde
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Rupp schrieb:
das sehe ich nicht so, wir bauen prüf- und isolations-geräte für automobil-hersteller, welche solche vorgaben nicht beinhalten, soll heißen das auch hier kein grundsatzurteil gefällt werden kann, ich sagte ja auch nicht das es mit fup/kop nicht geht, ebend nur das ich es als persönlichen irrsinn empfinde
Zum Vergrößern anklicken....

Da sind keine Hersteller von Autos.
Also VauWe, Renault oder PSA verlangen es eben und daher leifern wir es.


bike
 
@bike
Von uns stehen auch Maschinen bei fast allen namhaften deutschen Automobilherstellern, es handelt sich zwar nur um Nebengewerk, aber unsere Maschinen sind sowohl in AWL als auch in CoDeSys in ST programmiert. Wenn man mit den technisch Verantwortlichen spricht, wird man oft merken, dass dieser Punkt relativ unwichtig ist. Diese Anforderung wird irgendwann mal von Einkäufern da rein geschrieben und die haben von der Technik nunmal absolut keine Ahnung.
 
Zurück
Oben