Step 7 kWh-Zähler am FU (Danfoss)

S

showmewhatUgot

Level-1
Beiträge
100
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich habe folgendes Problem und zwar versuche ich den kWh-Zählerwert über die SPS auszulesen. Es kommt auch ein Wert an und wird plausibel hoch gezählt allerdings ist der negativ und weicht sehr stark vom dem Wert welcher am Display angezeigt wird.

-Danfoss FC-300er Reihe
-S7
-über Profibus
-Hardware ist auf PPO 8 Module consistent eingestellt
-Laut handbuch ist die Range für den Zähler 0 - 2147483647 [kWh] dafür reicht ja ein Word bzw 2 Byte nicht aus.
-Zähler hat Umrechnugsindex 75 (x3600), damit komme ich aber auch nicht auf den Wert

Darüber hinaus werden Frequenz Motorstrom und die Leistung ausgelesen und die Werte stimmen soweit.

Hat jemand eine Idee, denn ich bin gerade ratlos.. habe schon alles abgesucht...

Weil der WErt negativ ist, vermute ich dass der Tatsächlich Wert irgendwie falsch übermittelt bzw. falsch abgetrennt wird...
1.PNG
-
 
Zuletzt bearbeitet:
Laut Kommentar geht's an der markierten Stelle um Drehmoment. Zeigst Du uns die falsche Stelle oder sollen wir den Kommentar ignorieren?
Du willst/musst auch alle 4 Byte einlesen, die dazu gehören.
Der ITD ist mit Sicherheit fehl am Platz. Er wandelt einen INT (16 Bit = 2 Byte) in DINT (32 Bit = 4 Byte), d.h., selbst wenn Du die richtigen 4 Byte eingelesen haben solltest, arbeitest Du nur mit den zwei niederwertigsten Bytes weiter.
Das würde auch Deine negativen Werte erklären können.
Ausserdem wäre denkbar, dass die 4 angelieferten Bytes nicht in der erwarteten Reihenfolge kommen ("Little Endian vs. Big Endian").

PS:
Kannst Du mal ein Beispiel der eingelesen 4 Bytes liefern und passend dazu den Wert, der angezeigt werden sollte?

showmewhatUgot schrieb:
Darüber hinaus werden Frequenz Motorstrom und die Leistung ausgelesen und die Werte stimmen soweit.
Zum Vergrößern anklicken....
Stimmen die wirklich, oder könnten dort negative Werte angeliefert werden, die dann fälschlich als positive Werte angezeigt werden?
 
Zuletzt bearbeitet:
Den Kommentar kannst du ignorieren. Was ich aber auch nicht verstehe laut der Tabelle sind pro PCD jeweils nur 2 Byte vorgesehen, aber für die Größenordnung für den KWH-Zähler benötige ich die 4 Byte...
Falsche Reheinfolgen? Wie könnte man es übeprüfen bzw. korriegieren? Die anderen Werte kommen aber richtig an, müssten dann nicht alle Werte falsch ankommen?
 

Anhänge

  • 2.PNG
    2.PNG
    35,6 KB · Aufrufe: 24
Zuviel Werbung?
-> Hier kostenlos registrieren
Heinileini schrieb:
Laut Kommentar geht's an der markierten Stelle um Drehmoment. Zeigst Du uns die falsche Stelle oder sollen wir den Kommentar ignorieren?
Du willst/musst auch alle 4 Byte einlesen, die dazu gehören.
Der ITD ist mit Sicherheit fehl am Platz. Er wandelt einen INT (16 Bit = 2 Byte) in DINT (32 Bit = 4 Byte), d.h., selbst wenn Du die richtigen 4 Byte eingelesen haben solltest, arbeitest Du nur mit den zwei niederwertigsten Bytes weiter.
Das würde auch Deine negativen Werte erklären können.
Ausserdem wäre denkbar, dass die 4 angelieferten Bytes nicht in der erwarteten Reihenfolge kommen ("Little Endian vs. Big Endian").

PS:
Kannst Du mal ein Beispiel der eingelesen 4 Bytes liefern und passend dazu den Wert, der angezeigt werden sollte?


Stimmen die wirklich, oder könnten dort negative Werte angeliefert werden, die dann fälschlich als positive Werte angezeigt werden?
Zum Vergrößern anklicken....
nein, es werden positive werte geliefert, lediglich die Kommastelle wird angepasst duch *R bzw /R (s. Code)
 
