# Wago 750-650 über RS232-Lesekopf eHz auslesen



## knuetterich (20 Januar 2015)

Hallo,

ich möchte mit meiner Wago 750-841 und einer 750-650 (RS232) einen elektronischen Haushaltszähler (eHz) über einen optischen Lesekopf auslesen.
Den Lesekopf habe ich von der Volkszähler-HP geordert.

Hat jemand schonmal diese Anwendung programmiert?

Gruß
knuetterich


----------



## fraggle-m (20 Januar 2015)

Hallo,

Was hast Du denn für einen eHz?

Ich hatte das auch schon mal vor, da es aber derzeit recht zuverlässig über ip-symcon funktioniert habe ich das Projekt auf der ToDO-Liste nach ganz unten verschoben.

Gruß
Frank


----------



## Termi (20 Januar 2015)

Hallo,
ich habe gleiches vor:
1. Zähler ISKRA MT681 ist eingebaut.
2. Wagosteuerung mit serieller Schnittstelle hängt daneben
3. Lesekopf fehlt noch. Ich hatte noch vor der Installation des Zählers hinten eine Hager BKE Datenschnittstelle EZH001 einbauen lassen. Vielleicht sprudeln da ja ebenfalls die Daten. 

Gruß
Chris


----------



## shrimps (20 Januar 2015)

Hallo zusammen,
ich habe das ganze mal komplett mit dem Y-Port aus dem Forum Volkszaehler.org durchexerziert.
Ich hatte vele Ausfälle der Minilinuxkiste (vzlogger)
Dann habe ich Spaßeshalber mal das Protokoll mit Freebasic abgefange, decodiert und als TXT weggeschrieben.
Irgendwann habe ich es mit der Technik drangegeben, weil mir alles zu unzuverlässig erschien.
Gerne würde ich hier helfen, dies in OSCAt zu realisieren.
Ich bin allerdings auf Twincat mit Beckhoff unterwegs und noch recht frisch in der Programmierung.
Allgemeine Codierungen bekomme ich hin, aber eine RS232 mitlesen z.Zt. noch nicht.
Ich kann aber jemanden, welcher in meiner Nähe ist, gerne einen EMH ED300l als Testobjekt zur Verfügung stellen.
Der Spukt SML via Optokopf als HEX aus.
Mein YPort lässt sich via TCP ansprechen und dann kommen dort auf dem entsprechenden Port unaufgefordert permanent die Packete !!!
Das allein hatt mich schon Nerven gekostet, da fast alle Threads im Web, was die TCP-Stream-Leseprogrammierung angeht, von einem Request und anschl. endenden datenstrom ausgehen.
Naja, unter Freebasic hatte ich es geschafft.
Wer also das Teil mal braucht kann es gerne bei mir holen.
Habe auch den YPort und Optische Köpfe.
Die Dokus aus dem Netz etc ebenfalls.
Und jetzt macht mich fertig... 
LG
Shrimps


----------



## Termi (20 Januar 2015)

Hallo Shrimps,
warum sollte ich dich fertig machen? Jeder hat seine Erfahrungen und versucht, mit dem ihm zur Verfügung stehenden Mitteln zum Ziel zu kommen.
Ich nutze von SELEAE (www.seleae.com) die Hard- und Software. So hänge ich parallel mit 4 Ports (RTS,CTS,RXD und TXD) parallel über ein MAX232 an der Schnittstelle. Ich kann das Timing mitschreiben und analysieren wo datenrechnisch die Probleme liegen. War für eine Analyse der 232SS die effektivste Lösung und da ich oft Schnittstellenprobleme habe, hat sich das Teil schon lange bezahlt gemacht. 

Chris


----------



## Termi (20 Januar 2015)

Doppelpost- kann gelöscht werden


----------



## knuetterich (21 Januar 2015)

Hallo Zusammen,

hier gibt es ja einige die das Thema interessiert.

Zu deiner Frage Frank, ich habe einen Zweirichtungszähler von EMH (eHZ-IW8E2A5L0EQ2P).


Gruß
Ralf


----------



## Termi (26 Februar 2015)

So,
ich habe mal den Lesekopf angebaut und eine 750-8204 mir einer 750-652 neben einigen anderen Karten zu laufen gebracht. Sieht schon Positiv aus. Ich bin nur enttäuscht was mit mein EVU an Daten anbietet. Wirkleistung L1,L2,L3, Zählerstand und Gesamtverbrauch mit 2 Tarifen sind nutzbar und dafür werden 385 Bytes übertragen. Also ca. 400ms Daten und 1s Datenpause. Im Vergleich dieses geeichten Zählers zu einer 750-494 muss ich sagen, dass die Daten nahezu identisch sind. Es ist eine Abweichung von 1-2kWh bei wöchenlichem Vergleich und ca 140kWh Verbrauch also ca 1%!!! Hut ab Wago.

Ich habe im Moment jedoch noch Probleme mit den Daten. Ab und zu, so alle 10s sind da noch Ausreisser drin. Kleine Bugs, die ich noch finden muss. Ansonsten auch nicht tragisch, da immer wieder die aktuellen Werte nach 1,5s bereitstehen. 


