TIA S7-1200 Amperestunden Zähler

Zuviel Werbung?
-> Hier kostenlos registrieren
so, läuft. ich glaube aber, dass das Integral dann keine As mehr sind, es sind aktuell zu wenig. Das Ergebnis teile ich ja dann durch 3600 um Ah zu erhalten.
In 5 min müßten 0,833333333 Ah gemessen werden. Nach 5 min ist das Integral bei einem Eingangswert von 10 bei 150.
Demnach müßte ich den Wert 150 durch 180 statt 3600 teilen, um auf 0,833333 zu kommen. Empirsch berechnet. Woher kommt die Abweichung?

die 50 ms vom cyclic interrupt wurde doch im SCL in Zeile 74 mit dem 0,05 multipliziert?

Im Umkehrschluss: statt 3600 nur durch 180 teilen, also müsste das Integral um Faktor 20 größer sein.
In Zeile 74 multiplizieren wir mit 0,05. Dies mit 20 nochmals multipliziert ergibt 1. Also müßte man gar nicht dort korrigieren?

Im InstanzDB des Integrators stehen:
tempDeltaTimeT = T#50MS
tempDeltaTimeDint = 50
tempDeltaTimeReal = 0.05

passt also, da ja #tempDeltaTimeReal im SCL mit 50 konstant gesetzt sind.
 
Zuletzt bearbeitet:
Sieht aus als würdest Du zweimal mit 0.05 multiplizieren. Hast Du auch die Zeile 77 entfernt? Ich habe für bessere Effizienz der Multiplikation die Zeilen 74 und 77 zusammengefasst. Das soll nun so aussehen:
Code: 
73	// Divide in half statScalIn [COLOR="#0000FF"]and Multiply with Delta Time (s)[/COLOR]
74	#tempValue := #tempValue / 2.0 [COLOR="#0000FF"]* 0.05; // wird alle 50 ms aufgerufen[/COLOR] <--- das ist Zeile 74 + [COLOR="#0000FF"]Zeile 77[/COLOR]
75
76	// Calculate new integral
77	#statIntegral := #statIntegral + #tempValue; //(alte Zeile 80)

PS: oder Du setzt irgendwo vorher #tempDeltaTime... auf fest 50 ms, so daß in der ursprünglichen Zeile 77 #tempDeltaTimeReal = 0.05 ist
Code: 
49	// Calculate time difference between last and actual time
50	#tempDeltaTimeT := [COLOR="#0000FF"]T#50MS;[/COLOR] [COLOR="#008000"]//#statSysTime - #statLastTime;[/COLOR]

Harald
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab wie im Post #59 nur Zeile 54 auf 50 fix und Zeile 74 um Faktor 0.05 erweitert.

Der Durlauf hat über einer Stunde eine Abweichung des Integralwertes von 1801.132 statt erwartet 1800.0 ergeben, also wesentlich genauer.
Aktuell läuft noch ein 3 Stunden Durchlauf, dann entferne ich noch Zeile 77 nach dem Motto: KISS und werde morgen nochmal 3 Stunden testen.
 
Wenn Du den Baustein LGF_Integration in einem cyclic interrupt aufrufst, dann würde ich die Uhrzeitverwendung und die ganzen überflüssigen Status-Ausgänge und "lesbaren" Konstanten komplett entfernen. Da verschwinden so nebenbei gleich ein paar Fehler :D
z.B.
Code: 
#statusID := [COLOR="#FF0000"]#NO_ERROR[/COLOR];
erzeugt in TIA V13 SP1 einen Übersetzungsfehler: "Eine implizite Konvertierung von Datentyp 'Word' nach 'UInt' ist nicht möglich."
So schlampiger Umgang mit Datentypen wurde in TIA erst später eingeführt/erlaubt. Der Fehler ist aber auch ein logischer Fehler, weil an #statusID soll laut Baustein-Beschreibung ein Fehler-Ort ausgegeben werden und keine Fehlernummer.

Code: 
// Read system time
#tempRetval := RD_SYS_T(OUT => #statSysTime);
	