showmewhatUgot schrieb:
Falsche Reheinfolgen? Wie könnte man es übeprüfen bzw. korriegieren? Die anderen Werte kommen aber richtig an, müssten dann nicht alle Werte falsch ankommen?
Zum Vergrößern anklicken....
Du hast Recht, wenn die 2-Byte-Werte richtig zu sein scheinen, dann hast Du nicht das Problem der "falschen" Reihenfolge der Bytes.
showmewhatUgot schrieb:
Was ich aber auch nicht verstehe laut der Tabelle sind pro PCD jeweils nur 2 Byte vorgesehen, aber für die Größenordnung für den KWH-Zähler benötige ich die 4 Byte...
Zum Vergrößern anklicken....
Der anfangs von Dir genannte ZahlenBereich 0..2.147.483.648 spricht eindeutig für DINT, also 4 Byte.
Deine PCD-Tabelle konnte ich noch nicht so richtig entschlüsseln.

PS:
Beim von Dir eingekringelten "Typ8" sind aber die Bytes 25..28 belegt (also 4 Bytes) - das entspricht dem, was wir erwarten?
Habe weiterhin Probleme, die Tabelle zu deuten.

PPS:
Wieviele Bytes werden denn durch L #EB.dw8 eingelesen?
Wo ist die Information der Länge versteckt? dw spricht für 2 Bytes (und EB für 1 Byte).
Ist EB.dw8 als DINT deklariert?
Ist EB.dw8 ein irreführender symbolischer Name?
 
Zuletzt bearbeitet:
Heinileini schrieb:
Na ja, Strom und DrehMoment sind immerhin proportional zueinander und so gesehen "eng miteinander verwandt". ;)
Ein EnergieZähler ist weit davon entfernt.
Aber es wäre schon schön/angenehm, wenn die Kommentare zum Verständnis beitragen und nicht zur Verwirrung.
Zum Vergrößern anklicken....
das Drehmoment war von dem Hersteller so angelegt, aber nirgendwo gebraucht und habe stattdessen darauf den KWH-Zähler gegeben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Heinileini schrieb:
Du hast Recht, wenn die 2-Byte-Werte richtig zu sein scheinen, dann hast Du nicht das Problem der "falschen" Reihenfolge der Bytes.

Der anfangs von Dir genannte ZahlenBereich 0..2.147.483.648 spricht eindeutig für DINT, also 4 Byte.
Deine PCD-Tabelle konnte ich noch nicht so richtig entschlüsseln.
Zum Vergrößern anklicken....
zu Tabelle:

die Hardware ist auf PPO Typ 8 eingestellt in der Tabelle unten links
die PCD 1-8 ist dann der Bereich für die eingestellten/gewünschte Werte 1 und 2 sind fest und 3 ist dann für die Frequenz 4 für den Motorstrom 5 Leistung 6 Drehmoment (jetzt KWh-Zähler), aber es sind immer jeweils 2 Bytes, das kann ja auch nicht stimmen..
 
Heinileini schrieb:
Laut Kommentar geht's an der markierten Stelle um Drehmoment. Zeigst Du uns die falsche Stelle oder sollen wir den Kommentar ignorieren?
Du willst/musst auch alle 4 Byte einlesen, die dazu gehören.
Der ITD ist mit Sicherheit fehl am Platz. Er wandelt einen INT (16 Bit = 2 Byte) in DINT (32 Bit = 4 Byte), d.h., selbst wenn Du die richtigen 4 Byte eingelesen haben solltest, arbeitest Du nur mit den zwei niederwertigsten Bytes weiter.
Das würde auch Deine negativen Werte erklären können.
Ausserdem wäre denkbar, dass die 4 angelieferten Bytes nicht in der erwarteten Reihenfolge kommen ("Little Endian vs. Big Endian").

PS:
Kannst Du mal ein Beispiel der eingelesen 4 Bytes liefern und passend dazu den Wert, der angezeigt werden sollte?


Stimmen die wirklich, oder könnten dort negative Werte angeliefert werden, die dann fälschlich als positive Werte angezeigt werden?
Zum Vergrößern anklicken....
Vielleicht, holt er den richtigen Wert als 4 Byte und interpretiert die dann als INT und wandelt die dann auf DINT um
 
showmewhatUgot schrieb:
Vielleicht, holt er den richtigen Wert als 4 Byte und interpretiert die dann als INT und wandelt die dann auf DINT um
Zum Vergrößern anklicken....
Das müsstest Du beobachten können, was da abläuft.
Heinileini schrieb:
PS:
Kannst Du mal ein Beispiel der eingelesen 4 Bytes liefern und passend dazu den Wert, der angezeigt werden sollte?
Zum Vergrößern anklicken....
Please show me what you've got, showmewhatUgot !

Ich hatte noch in meinem Beitrag #7 einiges angefügt und Deine zwischenzeitlichen Beiträge nicht gesehen.
 