Ich arbeite dran.

Chris


----------



## knuetterich (26 Februar 2015)

@Termi

Klingt ja sehr interessant.
Würdest du den Code zur Verfügung stellen?

Gruß
Ralf


----------



## Termi (27 Februar 2015)

Klar stelle ich den Code online. Gib mir noch ein paar Tage bis ich den o.g. Bug gefunden habe. Mit Bug ungerne

Gruß
Chris


----------



## Termi (4 März 2015)

so da bin ich mal wieder und möchte mal eine alpha-Version zum  Zählerdatenauslesen veröffentlichen. Ja, es gibt noch viel zu tun, aber  ich bekomme alle Zählerdaten, die ich brauche. Quick an dirty und nicht  universell, aber das brauche. Leider ist es mir nicht geglückt  eine funktionierende CRC-Checksumme zu generieren. Ich habe testweise  ein Array benutzt und bekomme eine ungleiche CRC-Summe, weder mit OSCAT  noch mit meiner Routine, die ich aus der smllib Datei SMLlib_tools.c  habe. Ich habe versucht, die relevanten Programmzeilen von C nach  CoDeSys zu portieren. Irgendetwas habe ich übersehen. Vielleicht könnt  ihr mal drüberschauen. Ich bin nicht unbedingt der Polynomer.:wink:         
Bei Unklarheiten, auch über den Programmablauf, einfach fragen. Keine PM
Chris

Anhang anzeigen CRC-Test.zip


----------



## knuetterich (5 Januar 2016)

Hallo Termi,

erstmal ein großes DANKE SCHÖN, dass du den Code zur Verfügung stellst. 
Ich denke das hilft mir schon weiter. Leider hatte ich bisher keine Zeit, mich intensiver damit zu beschäftigen...sollte in den nächsten Wochen aber soweit sein.
Was mir aufgefallen ist, das die Bausteine "CRC_GEN" und CRC_GEN01" einmal im FB "Zaehler_lesen" und einmal im Programm "PLC_PRG" aufgerufen werden.
Hat das einen bestimmten Grund und was machen die Bausteine überhaupt?

Ich habe eine Zähler von EMH edl21 der mir inkl. Füllbyte und Prüfsumme 392 Byte ausgibt.
Dort habe ich allerdings nur die Möglichkeit den Bezugszähler, den Einspeisezähler und die aktuelle Leistung auszulesen.
Wie muss ich dann das Programm anpassen (abgesehen davon, dass die auszulesenden Werte in anderen Bytes liegen können --> da hab ich schon einen Ausdruck in welchen Bytes die Werte stehen)?

Gruß
Ralf


----------



## Termi (5 Januar 2016)

Hallo Ralf,
der Name ist Programm. CRC_GEN und CRC_GEN1 generieren aus dem eingetrudelten Telegramm einen CRC-Code. Aber wie ich schon schrieb klappt es nicht.
Davonab, schreibe ich das Programm nicht weiter, da ich alles auf Codesys 3.5 portiert habe. Bis auf den CRC-Check läuft es ebenfalls super.

Wie Du das Programm anpassen mußt? Was willst Du jetzt lesen? Nun, du solltest verstehen was die Programmteile machen, dann fällt Dir das Anpassen auch nicht besonders schwer. 

Chris


----------



## sunshineboy10 (27 November 2016)

Hi Chris

anschlossen habe ich den EHZ. Kann mit dem Schnittstellen Baustein von Wago die Daten lesen. Doch die Aufbereitung mit deinem Programm bekomme ich nicht hin. noch nicht mal den Empfang.

MFG
Volker



Termi schrieb:


> Klar stelle ich den Code online. Gib mir noch ein paar Tage bis ich den o.g. Bug gefunden habe. Mit Bug ungerne
> 
> Gruß
> Chris


----------



## knuetterich (19 März 2018)

Hallo Termi, hallo sunshineboy10,

ich hatte das Projekt etwas aus den AUgen verloren ....versuche aber jetzt es zu reaktivieren...
Ich bin gerade dabei den Lesekopf an die Wago 750-652 anzuschließen.
Da  bin ich auf ein Problem gestoßen...laut Volkszähler-HP muss der braune  Draht (DTR) auf High-Pegel angeschlossen werden. Die serielle Karte hat  aber kein DTR, nur RTS und CTS.

Gibt´s da ne Lösung?


Gruß


----------



## fraggle-m (26 März 2018)

Hallo,

Kommt darauf an welche Spannung dein Lesekompetenz verträgt. Wenn nur 12 VDc wie meiner dann einfach mit einem DC-DC Wandler von 24 V auf 12 V.
Gruss
Frank


----------



## knuetterich (28 März 2018)

Hallo,

so...der Lesekopf benötigt +5V - 7V Versorgungsspannung, die über die DTR-Leitung eingespeißt wird.
Es ist also eine externe Spannungsversorgung notwendig oder eine Spannungsversorgungsklemme Wago 750-623.

Gruß


----------