// Error Handling read system time
IF ([COLOR="#FF0000"]#tempRetval > 1[/COLOR]) THEN
Das ganze extra "schön" gemachte Error Handling funktioniert überhaupt nicht, weil RD_SYS_T niemals Rückgabewerte > 1 zurückgibt... RD_SYS_T signalisiert zwar durchaus Fehler, doch die sind als W#16#80xx codiert, was als INT negative Werte < 1 sind :ROFLMAO::roll:
Da fragt man sich, was für ein Anfänger hat diesen Baustein programmiert, und hat der/die womöglich noch mehr verbrochen, womöglich Bausteine mit KnowHow-Schutz, damit man das Elend nicht sieht? ;) Hat bei Siemens wirklich kein Programmierer mit Ahnung Zeit, mal über solche Sachen drüber zu schauen? Wofür man keine Bezahlung verlangen kann, das darf halt auch nichts kosten.

Harald
 
Hier der abgespeckte LGF_Integration für den Einsatz in einem Cyclic interrupt. Der rechnet nun zur Verbesserung der Genauigkeit intern mit LREAL. Allerdings behandelt er die erste Berechnung ab enable = true noch nicht korrekt, was sich aber nicht auswirkt, wenn der In-value zu dem Zeitpunkt noch 0.0 ist.
Code: 
FUNCTION_BLOCK "(LGF)_Integration_C50ms"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 1.1
   VAR_INPUT 
      value : Real;   // -
      enable : Bool;   // -
      reset : Bool;   // -
   END_VAR

   VAR_OUTPUT 
      integral : Real;   // -
   END_VAR

   VAR 
      statOldValue : Real;   // -
      statIntegral : LReal;   // -
   END_VAR

   VAR_TEMP 
      tempValue : LReal;   // -
      tempNewValue : Real;
   END_VAR

   VAR CONSTANT 
      CycleTimeMsReal : LReal := 50.0;   // Aufrufintervall in ms hier eintragen
   END_VAR


BEGIN
//=============================================================================
// SIEMENS AG
// (c)Copyright 2017
//-----------------------------------------------------------------------------
// Library:       ( LGF (Library General Functions) )
// Tested with:   CPU1212C DC/DC/DC FW:V4.2
// Engineering:   TIA Portal V14 Upd 1
// Restrictions:  -
// Requirements:  PLC (S7-1200 / S7-1500)
// Functionality: The input value will be integrated.
//                The FB must be called in a cyclic interrupt.
//-----------------------------------------------------------------------------
// Change log table:
// Version  Date        In charge Changes applied
// 01.00.00 17.02.2017  Siemens Industry Online Support
//                      First released version
// 01.00.01 17.08.2018  Siemens Industry Online Support
//                      Upgrade: TIA V15 Update 2
//-----------------------------------------------------------------------------
// 01.01.00 31.01.2019  Harald SPS-Forum.de
//                      Verwendung Uhrzeit entfernt für Cyclic interrupt
//                      und die ganzen überflüssigen Statusausgänge entfernt
//                    (Logikfehler/Berechnung erstes Integral nicht korrigiert)
//=============================================================================

// Reset 
IF #reset THEN
  #integral := 0.0;
  #statOldValue := 0.0;
  #statIntegral := 0.0;
  RETURN;
END_IF;

IF NOT #enable THEN
  #statOldValue := 0.0;
  RETURN;
END_IF;

// Read input value to temp variable
#tempNewValue := #value;

// Add LastScalIn to ScalIn
#tempValue := #tempNewValue + #statOldValue;

// Save last input
#statOldValue := #tempNewValue;

// Divide in half statScalIn and multiply with Delta Time
#tempValue := #tempValue / 2.0 * #CycleTimeMsReal / 1000.0;

// Calculate new integral
#statIntegral := #statIntegral + #tempValue;

// Write output
#integral := LREAL_TO_REAL(#statIntegral);

END_FUNCTION_BLOCK
Hinweis: Wenn der Baustein in einem Cyclic interrupt aufgerufen wird, dann darf der zu integrierende Analogwert nicht aus dem Prozessabbild der Eingänge genommen werden, weil die werden nur im Rhythmus des OB1 aktualisiert. Im Cyclic interrupt muß der Wert von der Peripherie (Hardware Eingang) gelesen werden, das schreibt man in TIA so, daß an die Hardwareadresse ein ":P" angehängt wird, z.B. %EW64:P oder "Tag_1":P

Ablauf im Cyclic interrupt (z.B. alle 50 ms)
Code: 
             Analogeingang
          lesen und skalieren
               +-------+
               |       |
      %EW64:P--|IN  OUT|--"Stromwert_1"
               |       |
               +-------+

              Integration_Instanz
               +---------------+
               |               |