Zuletzt bearbeitet:
lese doch mal in ner VAT das entsprechende PEW und sag uns als hex was da kommt und was der FU als Zähler-kWh gerade anzeigt.

vermutlich muss das irgendwie so sein:
Code: 
L PEW 5000
// ITD //nur notwendig, wenn der Wert als INT kommt, ich vermute es kommt UINT
DTR
L 3600.0 // evtl hier nen passenden Faktor einfügen
*R
T Ergebnis
 
Zuletzt bearbeitet:
ducati schrieb:
lese doch mal in ner VAT das entsprechende PEW und sag uns als hex was da kommt und was der FU als Zähler-kWh gerade anzeigt.
Zum Vergrößern anklicken....
Nicht DAS PEW, sondern die beiden, aufeinander folgenden PEWs!

Was konkret liest denn der L #EBdw8 ein? Wie ist diese Variable deklariert?

UINT und INT wären in jedem Fall falsch. In beiden Fällen wird der genannte WerteBereich nicht annähernd erreicht!
Ob UDINT oder DINT wäre egal, wenn der genannte WerteBereich stimmt bzw. nicht überschritten wird.
 
Zuletzt bearbeitet:
Die Sinn von die Umwandlungsfaktor 3600000 verstehe icht nicht.
Warum muss man mit diesen Faktor multiplizieren ?
Wenn die rohen Wert in kWh ist, dann bekommt man nach die multiplikation den Wert in Ws (Watt Sekunden). Aber wer verwendet Ws ?
Und mit die Multiplikation von ein Ganzzahl bekommt man kein höheren Auflösung.

Ich hätte es verstehen können, wenn die Zählerwert ein viel höhere Auflösung hat (die Ws) und um es in die normalen kWh zu bekommen, sollte man es mit die 3600000 dividieren, nicht multiplizieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ducati schrieb:
versuche mal mit 3600000 zu multiplizieren.
Zum Vergrößern anklicken....
Das können wir später immer noch nachholen, sofern gewünscht.
3600 = Faktor Umrechnung h in s
1000 = Faktor Umrechnung kW in W
Vielleicht wäre auch dividieren durch ... angebracht? ;)
ducati schrieb:
Das Wort was kommt ist vermutlich UINT von daher ist die Betrachtung als DINT schon richtig... (ohne ITD!)
Zum Vergrößern anklicken....
Was spricht dafür, dass der Wert tatsächlich als 16Bit-Wert übergeben wird? Das halte ich für seeehr unwahrscheinlich.

Typ8 ist in der neuen Tabelle verschwunden.
Jetzt ist Typ7 der "verdächtige"!?
Damit wäre die Aussage "UmrechnungsFaktor 3600" aus Beitrag #1 falsch aber "Konv.-Index 75" richtig.
Die Relevanz des Konv.-Index 75 dürfte für den Zähler (FU?) und seine Beschreibung gelten, aber die 75 ist beim Einlesen in die SPS irrelevant.
Da in der Beschreibung kWh steht, sollte man erwarten, dass die gelieferte Zahl direkt in kWh zu verstehen ist und nicht erst nach der Division durch 3.600.000 (also erst nach Umwandlung von Ws in kWh).
Plausibel wäre mir die Division durch "nur" 3600, also ggfs eine Umrechnung Ws in Wh, denn damit bleiben sozusagen die ersten 3 NachkommaStellen erhalten.
 
Zuletzt bearbeitet:
JesperMP schrieb:
Die Sinn von die Umwandlungsfaktor 3600000 verstehe icht nicht.
Zum Vergrößern anklicken....
verstehe ich auch nicht, steht aber in der Doku, nur stimmt die auch nicht immer...
Heinileini schrieb:
Was spricht dafür, dass der Wert tatsächlich als 16Bit-Wert übergeben wird? Das halte ich für seeehr unwahrscheinlich.
Zum Vergrößern anklicken....
ich hab grad in der Danfoss Software den Zähler am PPO8 angetragen und der hat nicht gemeckert...Wenn ich das am PPO 7 und 8 antrage, dann kann ich keine Unterscheidung nach Highword und Lowword machen...

ducati schrieb:
lese doch mal in ner VAT das entsprechende PEW und sag uns als hex was da kommt und was der FU als Zähler-kWh gerade anzeigt.
Zum Vergrößern anklicken....
das ist das einzige, was wirklich weiterbringt.
 
Zuletzt bearbeitet:

Similar threads

C
EL3403 kWh Zählerstand bleibt unregelmäßig nach kurzer Zeit stehen
2 3 4
Antworten
69
Aufrufe
9K
Crack123
C
D
Danfoss FC302 Profibus kein Alarmwort
Antworten
9
Aufrufe
8K
mkol
M
Zurück
Oben