"Stromwert_1"--|value  integral|--"Strom_As"
               |               |
               +---------------+
Soll auch im OB1 der "Stromwert_1" oder "Strom_As" verwendet werden, so dürfen die Werte nur einmal gelesen werden, weil beim zweiten Zugriff können sie sich zum Wert vom ersten Zugriff verändert haben. Also am besten am Anfang des OB1 die Werte auf Kopien ( = Prozessabbilder) für die Verwendung im OB1 kopieren, und dann immer nur diese Kopien verwenden.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen Harald,
Vielen Danke für Deine Hilfe und die vielen Dinge, die ich dadurch lernen durfte. Ganz dickes Lob.

Wenn mal alles so läuft wie gedacht, müßte ich von 2 analogen Eingängen über die Zeit integrieren.
Ich würde dann in dem 50 ms cyclic interrupt zwei Instazen des Integrators laufen lassen und wie von dir geschrieben von der Hardwareadresse mit ":P" lesen.
Da ich Ah statt As benötige, würde ich im Integrator gleich noch den Divisor 3600

Code: 
// Write output
#integral:= LREAL_TO_REAL(#statIntegral) / 3600;

einfügen. Der aktuelle Ah Wert wird dann nur im HMI angezeigt und in einem FB verglichen. Da würde ich gleich auf den Wert in der InstanzDB des jeweiligen Integrators zu greifen.
Spricht etwas dagegen?

Ich werde sofort Deinen Integrator testen.
 
PN/DP schrieb:
Soll auch im OB1 der "Stromwert_1" oder "Strom_As" verwendet werden, so dürfen die Werte nur einmal gelesen werden, weil beim zweiten Zugriff können sie sich zum Wert vom ersten Zugriff verändert haben. Also am besten am Anfang des OB1 die Werte auf Kopien ( = Prozessabbilder) für die Verwendung im OB1 kopieren, und dann immer nur diese Kopien verwenden.
Zum Vergrößern anklicken....

Der Analogeingang wird normiert, das Ergebnis wird als LREAL Wert im Temp gespeichert, anschließend wird dieser Wert skaliert. Dieser Wert wird in einer globalen Variable gespeichert und ich anderen Bausteinen verwendet. Sollte doch gehen oder?

lg Frank
 
digidax schrieb:
Ich würde dann in dem 50 ms cyclic interrupt zwei Instazen des Integrators laufen lassen und wie von dir geschrieben von der Hardwareadresse mit ":P" lesen.
Da ich Ah statt As benötige, würde ich im Integrator gleich noch den Divisor 3600

Code: 
// Write output
#integral:= LREAL_TO_REAL(#statIntegral) / 3600;

einfügen.
Zum Vergrößern anklicken....
Das kannst Du so machen, doch schreibe bitte 3600.0 im Gleitpunktzahlformat. (gleich richtig angewöhnen, auch wenn in dieser Formel der Compiler auch so weiß was gemeint ist)
Und die Division noch in LREAL machen und erst das Ergebnis nach REAL wandeln könnte ein ganz klein wenig genauer sein.

Ich würde dann den Ausgang umbenennen oder noch einen zweiten Ausgang spendieren (nicht benötigte FB-Ausgänge kann man beim Aufruf unbeschaltet lassen):
Code: 
26	// Reset 
27	IF #reset THEN
28	  #integral_s := 0.0;
29	  #integral_h := 0.0;
30	  #statOldValue := 0.0;
...
55	// Write output
56	#integral_s:= LREAL_TO_REAL(#statIntegral);
57	#integral_h:= LREAL_TO_REAL(#statIntegral / 3600.0);


digidax schrieb:
Der aktuelle Ah Wert wird dann nur im HMI angezeigt und in einem FB verglichen. Da würde ich gleich auf den Wert in der InstanzDB des jeweiligen Integrators zu greifen.
Spricht etwas dagegen?
Zum Vergrößern anklicken....
Achtung! Schlechter Programmierstil!
Besser Du beschaltest den fürs HMI gewünschten Ausgang mit einer extra Variable fürs HMI. Das ist nicht nur übersichtlicher und besser nachvollziehbar, sondern man muß im Programm des FB keine Rücksicht nehmen auf externe Dinge die auf nicht offiziell dokumentierte interne Dinge zugreifen. Die offiziell dokumentierte Baustein-Schnittstelle sind die IN/OUT/INOUT-Parameter. Will man noch eine HMI-Schnittstelle haben, die aber beim Bausteinaufruf nicht an der Baustein-Box sichtbar sein soll, dann ist es technisch möglich auch auf die STATIC-Variablen zuzugreifen, doch man sollte dann diese HMI-Schnittstelle dokumentieren indem man da eine Struktur "HMI" mit den fürs HMI gedachten Variablen anlegt. Dann sieht man beim Baustein ändern daß diese Struktur so erhalten bleiben muß. Die Variablen in der HMI-Struktur sollten Kopien von internen Variablen sein bzw. nur eine einzige Zuweisung haben.

Zweites Problem beim Multi-Tasking-Zugriff der HMI (die HMI-Kommunikation ist ohne Zykluskontrollpunkt!) auf Baustein-interne Variablen: man darf nur auf Variablen zugreifen, die im Baustein nur eine einzige Zuweisung haben. Greift man auf Variablen zu, denen mehrmals Werte zugewiesen werden (z.B. "sicherheitshalber" erstmal auf 0 setzen und später vielleicht den richtigen Wert zuweisen) dann wird der am HMI angezeigte Wert "flackern", d.h. zwischen den an den verschiedenen Stellen zugewiesenen Werten springen. Der HMI-Projekteur weiß nicht bzw. prüft nicht, ob eine Variable im FB mehrmals beschrieben wird - deshalb Finger weg vom Zugriff auf interne Instanz-Variablen.

Harald
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
digidax schrieb:
Dieser Wert wird in einer globalen Variable gespeichert und ich anderen Bausteinen verwendet. Sollte doch gehen oder?
Zum Vergrößern anklicken....
Nein, nicht gut.

Die Programmteile, die im OB1 ausgeführt werden, wissen nicht wann sie vom Cyclic Interrupt unterbrochen werden und ob der Wert von vor oder nach der Unterbrechung stammt. Der Wert kann/wird im Cyclic Interrupt verändert werden. Deshalb muß der OB1 sich ein "Prozessabbild" (Kopie) der in anderen OBs veränderten Variablen anlegen und verwenden. Er muß die Variable des anderen OB selbst lesen/kopieren. Bei der Interprozesskommunikation zwischen verschiedenen Task dürfen die Variablen im Zyklus immer nur ein einziges mal gelesen werden.

Beispiel:
Code: 
IF Messwert > 0.0 AND Messwert <= 100.0 THEN
  X := A / Messwert;
END_IF;
Man möchte meinen, daß bei der Division der Messwert nicht 0.0 sein kann, doch wenn Messwert in einem OB verändert wird, der diesen Code genau zwischen den beiden Vergleichen unterbricht, dann kann ein Messwert = 0.0 unerkannt "durchschlüpfen"

Harald
 
digidax schrieb:
Wenn mal alles so läuft wie gedacht, müsste ich von 2 analogen Eingängen über die Zeit integrieren.
Zum Vergrößern anklicken....

Bei einer 1214 FS08 (Bj. 2018 ) ist mir kürzlich aufgefallen, dass bei Anschluss eines 5k-Poti an den zweiten AI (für 0-10V mit Vorwiderstand 6k8 an +24V) der AI-Wert des ersten Eingangs (von einem Messumformer) ungenauer wurde.

Der Messumformer macht sehr genau 2,000V LiveZero, der gewandelte Wert des AI war auch 5530, bei Anschluss des Poti an den zweiten AI änderte er sich auf 5494. Eine zweite CPU verhielt sich genauso, bei einer 1214 FS04 (Bj. 2015) waren die Werte 5530 / 5563.

Ob der gemeinsame Strom über den M-Anschluss oder was anderes die Wertänderung verursacht, habe ich (noch) nicht weiter ausprobiert, da diese Ungenauigkeit hierbei nicht stört.

Gruß und Danke euch beiden für den interessanten Austausch.
 
Zuletzt bearbeitet:
Okay, ich gebe ganz ehrlich zu, mit "Prozessabbild" zwischen den Bausteinen hatte ich noch nicht zu tun.
Aktuell läuft ja noch ein Test, danach werde ich:

- einen 2. Output mit dem Ah Wert ( / 3600.0) anlegen

Wie erreiche ich, dass der OB1 sich ein "Prozessabbild" (Kopie) der in anderen OBs veränderten Variablen anlegt?
Was ich bisher gelesen habe, gibt es ein Prozessabbild der Ein- und Ausgänge, dieses liegt im Prozessor vor.
 
digidax schrieb:
Wie erreiche ich, dass der OB1 sich ein "Prozessabbild" (Kopie) der in anderen OBs veränderten Variablen anlegt?
Zum Vergrößern anklicken....
Einfach genau 1x am Anfang des OB1 den Wert in eine globale Variable kopieren. "Prozessabbild" habe ich das Verfahren genannt weil es den selben Zweck hat wie das Prozessabbild der Eingänge: den Wert für einen ganzen Durchlauf des OB1 gleich/unverändert/konsistent zu halten, egal wann und wie oft der Wert abgefragt wird.

Im Cyclic interrupt (OB30):
Code: 
                        Analogeingang
                     lesen und skalieren
                          +-------+
                          |       |
                 %EW64:P--|IN  OUT|--"OB30_Werte".Stromwert_1
                          |       |
                          +-------+

                          Integration_Instanz
                          +-----------------+
                          |                 |
"OB30_Werte".Stromwert_1--|value  integral_h|--"OB30_Werte".Strom_1_Ah
                          |                 |
                          +-----------------+

Im OB1 bzw. in vom OB1 aufgerufenen Bausteinen:

Code: 
[COLOR="#008000"]//vorzugsweise am Anfang des OB1
//konsistentes Prozessabbild der im OB30 erzeugten Werte bilden[/COLOR]
"Analogwerte".Stromwert_1 := "OB30_Werte".Stromwert_1;
"Analogwerte".Strom_1_Ah  := "OB30_Werte".Strom_1_Ah;

...

[COLOR="#008000"]//nun nur die Werte des "Prozessabbildes" verwenden[/COLOR]
IF "Analogwerte".Strom_1_Ah > "Prozess".Grenzwert_1 THEN ...

IF "Analogwerte".Strom_1_Ah > "Prozess".Grenzwert_2 THEN ...
"Analogwerte".Strom_1_Ah hat so im Verlauf des OB1 immer den gleichen Wert, egal wann OB1 durch den OB30 unterbrochen wird.

Harald
 
Gleichstromer schrieb:
Der Messumformer macht sehr genau 2,000V LiveZero, der gewandelte Wert des AI war auch 5530, bei Anschluss des Poti an den zweiten AI änderte er sich auf 5494.
Zum Vergrößern anklicken....
Vielleicht benötigt der Messumformer zwischen seiner Versorgungsspannung und seinem Analogausgang eine Potential-Freiheit, die aber nicht mehr gegeben ist, wenn seine Versorgungsspannung mit dem 2M der 1214-Analogeingänge verbunden ist? Oder eine evtl. gegebene max zulässige Potential-Differenz des Messumformers zu 2M wurde überschritten?

Für genauere Aussagen müsste man die genaue elektrische Verschaltung sehen und den Typ des Messumformers wissen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gleichstromer schrieb:
Bei einer 1214 FS08 (Bj. 2018 ) ist mir kürzlich aufgefallen, dass bei Anschluss eines 5k-Poti an den zweiten AI (für 0-10V mit Vorwiderstand 6k8 an +24V) der AI-Wert des ersten Eingangs (von einem Messumformer) ungenauer wurde.
. . . der gemeinsame Strom über den M-Anschluss oder was anderes . . .
Zum Vergrößern anklicken....
Ich hab's schon immer befürchtet, aber nie wirklich festgestellt. Fand nämlich die Technik, mehrere AnalogSignale reihum auf ein und denselben AnalogDigitalWandler zu multiplexen, irgendwie suspekt. Nach dem gemeinsamen Strom über den M-Anschluss wäre der AnalogMultiplexer bei mir der nächste Verdächtige als mögliche Ursache. Allerdings könnte man als Anwender dann wohl kaum das Problem beeinflussen.
Interpretiere ich die Aussage "sehr genau 2,000V LiveZero" richtig, dass Du an dem einen Eingang die hochkonstante Spannung von 2 V anliegen hast? Dann würde ich doch mal messen, was passiert, wenn . . .
- am Poti ebenfalls 2 V eingestellt ist
- am Poti eine niedrigere Spannung (z.B. 0 V)
- am Poti eine höhere Spannung (z.B. 5 V)
- und letztlich die Verbindung des 6k8 Widerstandes nach + 24 V getrennt ist (das Poti jedoch weiterhin mit dem AE verbunden).
 
So, die Simulation über 4 Stunden hat exakt funktiniert. Nun mir realen Werten vom Gleichrichter.
Das Prinzip mit dem "Prozessabbild" hab ich nun verstanden, ganz logisch.
Das HMI liest ja in seinem eigenen Zyklus, dann wäre es wohl gut, den einmal für den OB1 am Anfang als "Prozessabbild" definierte Variable auch im HMI zu lesen?
 
digidax schrieb:
Das HMI liest ja in seinem eigenen Zyklus, dann wäre es wohl gut, den einmal für den OB1 am Anfang als "Prozessabbild" definierte Variable auch im HMI zu lesen?
Zum Vergrößern anklicken....
Ja, die kannst Du nehmen. Du könntest aber auch die OB30-Variable nehmen, Hauptsache die Variable bekommt nur einmal im Zyklus einen Wert zugewiesen. Wenn Du für die HMI keine extra Variablen anlegen möchtest, dann halte ich die OB1-Variable für ein bisschen besser geeignet (Geschmackssache).
ABER: Auf welche Variablen die HMI zugreift sieht man im SPS-Programm nicht, und weiß deshalb nicht was man im Programm nicht verändern darf ohne das HMI zu beeinflussen (man müsste bei jeder Variablenänderung auch ins HMI-Projekt schauen). Ich finde es besser, für die HMI einen/mehrere extra angelegte DB ("Visu", "HMI", ...) mit Kopien der interessierenden Variablen anzulegen, da hat man erstens schön deutlich die Schnittstelle zum HMI dokumentiert und zweitens ein (versehentliches?) Schreiben der HMI auf diese Variablen beeinflusst das Programm nicht. z.B. in meinem Beispiel in #69 könnte auch das HMI Werte in die Variable "Messwert" schreiben und könnte dadurch die Prüfung auf > 0.0 aushebeln, und drittens kann man eigene HMI-Variablen besser für den Test und Dokumentation/Bildschirmfotos der HMI manipulieren ohne das Programm zu beeinflussen.

Harald
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Off Topic

Heinileini schrieb:
Ich hab's schon immer befürchtet, aber nie wirklich festgestellt. Fand nämlich die Technik, mehrere AnalogSignale reihum auf ein und denselben AnalogDigitalWandler zu multiplexen, irgendwie suspekt. Nach dem gemeinsamen Strom über den M-Anschluss wäre der AnalogMultiplexer bei mir der nächste Verdächtige als mögliche Ursache. Allerdings könnte man als Anwender dann wohl kaum das Problem beeinflussen.
Interpretiere ich die Aussage "sehr genau 2,000V LiveZero" richtig, dass Du an dem einen Eingang die hochkonstante Spannung von 2 V anliegen hast? Dann würde ich doch mal messen, was passiert, wenn . . .
- am Poti ebenfalls 2 V eingestellt ist
- am Poti eine niedrigere Spannung (z.B. 0 V)
- am Poti eine höhere Spannung (z.B. 5 V)
- und letztlich die Verbindung des 6k8 Widerstandes nach + 24 V getrennt ist (das Poti jedoch weiterhin mit dem AE verbunden).
Zum Vergrößern anklicken....

Siemens gibt für die CPU-AI 3,5% vom Vollauschlag bei -20 bis +60°C an, da scheinen wohl ein Drehspul-Wandler und Kohleschicht-Widerstände verbaut zu sein.
Die von Digidax durchgeführten Messungen (und meine) zeigen eine deutlich höhere Genauigkeit. Aber die analogen Signalmodule müssen ja auch unters Volk ...

Habe momentan keine Anlage hier, werde bei der nächsten Anlage testen und berichten.


 
PN/DP schrieb:
Hat sich das Phänomen mit dem nicht funktionierenden RUNTIME bei Dir aufgeklärt?

Harald
Zum Vergrößern anklicken....

Nein, keine neuen Erkenntnisse diesbezüglich. Ich bin aber noch nicht dazu gekommen, die Gegenprobe auf einer 1200 zu machen.

Hat denn jemand anderes hier mit einer realen 1500 meine Beobachtung bestätigen oder widerlegen können?
 
Zurück
Oben