Domotica met plc's

[meijer3]

Mocht je een warmte pomp hebben, bedenk dan dat zoning in vloerverwarming misschien niet is wat je wilt. Je COP van je warmte pomp zou zo maar eens lager liggen, dan met de energie die je spaart. Het klinkt onnatuurlijk maar kijk eens deze video:
YouTube: Why NOT to ZONE Heat Pumps! or boilers.. (SURPRISING RESULTS!!)

Eerst wou ik het ook automatiseren maar nu staan de vloerverwarming hier eigenlijk standaard aan en past de warmte pomp zijn output hier op aan.

Voor andere verwarming systemen geld dat dan weer niet echt.

[Kanze]

MichVw schreef op vrijdag 5 januari 2024 @ 19:32:
[...]


Ik ben iets aan het schrijven maar nog niet aan testen geraakt. Ik denk dat wat je zoekt een simpele FB is waar je de gemeten temperatuur, desired temperatuur, aan/uit kan in pompen en dat die dan een signaal geeft voor de pomp van je vloerverwarming?

Opgepast met de montage van drivers op OSB. In principe mag je niet direct op brandbare materialen monteren.

Hier zitten ze in metalen kasten IP40. En die hangen dan op een betonplex. Bij keuring kan men moeilijk doen.

[ Voor 3% gewijzigd door Kanze op 06-01-2024 11:31 ]

[cotton_eye_joe]

Roekeloos schreef op woensdag 3 januari 2024 @ 02:50:
Allereerst het DMX verhaal. Dat is nu Artnet via Home Assistant, waarbij ik gebruik maak van scenes, die getriggerd worden door schakelaars die aan de PLC hangen. Bij alle ruimtes is enkel drukken de "hoge" scene aan/uit en lang drukken de "lage" scene, waarachter vaak een scene zit voor die ruimte met meerdere DMX kanalen met verschillende waarden. Als ik dit naar de PLC wil halen, kom ik bij die "dimmer" functieblokken uit, maar ik wil geen schakelaar vasthouden tot de verlichting de gewenste waarde heeft. De enige manier om de huidige opzet te bereiken, is door te werken met heel veel virtual_ints waarin de DMX waarden van de verschillende scenes zijn opgeslagen. Of heeft iemand een ander idee?

Ik heb zelf alle variabelen horende bij een scène in een struct om ze met weinig code door het programma te kunnen verplaatsen. Zoals bijvoorbeeld bij het aanroepen of wijziging van scènes. Uiteindelijk zul je ze een keer naar je dmx kanalen moeten schrijven maar dat hoeft slechts op 1 plek in het programma

[Roekeloos]

cotton_eye_joe schreef op vrijdag 12 januari 2024 @ 23:08:
[...]


Ik heb zelf alle variabelen horende bij een scène in een struct om ze met weinig code door het programma te kunnen verplaatsen. Zoals bijvoorbeeld bij het aanroepen of wijziging van scènes. Uiteindelijk zul je ze een keer naar je dmx kanalen moeten schrijven maar dat hoeft slechts op 1 plek in het programma

Dat klinkt logisch, maar ik ben helaas geen PLC programmeur. Ik begrijp de code wel en kan deze aanpassen, maar zoiets kan ik niet from scratch opzetten. Voorbeelden zijn dus welkom…

[cotton_eye_joe]

Roekeloos schreef op vrijdag 12 januari 2024 @ 23:52:
[...]


Dat klinkt logisch, maar ik ben helaas geen PLC programmeur. Ik begrijp de code wel en kan deze aanpassen, maar zoiets kan ik niet from scratch opzetten. Voorbeelden zijn dus welkom…

Je voegt een struct toe (Add object -> DUT -> Structure) in het voor beeld heet hij DUT

Declaratie van de struct:

TYPE DUT :
STRUCT
iLampPlafondLinks : INT;
iLampPlafondRechts : INT;
bLampBedLinks : BOOL;
bLampBedRechts : BOOL;
END_STRUCT
END_TYPE


In het programma zet je in de declaratie:

PROGRAM PLC_PRG
VAR
stStoredScenes : ARRAY[0..10] OF DUT;
stCurrentVals : DUT;
i : INT;
END_VAR


Programma:

stCurrentVals := stStoredScenes[i];


Speel maar eens met de variablen en kijk wat het doet

[Femme]

meijer3 schreef op vrijdag 5 januari 2024 @ 21:15:
Mocht je een warmte pomp hebben, bedenk dan dat zoning in vloerverwarming misschien niet is wat je wilt. Je COP van je warmte pomp zou zo maar eens lager liggen, dan met de energie die je spaart. Het klinkt onnatuurlijk maar kijk eens deze video:
YouTube: Why NOT to ZONE Heat Pumps! or boilers.. (SURPRISING RESULTS!!)

Eerst wou ik het ook automatiseren maar nu staan de vloerverwarming hier eigenlijk standaard aan en past de warmte pomp zijn output hier op aan.

Voor andere verwarming systemen geld dat dan weer niet echt.

Interessant punt dit.

Ik heb zelf twee aan/uit-bodemwarmtepompen (een Nibe F1145 uit 2011 en een IVT Greenline D5 uit ca. 2007 die we een paar jaar geleden als tweedehandsje hebben geïnstalleerd). Bij een aan/uit-warmtepomp is he sowieso een wat grotere uitdaging om de warmte kwijt te kunnen. Met een 'domme' zone-regeling kun je het probleem krijgen dat de compressor aansluit en terwijl er dat moment maar een paar groepen open staan. De warmtepomp kan zijn warmte niet kwijt, drijft de aanvoertemperatuur snel op (lager rendement), dumpt nog wat warmte in het buffervat en gaat dan weer uit.

Ik heb had in mijn temperatuurregeling al de mogelijkheid gebouwd voor drie temperatuursetpoints (comfort, eco en nachtverlaging). Dit gaat op basis van een schedule of de mogelijkheid om de comforttemperatuur te forceren. Die misbruik ik nu om de comfortmodus (setpoint 0,5 ℃ hoger dan de eco-temperatuur) aan te zetten zodra de compressor loopt. Het zorgt ervoor dat er meer groepen open staan als de WP gaat draaien en als de WP uit is wordt de warmte uit het buffervat zoveel ingezet voor de ruimtes die een warmtetekort hebben. De compressor loopt langer en de aanvoertemperatuur is lager.

De woning is een woonboerderij met een vakantieappartement waarvan de temperatuur aan de hand van de brekingsagenda wordt gestuurd. Vanwege de oriëntatie ten opzichte van de zon zijn er ook grote verschillen in opwarming van ruimtes door zoninstraling. Zoneregeling is noodzakelijk om de temperatuur goed te sturen.

Ik wil de aansturing nog een keer reactoren zodat de samenwerking met de WP beter geregeld wordt en ook de sturing op dynamische energieprijzen. Ik blokkeer nu simpelweg de verwarming in de duurste uren maar er moet nog wat slimmigheid in komen om extra warmte te bufferen in de goedkoopste uren en voordat de afschakeling in de dure uren intreedt.

[MichVw]

MichVw schreef op donderdag 7 december 2023 @ 09:18:
[...]


ja hoor, ik heb Eberle TS ultra+ aangeschaft. Past er mooi op en 24V dus kan meteen op output PLC aangesloten worden

Ik heb wat pech met m'n zoneventielen, alhoewel de datasheet zegt dat 24V DC moet lukken is er geen beweging in te krijgen.. Iemand die 24V DC zoneventielen kan aanraden die wel werken?

[KoBolD54]

MichVw schreef op dinsdag 27 februari 2024 @ 16:56:
[...]


Ik heb wat pech met m'n zoneventielen, alhoewel de datasheet zegt dat 24V DC moet lukken is er geen beweging in te krijgen.. Iemand die 24V DC zoneventielen kan aanraden die wel werken?

Is misschien het aantal ampere dat ze nodig hebben hoger dan geleverd kan worden door jou voeding? Zo heb ik ooit een waterklep gehad die zonder waterdruk prima werkte met weinig ampere maar eenmaal op de waterleiding aangesloten deed hij niets meer. Na het vervangen van de voeding door een exemplaar met meer amperes werkte het prima.

[joostboot]

Welk type heb je? Kleppen met een thermische motor kunnen best wat minuten nodig hebben om in beweging te komen.

[MichVw]

KoBolD54 schreef op dinsdag 27 februari 2024 @ 18:52:
[...]

Is misschien het aantal ampere dat ze nodig hebben hoger dan geleverd kan worden door jou voeding? Zo heb ik ooit een waterklep gehad die zonder waterdruk prima werkte met weinig ampere maar eenmaal op de waterleiding aangesloten deed hij niets meer. Na het vervangen van de voeding door een exemplaar met meer amperes werkte het prima.

Ik heb het ding rechtstreeks op de voeding gezet om te testen, nog altijd geen beweging..

[MichVw]

joostboot schreef op woensdag 28 februari 2024 @ 07:48:
Welk type heb je? Kleppen met een thermische motor kunnen best wat minuten nodig hebben om in beweging te komen.

Erlebe TS Ultra+ (24V). Ik zal nog eens testen met meer geduld.. 🙃. Klopt het ook dat ik echt niets kan horen?

[Kanze]

-

[ Voor 100% gewijzigd door Kanze op 28-02-2024 15:40 ]

[joostboot]

MichVw schreef op woensdag 28 februari 2024 @ 12:24:
[...]


Erlebe TS Ultra+ (24V). Ik zal nog eens testen met meer geduld.. 🙃. Klopt het ook dat ik echt niets kan horen?

Dat is een thermisch gedreven klep. Er zit een soort was in met een gloeispiraal. De was warmt langzaam op en zet uit. Dat drukt te klep open. Dat gaat dan dus helemaal geruisloos. Er zit geen elektromotor in ofzoiets.

Vaak kun je in de datasheet wel vinden hoe lang het moet duren. Ik meen van onze kleppen dat het 6 minuten was.

[joostboot]

Uit de datasheet: "Snelle aanspreektijd (opening van 4 mm in 2 minuten)"

[THM0]

Ik probeer al een tijdje het Codesys project van @MichVw op een Wago 8212 te deployen obv Codesys 3.5 (dus zonder eCockpit), maar loop steeds vast op errors bij het uploaden van de boot application naar de PLC.

De applicatie compileert gewoon zonder errors, maar ik krijg meldingen van "Unresolved reference: 'CODEMGETCONTENTBYFIRMCODE2' (en ook FIRMCODE3). Lijkt iets in de CmpCodeMeter library te zijn, die heb ik toegevoegd maar maakt geen verschil.


Die meldingen linken overigens nergens naar dus geen idee waar het probleem zit.

Wie weet raad? Ik draai eea op Codesys 3.5 SP19 patch 2 (de versie die Wago ondersteunt) maar heb ook de nieuwste geprobeerd. De PLC getest met firmwares 24 en 26, beide geven zelde resultaat...

[ Voor 28% gewijzigd door THM0 op 21-03-2024 20:19 ]

[Gunskes]

THM0 schreef op dinsdag 19 maart 2024 @ 22:34:
Ik probeer al een tijdje het Codesys project van @MichVw op een Wago 8212 te deployen obv Codesys 3.5 (dus zonder eCockpit), maar loop steeds vast op errors bij het uploaden van de boot application naar de PLC.

De applicatie compileert gewoon zonder errors, maar ik krijg meldingen van "Unresolved reference: 'CODEMGETCONTENTBYFIRMCODE2' (en ook FIRMCODE3). Lijkt iets in de CmpCodeMeter library te zijn, die heb ik toegevoegd maar maakt geen verschil.

[Afbeelding]
Die meldingen linken overigens nergens naar dus geen idee waar het probleem zit.

Wie weet raad? Ik draai eea op Codesys 3.5 SP19 patch 2 (de versie die Wago ondersteunt) maar heb ook de nieuwste geprobeerd. De PLC getest met firmwares 24 en 26, beide geven zelde resultaat...

In onderstaande link vind je 2 oplossingspistes, helpt dit voor jou?

https://forge.codesys.com/forge/talk/Runtime/thread/66d6ef1664/

[KoBolD54]

THM0 schreef op dinsdag 19 maart 2024 @ 22:34:
Ik probeer al een tijdje het Codesys project van @MichVw op een Wago 8212 te deployen obv Codesys 3.5 (dus zonder eCockpit), maar loop steeds vast op errors bij het uploaden van de boot application naar de PLC.

De applicatie compileert gewoon zonder errors, maar ik krijg meldingen van "Unresolved reference: 'CODEMGETCONTENTBYFIRMCODE2' (en ook FIRMCODE3). Lijkt iets in de CmpCodeMeter library te zijn, die heb ik toegevoegd maar maakt geen verschil.

[Afbeelding]
Die meldingen linken overigens nergens naar dus geen idee waar het probleem zit.

Wie weet raad? Ik draai eea op Codesys 3.5 SP19 patch 2 (de versie die Wago ondersteunt) maar heb ook de nieuwste geprobeerd. De PLC getest met firmwares 24 en 26, beide geven zelde resultaat...

Deze melding heb ik ook gehad toen ik van eCockpit naar Codesys overging. Het had inderdaad te maken met een library, welke weet ik alleen helaas niet meer precies. De libraries heb ik toen uit de eCockpit installatie gehaald

code:

C:\ProgramData\Wago Software\e!COCKPIT\CODESYS\Managed Libraries

[kuhlivisj]

Zorg ervoor dat bij de placeholders bij CmpCodeMeter niks ingevuld staat.



Zodra daar wel iets staat krijg je die foutmeldingen.

[THM0]

@KoBolD54 @kuhlivisj kunnen jullie wellicht een screenshot maken welke libraries en versies je in de Library Manager ziet?
Als ik de 3sLicense library eruit gooi krijg ik hem overgezet, maar dan zie ik weer foutmeldingen in de log dat de applicatie in Demo mode loopt omdat de licensie ontbreekt...

[THM0]

Nou inmiddels eindelijk werkend. Heb het volgende gedaan:

- Alle libraries van e!Cockpit gekopieerd naar een andere map per instructies van @KoBolD54
- e!Cockpit gedeïnstalleerd
- Codesys gedeïnstalleerd
- Alle resterende mappen van Codesys en e!Cockpit verwijderd uit Program Files \ ProgramData mappen
- Codesys opnieuw geinstalleerd, heb eea via Wago Download center gedownload (dan krijg je niet de laatste versie)
- Wago add-ons geinstalleerd via de Codesys installeer (je krijgt een set extra packages als je Codesys via Wago Download Center binnenhaalt, met daarin oa de Device types en Wago libraries)
- Nieuw "empty project" aangemaakt in Codesys. Github project geimporteerd en alles volgens de instructies uitgevoerd. Moest de library PlcServices uit de gekopieerde e!Cockpit libraries halen
- Heb de nieuwste versies van de MQTT en PRO_JSON libraries gebruikt (te vinden op Github)

[ Voor 17% gewijzigd door THM0 op 22-03-2024 22:11 ]

[MichVw]

THM0 schreef op dinsdag 19 maart 2024 @ 22:34:
Ik probeer al een tijdje het Codesys project van @MichVw op een Wago 8212 te deployen obv Codesys 3.5 (dus zonder eCockpit), maar loop steeds vast op errors bij het uploaden van de boot application naar de PLC.

De applicatie compileert gewoon zonder errors, maar ik krijg meldingen van "Unresolved reference: 'CODEMGETCONTENTBYFIRMCODE2' (en ook FIRMCODE3). Lijkt iets in de CmpCodeMeter library te zijn, die heb ik toegevoegd maar maakt geen verschil.

[Afbeelding]
Die meldingen linken overigens nergens naar dus geen idee waar het probleem zit.

Wie weet raad? Ik draai eea op Codesys 3.5 SP19 patch 2 (de versie die Wago ondersteunt) maar heb ook de nieuwste geprobeerd. De PLC getest met firmwares 24 en 26, beide geven zelde resultaat...

Ik moet deze topic nog eens goed bekijken.. weet er iemand of met pfc200 gen1 de omschakeling ook zou moeten lukken?

[TLDNL]

MichVw schreef op zaterdag 30 maart 2024 @ 13:47:
[...]


Ik moet deze topic nog eens goed bekijken.. weet er iemand of met pfc200 gen1 de omschakeling ook zou moeten lukken?

Volgens mij ondersteunt de Gen1 alleen e!Cockpit.

Maar zeker weten doe ik het niet.

[THM0]

TLDNL schreef op zaterdag 30 maart 2024 @ 14:21:
[...]


Volgens mij ondersteunt de Gen1 alleen e!Cockpit.

Maar zeker weten doe ik het niet.

Je kunt daar een Codesys runtime voor kopen in de store van Codesys en dan kun je hem programmeren met de standaard Codesys ontwikkelomgeving.

[TLDNL]

THM0 schreef op zaterdag 30 maart 2024 @ 14:55:
[...]

Je kunt daar een Codesys runtime voor kopen in de store van Codesys en dan kun je hem programmeren met de standaard Codesys ontwikkelomgeving.

Ah dan is dat het. Bij de Gen2 zit de Codesys runtime erin na een bepaalde firmware update.

[THM0]

TLDNL schreef op zaterdag 30 maart 2024 @ 14:58:
[...]


Ah dan is dat het. Bij de Gen2 zit de Codesys runtime erin na een bepaalde firmware update.

Klopt. Overigens is het licentiemodel van die betaalde runtime gewijzigd naar een prijs afhankelijk van de complexiteit van de applicatie. Wellicht nog wel interessant om te kijken of de benodigde licentie voor het project van @MichVw een schappelijke prijs heeft?

https://store.codesys.com/en/howto_applicationbasedlicenses

En hier vind je de benodigde runtime: https://store.codesys.com...trol-for-pfc200-sl-1.html

[ Voor 8% gewijzigd door THM0 op 30-03-2024 15:13 ]

[MichVw]

THM0 schreef op zaterdag 30 maart 2024 @ 15:06:
[...]

Klopt. Overigens is het licentiemodel van die betaalde runtime gewijzigd naar een prijs afhankelijk van de complexiteit van de applicatie. Wellicht nog wel interessant om te kijken of de benodigde licentie voor het project van @MichVw een schappelijke prijs heeft?

https://store.codesys.com/en/howto_applicationbasedlicenses

En hier vind je de benodigde runtime: https://store.codesys.com...trol-for-pfc200-sl-1.html

Ahn 🙃. Dus eigenlijk is gewoon de runtime gratis bij de gen2 en bij gen1 betalen. Alle Wago libs voor bv Dali zouden moeten blijven werken?

Eigenlijk verandert er dan weinig als ik het zo bedenk. Het was vroeger ook te betalen om codesys te gebruiken op de gen1 toestellen.

Het nieuwe licentie model lijkt me inderdaad interessant, als ik m’n code compile dan kom ik aan 1.5MB maar er zit vrij veel in. Kan voor andere mensen minder zijn waarschijnlijk.

[THM0]

MichVw schreef op zaterdag 30 maart 2024 @ 15:18:
[...]


Ahn 🙃. Dus eigenlijk is gewoon de runtime gratis bij de gen2 en bij gen1 betalen. Alle Wago libs voor bv Dali zouden moeten blijven werken?

Eigenlijk verandert er dan weinig als ik het zo bedenk. Het was vroeger ook te betalen om codesys te gebruiken op de gen1 toestellen.

Het nieuwe licentie model lijkt me inderdaad interessant, als ik m’n code compile dan kom ik aan 1.5MB maar er zit vrij veel in. Kan voor andere mensen minder zijn waarschijnlijk.

Wago biedt nu de libraries aan als download package inderdaad, precies hetzelfde als je met de 8212 doet. Muv aankopen van de runtime zou het echt exact hetzelfde moeten zijn volgens mij ja.
Ik heb echter mijn 8202 verkocht en een 8212 gekocht met nagenoeg gesloten beurs dus ik ga het niet kunnen testen. :-)

[EPLK]

Geweldig topic! Op dit moment ben ik bezig mijn 'nieuwe' jaren 70 woning volledig te strippen. Alles behalve de muren en het dak wordt vernieuwd, dus ook alle elektra. Graag maak ik van de mogelijkheid gebruik om alles (ten minste potentieel) slim te maken en natuurlijk het liefst bedraad en ik heb reeds een mooie 8212 op de kop weten te tikken.
Van de 'ster manier' van bedraden ben ik echter geen fan. Als ik iedere deur, raam, stopcontact, lichtpunt, schakelaar, etc. potentieel slim wil maken, moeten er dan al snel 10 of meer buizen per kamer naar de meterkast en als ik ooit zou besluiten nog een extra kamer op zolder toe te voegen, komen daar weer 10 extra buizen bij die allemaal op één of andere manier het hele huis door moeten.
De oplossing die ik heb bedacht is om op iedere kamer een klein kastje met een klein stukje din rail te maken waar 4 buizen binnenkomen: één voor elektriciteit, één voor een ethernetkabel, één voor een 24 aderige signaalkabel en een loze leiding voor de toekomstbestendigheid. Dit kastje fungeert dan als centraaldoos, als knooppunt/laspunt voor de signaaldraden van de sensoren op die kamer, maar ook als behuizing van alle relais en dergelijke die op die kamer dienst doen. Deze kunnen dan via de signaalkabel door de centrale plc worden aangestuurd. Vanuit dit kastje vertrekken dan weer alle buizen naar sensoren, lichtpunten, stopcontacten, etc. op die kamer.
Behalve dat ik op iedere kamer een plek voor zo'n kastje moet vinden, zie ik eigenlijk alleen maar voordelen aan dit systeem, maar wellicht zie ik iets over het hoofd. Bij deze dus de vraag: ziet iemand problemen waar ik tegenaan zou kunnen lopen als ik mijn bedrading op deze manier aanpak?

[deWit]

Dat het niet mag?

230V afmonteren in een centraaldoos met ook utp en signaal vraagt wel wat aan scheiding van de systemen. Logisch want je wil niet per ongelijk 230v op je utp krijgen omdat er een draad los raakt... Dus netjes met kokers in de kast werken, en dan word het kastje wat je voor ogen hebt opeens weer best een unit...

[EPLK]

Uiteraard moet alles in dat kastje netjes gedaan worden; ik zat te denken aan twee centraaldoosachtige constructies erin, één onderin voor 24v en één bovenin voor 230v, een stukje din rail ertussen en ernaast een soort verdeelsectie voor uitgangen waar die utp kabel ook binnen kan komen en een uitgang kan kiezen. Het ontwerp is nog niet af, maar het hoeft volgens mij niet een enorm ding te worden. Zo'n 30cm hoog, 30cm breed en 10cm diep?

[THM0]

EPLK schreef op zondag 31 maart 2024 @ 22:21:
Uiteraard moet alles in dat kastje netjes gedaan worden; ik zat te denken aan twee centraaldoosachtige constructies erin, één onderin voor 24v en één bovenin voor 230v, een stukje din rail ertussen en ernaast een soort verdeelsectie voor uitgangen waar die utp kabel ook binnen kan komen en een uitgang kan kiezen. Het ontwerp is nog niet af, maar het hoeft volgens mij niet een enorm ding te worden. Zo'n 30cm hoog, 30cm breed en 10cm diep?

Je kunt ook naar KNX kijken, dan kun je alles gewoon vertakken onderling. Schakelaars etc wel aan de prijs maar ook enorm betrouwbaar omdat alles ook autonoom werkt als de centrale controller wegvalt (afhankelijk van hoe je het programmeert natuurlijk).
Signaal mag bij 230V in dezelfde buis als je de juiste kabel neemt.

[EPLK]

THM0 schreef op maandag 1 april 2024 @ 11:10:
[...]

Je kunt ook naar KNX kijken, dan kun je alles gewoon vertakken onderling. Schakelaars etc wel aan de prijs maar ook enorm betrouwbaar omdat alles ook autonoom werkt als de centrale controller wegvalt (afhankelijk van hoe je het programmeert natuurlijk).
Signaal mag bij 230V in dezelfde buis als je de juiste kabel neemt.

Ja, een bus systeem zou natuurlijk eigenlijk het meest ideaal zijn, maar bij KNX worden de kosten toch wat te hoog. Bovendien beperkt het de mogelijkheden van zelf knutselen: een sensor die 0-10 volt op een draad zet, is (voor mij) nogal wat makkelijker te maken dan iets dat een correcte message op de bus zet. Vandaar dat de plc oplossing me toch het meest trekt.

[Kanze]

EPLK schreef op zondag 31 maart 2024 @ 21:24:
Geweldig topic! Op dit moment ben ik bezig mijn 'nieuwe' jaren 70 woning volledig te strippen. Alles behalve de muren en het dak wordt vernieuwd, dus ook alle elektra. Graag maak ik van de mogelijkheid gebruik om alles (ten minste potentieel) slim te maken en natuurlijk het liefst bedraad en ik heb reeds een mooie 8212 op de kop weten te tikken.
Van de 'ster manier' van bedraden ben ik echter geen fan. Als ik iedere deur, raam, stopcontact, lichtpunt, schakelaar, etc. potentieel slim wil maken, moeten er dan al snel 10 of meer buizen per kamer naar de meterkast en als ik ooit zou besluiten nog een extra kamer op zolder toe te voegen, komen daar weer 10 extra buizen bij die allemaal op één of andere manier het hele huis door moeten.
De oplossing die ik heb bedacht is om op iedere kamer een klein kastje met een klein stukje din rail te maken waar 4 buizen binnenkomen: één voor elektriciteit, één voor een ethernetkabel, één voor een 24 aderige signaalkabel en een loze leiding voor de toekomstbestendigheid. Dit kastje fungeert dan als centraaldoos, als knooppunt/laspunt voor de signaaldraden van de sensoren op die kamer, maar ook als behuizing van alle relais en dergelijke die op die kamer dienst doen. Deze kunnen dan via de signaalkabel door de centrale plc worden aangestuurd. Vanuit dit kastje vertrekken dan weer alle buizen naar sensoren, lichtpunten, stopcontacten, etc. op die kamer.
Behalve dat ik op iedere kamer een plek voor zo'n kastje moet vinden, zie ik eigenlijk alleen maar voordelen aan dit systeem, maar wellicht zie ik iets over het hoofd. Bij deze dus de vraag: ziet iemand problemen waar ik tegenaan zou kunnen lopen als ik mijn bedrading op deze manier aanpak?

Lijkt me nodeloos complexiteit inbouwen. In fabrieken is dit een logische manier van aanpakken omdat het vaak over honderden meters gaat tussen de inkomende aansluiting en centrale sturing en de lokale waar iets geschakeld moet worden. In een gewoon woonhuis heeft dit geen nut.

Wil je toch kabels reduceren kan je verstandig werken met signaalkabels. Bijvoorbeeld 1 stuurkabel met 16 of 24 aders per kamer die je vervolgens langs al je sensors door lust. Maar ook dat introduceert weer complexiteit.

Er is een reden waarom nagenoeg elke elektrische installateur in 2024 is afgestapt van het klassieke systeem (of de centraaldozen in NL). Een ster is op alle vlakken efficiënter.

[EPLK]

Kanze schreef op donderdag 4 april 2024 @ 13:56:
[...]

Lijkt me nodeloos complexiteit inbouwen. In fabrieken is dit een logische manier van aanpakken omdat het vaak over honderden meters gaat tussen de inkomende aansluiting en centrale sturing en de lokale waar iets geschakeld moet worden. In een gewoon woonhuis heeft dit geen nut.

Wil je toch kabels reduceren kan je verstandig werken met signaalkabels. Bijvoorbeeld 1 stuurkabel met 16 of 24 aders per kamer die je vervolgens langs al je sensors door lust. Maar ook dat introduceert weer complexiteit.

Er is een reden waarom nagenoeg elke elektrische installateur in 2024 is afgestapt van het klassieke systeem (of de centraaldozen in NL). Een ster is op alle vlakken efficiënter.

De complexiteit zal inderdaad iets toenemen, maar naar mijn mening niet nodeloos. Wat ik ermee hoop te bereiken is:

• Gotere flexibiliteit, omdat het makkelijker is om later een keer een nieuwe buis of draad te leggen vanaf een lokaal (in dezelfde kamer) kastje, dan helemaal naar de meterkast en/of stuurruimte.
• Ruimte besparen, vooral in de stuurruimte, maar ook in wanden en plafonds, want minder buizen nodig. Bij een renovatieproject zoals dat van mij, is het soms echt wel puzzelen hoe je alles netjes weggewerkt krijgt.
• Geld (en tijd) besparen, want bedrading is ook best duur en een slimme zolderkamer heeft toch al snel 100 meter extra buis en 300 meter extra draad nodig met het ster systeem.

Ik bestrijd dus dat een ster op alle vlakken efficiënter is en betwijfel ook sterk of die manier van werken de voorkeur heeft van een significant percentage installateurs boven het centraaldozensysteem.

[meijer3]

De ster is effectief, als het precies midden in je huis is.

Dus bij 3 verdiepingen en/of groot huis, kan ik me voorstellen dat het niet optimaal is. Het is ook de vraag hoeveel in/outputs je hebt per kamer. Het simpelste is natuurlijk lampje+schakelaar, maar je kan helemaal los. met natuurlijk meerdere schakelaars, meerdere lampen, screens, bewegingsensors, camera's, allerij input sensoren, verwarming ventilatie regelinstalaties. Ik heb nu in mijn badkamer 10 buizen. (oa. spiegel verwarming, 2 lampen, 3 schakelaars, input sensors). Dit is een renovatie project dus daar loop ik daar echt tegen aan.
Ik deel wel je gedachtes. Volgens mij zijn er verschillende systemen. Centraal (ster), bus (KNX) en decentraal waar je per deel van het huis het regelt, bijvoorbeeld je zolder apart. Enige na deel is dat je dan waarschijnlijk 4x PLC nodig hebt, die 3x onnodig stroom trekt.

[bartvb]

Hier in huis hebben we drie schakelkasten met zo'n 50 tot 70 PVC buizen per schakelkast en een tuinberging. In de woning zijn wel een aantal zaken zoals bewegingsmelders (KNX) en speakers doorgelust om in ieder geval een paar buizen te besparen

Mijn plan was om behoorlijk wat met PLCs te doen, maar uiteindelijk ben ik nogal afgeknapt op Codesys. Het voelt bijzonder 'vintage' en het is echt een compleet andere manier van programmeren dan ik gewend ben. Op zich prima voor wat simpel spul (KNX aan SMI zonwering koppelen b.v.) maar heel veel complexer ga ik dat niet maken.

De PLCs gebruik ik voor dat soort koppelingen en als een goedkope manier om b.v. deur- en raamcontacten te gebruiken. Maar achteraf had ik daar iets meer euro's tegenaan moeten gooien voor een KNX oplossing, dat had me heel veel uur prutsen met Codesys bespaart Maakt het ook makkelijker om het huis te verkopen als de basis draait op KNX ipv PLCs met custom code.

In mijn geval betekenen vier schakelkasten ook vier PLCs, maar anders was het niet te doen geweest. 120 buizen in één kast is niet grappig en het wordt daar ook niet overzichtelijker door. Een alternatief is de buizen van een verdieping uit laten komen in een (kleine) kast zonder actieve componenten en van daaruit met twee kabelgoten (230V en de rest) door gaan naar een kast waar je alles aan elkaar knoopt.

[ Voor 4% gewijzigd door bartvb op 10-04-2024 12:45 ]

[Femme]

Ik gebruik de PLC's alleen voor de I/O via modbus en MQTT. Codesys (2.3 in mijn geval wat voelt alsof je 30 jaar terug de tijd in gaat) trek ik niet en voor mij niet platform-onafhankelijk genoeg.

Ik heb her in der in huis kleinere kasjes (o.a. bij de vloerverwarmingsventielen en AC-onderverdelers) waar stuurkabels binnenkomen voor relais, bewegingssensoren en deurknoppen. Je zou het per verdieping kunnen doen. Het is goedkoper om 24-aderige SVV-kabel te trekken dan heel veel meters aan VD-draad. Maak zo'n kast niet te klein anders werk je je snel klem qua uitbreidingsruimte.

[joostboot]

Wij gebruiken ook PLC <-> MQTT <-> Homeassistant. Naast de moeilijke bekabeling blijf je ook altijd afhankelijk van een centrale verwerking. Zeker met complexe en/of oude software gecombineerd met doe-het-zelf-servers enz. is dat toch foutgevoeliger dan je denkt. Meer dan eens heb ik in het donker gestaan daardoor. Ook het itteratief werken is lastig. Elke program update haalt (tijdeljik) je hele huis plat.

Voor mij zou de heilige graal een decentraal, bekabeld, breed-ondersteund DIY systeem zijn. Kleine modules a la ESPHome die vie een bus met elkaar praten. Een IP-converter voor de koppeling met HA. Een gestandaardiseerd objectmodel die op projectbasis uit te breiden is. Apparaten die rechtstreeks op elkaars topics/resources kunnen subscriben. Remote configuratie... Wat is het toch mooi om te dromen.

[THM0]

joostboot schreef op woensdag 10 april 2024 @ 23:17:
Wij gebruiken ook PLC <-> MQTT <-> Homeassistant. Naast de moeilijke bekabeling blijf je ook altijd afhankelijk van een centrale verwerking. Zeker met complexe en/of oude software gecombineerd met doe-het-zelf-servers enz. is dat toch foutgevoeliger dan je denkt. Meer dan eens heb ik in het donker gestaan daardoor. Ook het itteratief werken is lastig. Elke program update haalt (tijdeljik) je hele huis plat.

Voor mij zou de heilige graal een decentraal, bekabeld, breed-ondersteund DIY systeem zijn. Kleine modules a la ESPHome die vie een bus met elkaar praten. Een IP-converter voor de koppeling met HA. Een gestandaardiseerd objectmodel die op projectbasis uit te breiden is. Apparaten die rechtstreeks op elkaars topics/resources kunnen subscriben. Remote configuratie... Wat is het toch mooi om te dromen.

Nou KNX komt aardig in de buurt…

[Kanze]

EPLK schreef op dinsdag 9 april 2024 @ 22:10:
[...]


De complexiteit zal inderdaad iets toenemen, maar naar mijn mening niet nodeloos. Wat ik ermee hoop te bereiken is:

• Gotere flexibiliteit, omdat het makkelijker is om later een keer een nieuwe buis of draad te leggen vanaf een lokaal (in dezelfde kamer) kastje, dan helemaal naar de meterkast en/of stuurruimte.
• Ruimte besparen, vooral in de stuurruimte, maar ook in wanden en plafonds, want minder buizen nodig. Bij een renovatieproject zoals dat van mij, is het soms echt wel puzzelen hoe je alles netjes weggewerkt krijgt.
• Geld (en tijd) besparen, want bedrading is ook best duur en een slimme zolderkamer heeft toch al snel 100 meter extra buis en 300 meter extra draad nodig met het ster systeem.

Ik bestrijd dus dat een ster op alle vlakken efficiënter is en betwijfel ook sterk of die manier van werken de voorkeur heeft van een significant percentage installateurs boven het centraaldozensysteem.

Het staat je vrij te doen wat je zelf wil hoor! Daar heb ik geen probleem mee. Ik geef alleen maar mee dat deze manier van werken niet courant meer is in de installatiewereld in België net omdat het nodeloos complex wordt.

De voordelen die je opsomt zijn effectief voordelen op schaal. Het kan zeer zinvol zijn om zo te werken in bedrijfsruimtes of fabrieken. Op die plaatsen moet de installatie vaak snel (en gemakkelijk) aan te passen zijn aan nieuwe noden en vereisten. Dat is niet het geval in een woonhuis. Het is zeer onwaarschijnlijk dat je na afwerking van je huis dan weer een hele vloer in een kamer zal gaan openbreken om ergens een nieuwe sensor te plaatsen. Na afwerking wordt meestal met draadloze oplossingen gewerkt net om die reden.

Ik betwist ook dat je op deze manier tijd zal uitsparen. De complexiteit van al die extra verdeelkasten gaat niet opwegen tegen een paar extra buizen over hetzelfde traject trekken. Je zal al die kasten bovendien conform moeten wegwerken in elke kamer wat esthetisch problemen geeft.

Ik denk dat mensen zich soms blindstaren op de kostprijs van extra bedrading en denken daar op te kunnen besparen met creatieve of slimme oplossingen.

Hoe dan ook veel succes met je project en kom zeker terug posten over je ervaringen!

[Kanze]

joostboot schreef op woensdag 10 april 2024 @ 23:17:
Wij gebruiken ook PLC <-> MQTT <-> Homeassistant. Naast de moeilijke bekabeling blijf je ook altijd afhankelijk van een centrale verwerking. Zeker met complexe en/of oude software gecombineerd met doe-het-zelf-servers enz. is dat toch foutgevoeliger dan je denkt. Meer dan eens heb ik in het donker gestaan daardoor. Ook het itteratief werken is lastig. Elke program update haalt (tijdeljik) je hele huis plat.

Voor mij zou de heilige graal een decentraal, bekabeld, breed-ondersteund DIY systeem zijn. Kleine modules a la ESPHome die vie een bus met elkaar praten. Een IP-converter voor de koppeling met HA. Een gestandaardiseerd objectmodel die op projectbasis uit te breiden is. Apparaten die rechtstreeks op elkaars topics/resources kunnen subscriben. Remote configuratie... Wat is het toch mooi om te dromen.

De problemen die je opsomt hebben helaas hoofdzakelijk te maken met je eigen implementatie, vrees ik. Wij gebruiken ook de tanden PLC, MQTT, Home Assistant en dat loopt als een trein.

Maar je moet wel de basisfuncties programmeren in de PLC zelf. De opstelling die @Femme gebruikt doet dat niet als ik me goed herinner. Zo stel je jezelf bloot aan problemen in Home Assistant of equivalent softwarepakket.

Als je in je PLC de basisfuncties van je huis hebt zitten (lichtknoppen en relais) blijft alles mooi werken wanneer er in je slimme softwarepakket zich een probleem voor doet.

[joostboot]

Kanze schreef op vrijdag 12 april 2024 @ 09:35:
[...]


De problemen die je opsomt hebben helaas hoofdzakelijk te maken met je eigen implementatie, vrees ik. Wij gebruiken ook de tanden PLC, MQTT, Home Assistant en dat loopt als een trein.

Maar je moet wel de basisfuncties programmeren in de PLC zelf. De opstelling die @Femme gebruikt doet dat niet als ik me goed herinner. Zo stel je jezelf bloot aan problemen in Home Assistant of equivalent softwarepakket.

Als je in je PLC de basisfuncties van je huis hebt zitten (lichtknoppen en relais) blijft alles mooi werken wanneer er in je slimme softwarepakket zich een probleem voor doet.

Wat je zegt over mijn setup en aanpak klopt ook wel.

Alleen loop je toch vrij snel tegen limitaties aan in de PLC-programmering. Je bent gelimiteerd in het aantal opties (packages) en de wijze van programmering (software). Kleine aanpassingen hebben daardoor veel voet in de aarde. Dat (veel? aanname) gebruikers al snel naar andere tools grijpen voor een betere ervaring bij het programmeren van hun domotica, toont dat alleen maar aan.

En door volledig op je PLC te vertrouwen stel je je weer bloot aan andere zaken. Na de aanpassingen liepen we tegen een vreemde melding aan in de PLC waardoor hij de cycle niet meer vol kon houden voor het MQTT gedeelte. Een fout die ik op Google niet kon achterhalen en niet kon verklaren. De PLC crashte daadwerkelijk, dus dan werkt niet alleen je sensorverlichting niet meer, maar staat álles stil: verwarming, verlichting, ventilatie, zonnewering. Dus alles resetten, backup project terugzetten...

[BlackShadow]

Zie hier regelmatig clips rond draden zitten als label/nummering. Er zijn veel soorten te vinden en mogelijk ook kwaliteitsverschil.

Met welke van die clips hebben jullie goede ervaring?

[Kanze]

joostboot schreef op vrijdag 12 april 2024 @ 10:59:
[...]


Wat je zegt over mijn setup en aanpak klopt ook wel.

Alleen loop je toch vrij snel tegen limitaties aan in de PLC-programmering. Je bent gelimiteerd in het aantal opties (packages) en de wijze van programmering (software). Kleine aanpassingen hebben daardoor veel voet in de aarde. Dat (veel? aanname) gebruikers al snel naar andere tools grijpen voor een betere ervaring bij het programmeren van hun domotica, toont dat alleen maar aan.

En door volledig op je PLC te vertrouwen stel je je weer bloot aan andere zaken. Na de aanpassingen liepen we tegen een vreemde melding aan in de PLC waardoor hij de cycle niet meer vol kon houden voor het MQTT gedeelte. Een fout die ik op Google niet kon achterhalen en niet kon verklaren. De PLC crashte daadwerkelijk, dus dan werkt niet alleen je sensorverlichting niet meer, maar staat álles stil: verwarming, verlichting, ventilatie, zonnewering. Dus alles resetten, backup project terugzetten...

In principe is er geen verschil tussen een opstelling met PLC's, MQTT. en HA aan de ene kant en een opstelling met het populaire Loxone aan de andere kant. Bij een opstelling met PLC's kan je zien hoe de worst gemaakt wordt. Maar al die lagen van abstractie zijn evenzeer aanwezig bij Loxone. Alleen heb je er daar geen toegang toe.

Ik zie dat dus niet echt als een limitatie. Bij het oplossing van complexe logica moet je de juiste abstractielaag aanspreken. Bij PLC's is dat jouw verantwoordelijkheid. Bij Loxone geeft de fabrikant je enkel toegang tot de toplaag en kiest het op voorhand welke interne abstractielagen beschikbaar zijn en dicteert dat dus ook de opties in de toplaag.

Ik heb hier ooit eens een uitgebreide post over geschreven maar het komt er voor mij op neer dat Domotica met PLC's een werk van liefde is. De verschillende moeilijkheden en de énorm steile leercurve zijn daar een onderdeel van. Het is naar mijn mening eerst aan de eindgebruiker om de juiste keuze te maken voor PLC's of een commerciële oplossing zoals Loxone.

Het is gek om dit te zeggen in het topic over domotica met PLC's maar ik denk dat voor heel wat mensen een oplossing zoals Loxono veel beter is. Voor wie op zoek is naar meer dan een werkende installatie maar ook graag dieper inzicht en kennis wil in (industriële) elektrotechniek en programmatie zijn PLC's dan weer een goede optie.

Het is misschien ook het vermelden waard dat de initiële post van Femme de PLC reduceert tot een doorgeefluik. Dat is absoluut een werkbare optie. Maar het maskeert misschien ook dat het programmeren van extra functies in codesys voor veel (nieuwe) programmeurs geen eitje is en dat je eigenlijk absoluut wat ervaring in C nodig hebt voor je aan dit soort project begint.

[THM0]

Kanze schreef op zaterdag 13 april 2024 @ 09:37:
[...]


In principe is er geen verschil tussen een opstelling met PLC's, MQTT. en HA aan de ene kant en een opstelling met het populaire Loxone aan de andere kant. Bij een opstelling met PLC's kan je zien hoe de worst gemaakt wordt. Maar al die lagen van abstractie zijn evenzeer aanwezig bij Loxone. Alleen heb je er daar geen toegang toe.

Ik zie dat dus niet echt als een limitatie. Bij het oplossing van complexe logica moet je de juiste abstractielaag aanspreken. Bij PLC's is dat jouw verantwoordelijkheid. Bij Loxone geeft de fabrikant je enkel toegang tot de toplaag en kiest het op voorhand welke interne abstractielagen beschikbaar zijn en dicteert dat dus ook de opties in de toplaag.

Ik heb hier ooit eens een uitgebreide post over geschreven maar het komt er voor mij op neer dat Domotica met PLC's een werk van liefde is. De verschillende moeilijkheden en de énorm steile leercurve zijn daar een onderdeel van. Het is naar mijn mening eerst aan de eindgebruiker om de juiste keuze te maken voor PLC's of een commerciële oplossing zoals Loxone.

Het is gek om dit te zeggen in het topic over domotica met PLC's maar ik denk dat voor heel wat mensen een oplossing zoals Loxono veel beter is. Voor wie op zoek is naar meer dan een werkende installatie maar ook graag dieper inzicht en kennis wil in (industriële) elektrotechniek en programmatie zijn PLC's dan weer een goede optie.

Het is misschien ook het vermelden waard dat de initiële post van Femme de PLC reduceert tot een doorgeefluik. Dat is absoluut een werkbare optie. Maar het maskeert misschien ook dat het programmeren van extra functies in codesys voor veel (nieuwe) programmeurs geen eitje is en dat je eigenlijk absoluut wat ervaring in C nodig hebt voor je aan dit soort project begint.

Dan zou ik eerder KNX overwegen, Loxone is ook niet bepaald goedkoop als je het vergelijkt met een PLC met standaard pulsdrukkers etc. Dan heb je bij KNX nog een zekere mate van vendor onafhankelijkheid plus de mogelijkheid van survivability’ als je centrale controller uitvalt.

[Giblet]

BlackShadow schreef op vrijdag 12 april 2024 @ 22:50:
Zie hier regelmatig clips rond draden zitten als label/nummering. Er zijn veel soorten te vinden en mogelijk ook kwaliteitsverschil.

Met welke van die clips hebben jullie goede ervaring?

Ik heb toevallig recent dit nog afgerond. Ik heb gekozen voor deze labelprinter: https://www.brother.nl/labels-en-bonnen/pt-p710bth en daarin dan krimpkous te kopen (HSe-221). Deze krimpkous kun je overigens voor veel schappelijkere prijzen vinden bij de bekende chinese websites
Deze specifieke labelprinter kun je ook gebruiken in combinatie met de desktop software welke veel meer mogelijkheden biedt dan de app-based software.

Ik ben daar supertevreden mee

[BlackShadow]

Giblet schreef op maandag 15 april 2024 @ 09:50:
[...]

Ik heb toevallig recent dit nog afgerond. Ik heb gekozen voor deze labelprinter: https://www.brother.nl/labels-en-bonnen/pt-p710bth en daarin dan krimpkous te kopen (HSe-221). Deze krimpkous kun je overigens voor veel schappelijkere prijzen vinden bij de bekende chinese websites
Deze specifieke labelprinter kun je ook gebruiken in combinatie met de desktop software welke veel meer mogelijkheden biedt dan de app-based software.

Ik ben daar supertevreden mee

Wist niet dat dit bestond, dat lijkt mij inderdaad een zeer handige oplossing en bovendien betaalbaar.
Heb je toevallig enkele foto's van het resultaat rond kleine draden/aders, 1,5mm² en kleiner.

[Roekeloos]

M.b.t. topologie: al eens eerder gedeeld geloof ik, maar wat voor mij goed werkte is een ster/ring combinatie. Natuurlijk een buis per schakelaar/lichtpunt. Maar alle wcd's binnen een kamer lus ik door met fase/nul/aarde/schakeldraad. Dit maakt het mogelijk om per wcd te kiezen of je hem op de fase zet of geschakeld (bijv. op een dimmer voor de schemerlampen). In mijn geval heb ik vaak groepjes van 2, waarbij er één vast is en de ander geschakeld (deze draai ik dan ook nog 90gr om te voorkomen dat je met de stofzuiger de dimmer opblaast). Dit geeft mij (meer dan) voldoende flexbiliteit, zonder de noodzaak van subkasten per ruimte of (erger nog) centraaldozen.

[meijer3]

@Roekeloos, dat is een leuk concept wat ik ga mee nemen!
Hoewel ik niet verwacht dat je snel wisselt tussen geschakelt en niet denk ik? De vuistregel is als ik het goed onthouden had om 4 WCD per groep te hebben gaat dan niet echt op toch? We hebben geen grootverbruikers en geen gourmet feesten , dus zal we mee vallen in praktijk.

Vraag voor iedereen: Hoe denken jullie na over de status van dit moois als je je huis wilt verkopen? Alles er weer uit?

[Roekeloos]

meijer3 schreef op vrijdag 19 april 2024 @ 10:53:
@Roekeloos, dat is een leuk concept wat ik ga mee nemen!
Hoewel ik niet verwacht dat je snel wisselt tussen geschakelt en niet denk ik? De vuistregel is als ik het goed onthouden had om 4 WCD per groep te hebben gaat dan niet echt op toch? We hebben geen grootverbruikers en geen gourmet feesten , dus zal we mee vallen in praktijk.

Vraag voor iedereen: Hoe denken jullie na over de status van dit moois als je je huis wilt verkopen? Alles er weer uit?

Ik heb geloof ik 60 WCD's; dan zou ik alleen daarvoor al 15 groepen moeten hebben? Volgensmij geldt die NEN1010 regel alleen als je heel weinig groepen hebt.

Verder zeer goed om vooraf na te denken over hoe terug te bouwen bij verkoop. Ik heb bedacht om dan "teleruptoren" (impulsschakelaars) in de kasten te zetten. Eigenlijk zoals huizen in België regelmatig worden opgeleverd (zodat dit later omgebouwd kan worden naar "echte" domotica.

[mauritso]

Ik heb zojuist na een aardige strijd HomeAutomation.CoDeSys3 werkend op mijn Wago PFC 750-8212, kan nu een lampje op de PLC schakelen van home assistant

De strijd:
1. Windows 10 VM opzetten want ik heb verder geen windows
2. Draaide voor geen meter in virtualbox op mijn intel macbook (wel eerder gedaan, toen ging het beter, jaren terug).
3. Windows 10 VM opzetten op een linux host, met kvm en virt-manager, draait nu als een trein via microsoft remote desktop.
4. Uitvogelen hoe het zit met de wago codesys licentie die er al bij moeten zitten om niet te hoeven te betalen voor codesys pfc200 targets.
5. Instructies van HomeAutomation.CoDeSys3 proberen te volgen, paar pogingen gedaan, uiteindelijk met de wago codesys en libs/targets gekomen bij een punt dat hij compiled maar toen gaf hij een error. IO er met kbus scan in gegooid en met de hand de inputs/outputs variabel namen gegeven.
6. Overschakelen naar codesys targets, dan moest ik opnieuw de IO er in zetten.
7. Toen maar terug naar de save game van stap 5 en de originele wago firmware/plc runtime weer geflashed.
8. Dit bleek de gouden tip: kuhlivisj in "Domotica met plc's"
9. In wezen werkend, zag data op mqtt, wat dingen er uit gehaald die ik nog niet nodig heb
10. homeassistant autodiscovery werkte ook en ik kon een ledje op een output module toggelen vanuit home assistant.

Bedankt @MichVw en @kuhlivisj

[Kanze]

Hoe zit dat met die Wago Codesys licentie op de pfc200 G2reeks? Is dat een volwaardige Codesys lice Tie zonder beperkingen?

Als je een licentie wil kopen van Codesys voor een G1 PLC moet je in dat getrapte systeem stappen en daar heb ik geen zin in.

[mauritso]

Kanze schreef op zondag 1 september 2024 @ 15:37:
Hoe zit dat met die Wago Codesys licentie op de pfc200 G2reeks? Is dat een volwaardige Codesys lice Tie zonder beperkingen?

Als je een licentie wil kopen van Codesys voor een G1 PLC moet je in dat getrapte systeem stappen en daar heb ik geen zin in.

Voor zover ik kan zien is dat zo, heb 24 uur+ het project draaiend gehad dus denk niet dat er een runtime limitatie is.

[Kanze]

mauritso schreef op zondag 1 september 2024 @ 15:41:
[...]


Voor zover ik kan zien is dat zo, heb 24 uur+ het project draaiend gehad dus denk niet dat er een runtime limitatie is.

Ik bedoel eerder limitatief in functionaliteit. Ze noemen het Application-Based licensing. Natuurlijk een manier om meer geld uit mensen te slaan.

[mauritso]

Zal volgende keer nog even kijken maar niets van gezien of gemerkt, ik vermoed niet van toepassing. Er worden geen codesys geleverde device targets gebruikt en de codesys runtime zelf levert wago.

[ Voor 32% gewijzigd door mauritso op 02-09-2024 00:31 ]

[THM0]

mauritso schreef op maandag 2 september 2024 @ 00:30:
Zal volgende keer nog even kijken maar niets van gezien of gemerkt, ik vermoed niet van toepassing. Er worden geen codesys geleverde device targets gebruikt en de codesys runtime zelf levert wago.

Zo begrijp ik het ook. Als je voor bijv de G1 PFC200 een Codesys runtime koopt krijg je hier wel mee te maken.

[MichVw]

Bijna een eeuwigheid geleden maar ik heb deze week eindelijk wat tijd gevonden om wat updates te pushen naar m'n repo en een nieuwe release te maken:

https://github.com/Michie...eSys3/releases/tag/v1.4.0

voor v1.5.0 zou ik al m'n climate function blocks willen toevoegen, daarna beginnen aan de omzet van éCockpit naar CodeSys..

Ik had nog een vraagje; zijn er mensen die wat meer kennen van het hele 'assistant' gedoe in Home Assistant? (spraak of via chat). Ik heb ergens opgevangen dat het sterk gebruik maakt van areas/ruimtes, is dit correct of kan het ook werken met labels?

Reden waarom ik het vraag is dat de huidige MQTT discovery logica in het project alle entiteiten publiceerd onder één toestel. En je kan maar op toestel niveau een ruimte toewijzen, niet op entiteit niveau.
Als het echt een must is voor dat gedeelte van Home Assistant te ondersteunen moet ik inkijken om de mogelijkheid te ondersteunen om voor iedere instantie van een function block een uniek toestel aan te maken via MQTT discovery...

[KoBolD54]

MichVw schreef op donderdag 17 oktober 2024 @ 17:15:
Bijna een eeuwigheid geleden maar ik heb deze week eindelijk wat tijd gevonden om wat updates te pushen naar m'n repo en een nieuwe release te maken:

https://github.com/Michie...eSys3/releases/tag/v1.4.0

voor v1.5.0 zou ik al m'n climate function blocks willen toevoegen, daarna beginnen aan de omzet van éCockpit naar CodeSys..

Ik had nog een vraagje; zijn er mensen die wat meer kennen van het hele 'assistant' gedoe in Home Assistant? (spraak of via chat). Ik heb ergens opgevangen dat het sterk gebruik maakt van areas/ruimtes, is dit correct of kan het ook werken met labels?

Reden waarom ik het vraag is dat de huidige MQTT discovery logica in het project alle entiteiten publiceerd onder één toestel. En je kan maar op toestel niveau een ruimte toewijzen, niet op entiteit niveau.
Als het echt een must is voor dat gedeelte van Home Assistant te ondersteunen moet ik inkijken om de mogelijkheid te ondersteunen om voor iedere instantie van een function block een uniek toestel aan te maken via MQTT discovery...

Als eerste, bedankt voor je werk van deze release.

Bij de release die ik op dit moment van jou draai is het ook zo dat bij default alle entiteiten in één area zitten. Echter kan je dit aanpassen. Zo heb ik verschillende entiteit vanuit mijn PLC toegekend aan andere area's. Dit heb ik gedaan door naar de entiteit te gaan en bij instellingen "Use device area" uit te schakelen. Daarna kan je een andere area kiezen.

[Rob Z]

BlackShadow schreef op vrijdag 12 april 2024 @ 22:50:
Zie hier regelmatig clips rond draden zitten als label/nummering. Er zijn veel soorten te vinden en mogelijk ook kwaliteitsverschil.

Met welke van die clips hebben jullie goede ervaring?

Voor kabels (ook netwerk) gebruik ik beschrijfbare trekbandlabels met een label van 25x8 mm

[MichVw]

ik heb de laatste tijd nogal wat problemen met Esera. Hun nieuwe sensoren werken niet op de gateway 10 en hun support is niet echt behulpzaam..

Dus terug naar het tekenbord, ik heb Esera altijd een 'gokje' gevonden, het is tenslotte een kleine speler in een niche markt. niet te vergelijken met een Wago bijvoorbeeld.

Wat lijken jullie de opties (of wat doen jullie) om sensorwaarden binnen te halen in de PLC met doel om HVAC toepassingen te gaan doen? Ergens ben ik op zoek naar een oplossing van een grote speler met een open protocol waarmee de PLC kan interfacen.

KNX lijkt een optie maar het prijskaartje is navenant per thermostaat. Hou er ook rekening mee dat ideaal gezien er ook vochtigheid of CO2 niveaus zouden moeten kunnen gemeten worden.

Esera 1-Wire naar modbus was het beste wat ik kon vinden maar misschien mis ik iets..

[Wafje]

MichVw schreef op zondag 3 november 2024 @ 18:55:
ik heb de laatste tijd nogal wat problemen met Esera. Hun nieuwe sensoren werken niet op de gateway 10 en hun support is niet echt behulpzaam..

Dus terug naar het tekenbord, ik heb Esera altijd een 'gokje' gevonden, het is tenslotte een kleine speler in een niche markt. niet te vergelijken met een Wago bijvoorbeeld.

Wat lijken jullie de opties (of wat doen jullie) om sensorwaarden binnen te halen in de PLC met doel om HVAC toepassingen te gaan doen? Ergens ben ik op zoek naar een oplossing van een grote speler met een open protocol waarmee de PLC kan interfacen.

KNX lijkt een optie maar het prijskaartje is navenant per thermostaat. Hou er ook rekening mee dat ideaal gezien er ook vochtigheid of CO2 niveaus zouden moeten kunnen gemeten worden.

Esera 1-Wire naar modbus was het beste wat ik kon vinden maar misschien mis ik iets..

Ik voorzie op dit moment KNX waar we temperatuur en vochtigheid willen meten. In ruimtes waar enkel temperatuur van belang is steek ik een NTC sensor achter de drukknoppen, aangesloten naar de PLC via multikabel (in ster dus). Ik heb iets minder vertrouwen in 1wire op lange afstanden.

[Femme]

Wafje schreef op zondag 3 november 2024 @ 23:42:
[...]

Ik voorzie op dit moment KNX waar we temperatuur en vochtigheid willen meten. In ruimtes waar enkel temperatuur van belang is steek ik een NTC sensor achter de drukknoppen, aangesloten naar de PLC via multikabel (in ster dus). Ik heb iets minder vertrouwen in 1wire op lange afstanden.

Ik gebruik nu ongeveer tien jaar 1-wire in een netwerk met 16 sensoren in lijntopologie. Het bussignaal gaat via dezelfde utp-kabel terug van de sensor naar een rijgklem in de verdeelkast en door naar de volgende sensor. Nul issues gehad na installatie van de sensoren.

In een ander netwerk had ik nog wat meer sensoren maar zijn er een paar uitgevallen omdat er een sensorkabel door een samenloop van omstandigheden was aangevreten door een ezel en de andere onderdompeling in een poel niet had overleeft (was bedoeld om watertemperatuur te meten van voor een horizontale bodemcollector). Geen tijd gehad om dit te fixen maar de sensoren die voor de breuk in de buslijn op de bus zitten doen het nog gewoon.

[thomke]

ik heb mijn PLC project ondertussen bijna 4jaar stabiel draaien
vele dank aan @MichVw voor het vele werk en goede uitleg!

ondertussen zijn er heel wat 'inputs' en 'outputs' bij gekomen.
waardoor het overzicht wat zoek was.

En in die 4 jaar tijd zijn ook heel wat uitbreidingen en updates bijgekomen (zoals de MQTT discovery, dmx, ...) die ik nooit toegepast heb.
(altijd met de oorspronkelijke versie van blokken/bibliotheken blijven werken)

daarom dacht ik van eens helemaal opnieuw te beginnen (dus compleet nieuw project, met het idee wel veel te kunnen copy pasten zoals mijn 'Pushbuttons' en 'Switches'

Maar bij het importeren/downloaden van de 'labraries' krijg ik 2 bibliotheken niet goed:



Ik vermoed dat ik zonder die bibliotheken kan zolang ik de DMX functionaliteit niet gebruik als ik het goed heb... (nu zit mijn DMX rechstreeks in HomeAssistant, maar zou ook overwegen dit via de PLC te doen als dit zou werken..)

voor mensen die DALI / RS485 willen gebruiken zullen die bibliotheken ook nodig zijn vermoed ik?

[MichVw]

thomke schreef op zaterdag 23 november 2024 @ 22:43:
ik heb mijn PLC project ondertussen bijna 4jaar stabiel draaien
vele dank aan @MichVw voor het vele werk en goede uitleg!

ondertussen zijn er heel wat 'inputs' en 'outputs' bij gekomen.
waardoor het overzicht wat zoek was.

En in die 4 jaar tijd zijn ook heel wat uitbreidingen en updates bijgekomen (zoals de MQTT discovery, dmx, ...) die ik nooit toegepast heb.
(altijd met de oorspronkelijke versie van blokken/bibliotheken blijven werken)

daarom dacht ik van eens helemaal opnieuw te beginnen (dus compleet nieuw project, met het idee wel veel te kunnen copy pasten zoals mijn 'Pushbuttons' en 'Switches'

Maar bij het importeren/downloaden van de 'labraries' krijg ik 2 bibliotheken niet goed:
[Afbeelding]


Ik vermoed dat ik zonder die bibliotheken kan zolang ik de DMX functionaliteit niet gebruik als ik het goed heb... (nu zit mijn DMX rechstreeks in HomeAssistant, maar zou ook overwegen dit via de PLC te doen als dit zou werken..)

voor mensen die DALI / RS485 willen gebruiken zullen die bibliotheken ook nodig zijn vermoed ik?

Die libraries gaan niet automatisch downloaden. Je vind ze terug in de ‘libraries’ folder in de git repo. Je hebt ze wel degelijk nodig..

Helaas bestaat er in de PLC wereld geen simpele manier om alles te updaten. Als ik volgend jaar de omschakeling maak naar Codesys ipv ecockpit zal het ook herbeginnen zijn.. Gelukkig met veel copy/paste 😉

[Santford]

MichVw schreef op zondag 24 november 2024 @ 19:44:
[...]


[…]
Helaas bestaat er in de PLC wereld geen simpele manier om alles te updaten. Als ik volgend jaar de omschakeling maak naar Codesys ipv ecockpit zal het ook herbeginnen zijn.. Gelukkig met veel copy/paste 😉

Een aantal platformen waarop je in structured text volgens de IEC 61131-3 standaard kunt programmeren biedt de mogelijkheid voor een in- en export via een PLCopen XML bestand.

Niet alle platformen ondersteunen alle functionaliteit uit de standaard, maar als je niet te fabrikant specifieke dingen doet kom je daar een heel eind mee om je code over te zetten.

https://plcopen.org/technical-activities/xml-exchange

Edit:
Zowel eCockpit als Codesys ondersteunen het exporteren en importeren van projecten via een xml-file:
https://techdocs.wago.com...KPIT/en-US/313355275.html

https://content.helpme-co...roject_export_import.html

[ Voor 15% gewijzigd door Santford op 24-11-2024 22:39 ]

[MichVw]

Santford schreef op zondag 24 november 2024 @ 20:23:
[...]

Een aantal platformen waarop je in structured text volgens de IEC 61131-3 standaard kunt programmeren biedt de mogelijkheid voor een in- en export via een PLCopen XML bestand.

Niet alle platformen ondersteunen alle functionaliteit uit de standaard, maar als je niet te fabrikant specifieke dingen doet kom je daar een heel eind mee om je code over te zetten.

https://plcopen.org/technical-activities/xml-exchange

Edit:
Zowel eCockpit als Codesys ondersteunen het exporteren en importeren van projecten via een xml-file:
https://techdocs.wago.com...KPIT/en-US/313355275.html

https://content.helpme-co...roject_export_import.html

Dat klopt. Er zit ook een export file in de repository. Maar kan toch nog beter 😉

[THM0]

MichVw schreef op maandag 25 november 2024 @ 20:42:
[...]


Dat klopt. Er zit ook een export file in de repository. Maar kan toch nog beter 😉

De Professional Developer versie van Codesys heeft een Git add-on.
Wel even EUR 550,-- ex BTW per jaar aftikken voor de licentie...

[Kanze]

Heeft iemand interesse in twee PFC200's van de eerste generatie? Ik overweeg een upgrade naar de tweede generatie. Het zijn een 750-8202 en een 750-8204 (incl CAN)

[mauritso]

Ik probeer een modbus netwerk op te zetten met HomeAutomation.CoDeSys3.

Met de volgende PLC: PFC200 / 750-8122 en een wago 750-652 RS-232/485 module in codesys 3.5.

Nou staat de module onder Kbus vermeld maar er staat maar 1 COM poort onder "serial" vermeld en ik zie niet hoe ik daar de poort van de 750-652 bij kan krijgen.

Iemand een idee? Heb ik Wago IO Check nodig om de kaart in te stellen?

EDIT: Ik heb onderhand via WAGO IO Check de modules gereset, maar ik heb nog niet genoeg aan de hint hieronder en wat er in de documentatie staat om het aan de praat te krijgen.

EDIT2: Verse import van HomeAutomation.CoDeSys3 maakt het wat duidelijker, ik zat tegen een lege RS485_RUN te kijken, dus ik kon de serial port initialization maar niet vinden.

[ Voor 34% gewijzigd door mauritso op 08-12-2024 12:25 ]

[Santford]

mauritso schreef op zaterdag 7 december 2024 @ 23:37:
Ik probeer een modbus netwerk op te zetten met HomeAutomation.CoDeSys3.

Met de volgende PLC: PFC200 / 750-8122 en een wago 750-652 RS-232/485 module in codesys 3.5.

Nou staat de module onder Kbus vermeld maar er staat maar 1 COM poort onder "serial" vermeld en ik zie niet hoe ik daar de poort van de 750-652 bij kan krijgen.

Iemand een idee? Heb ik Wago IO Check nodig om de kaart in te stellen?

Als ik het goed heb dan heb je daar de WagoAppCom library voor nodig en kun je vervolgens met de FbSerialInterface_cpt functiebouwsteen de seriële poort instellen en openen.

https://www.sps-forum.de/...zum-laufen-bringen.94425/

[Kanze]

mauritso schreef op zaterdag 7 december 2024 @ 23:37:
Ik probeer een modbus netwerk op te zetten met HomeAutomation.CoDeSys3.

Met de volgende PLC: PFC200 / 750-8122 en een wago 750-652 RS-232/485 module in codesys 3.5.

Nou staat de module onder Kbus vermeld maar er staat maar 1 COM poort onder "serial" vermeld en ik zie niet hoe ik daar de poort van de 750-652 bij kan krijgen.

Iemand een idee? Heb ik Wago IO Check nodig om de kaart in te stellen?

EDIT: Ik heb onderhand via WAGO IO Check de modules gereset, maar ik heb nog niet genoeg aan de hint hieronder en wat er in de documentatie staat om het aan de praat te krijgen.

EDIT2: Verse import van HomeAutomation.CoDeSys3 maakt het wat duidelijker, ik zat tegen een lege RS485_RUN te kijken, dus ik kon de serial port initialization maar niet vinden.

Een Modbus interface opzetten en laten werken gaat in twee stappen.

1. Declareer de modbus master

code:

PROGRAM PRG_MODBUS_652
VAR
    (* Link Layer execution of Read and Write Commands *)
    ModbusMaster        : WagoAppPlcModbus.FbMbMasterSerial := (
                                            xConnect    := TRUE,
                                            udiBaudrate := 9600,
                                            usiDataBits := 8,
                                            eParity     := WagoTypesCom.eTTYParity.None,
                                            eStopBits   := WagoTypesCom.eTTYStopBits.One,
                                            eHandshake  := WagoTypesCom.eTTYHandshake.None,
                                            ePhysical   := WagoTypesCom.eTTYPhysicalLayer.RS485_HalfDuplex,
                                            eFrameType  := eMbFrameType.RTU,
                                            tTimeOut    := T#500MS
                                          );
END_VAR

2. Call die master FB in elke cycle

code:

(* Link layer execution *)
ModbusMaster(
    I_Port := IoConfig_Globals.RS232_485_Interface,
    utQuery:= MasterQuery,
    xTrigger := xTrigger,
    utResponse:= MasterResponse
    );

De `I_Port` parameter is waar je je pointer naar je 750-652 interface opgeeft. Gebruik je COM1 dan zou die daar staan. De naam van je interface komt uit IoConfig_Globals. Die kan je hier aanpassen als je dat wil.




Belangrijk: De Wago modbus master doet alleen maar de basis send-en-receive functies. Je hebt een controller FB nodig die je modbus netwerk voor je beheert. Die doet dan de timing voor het uitlezen en aansturen van je modbus slaves

[ Voor 4% gewijzigd door Kanze op 09-12-2024 10:00 ]

[MichVw]

mauritso schreef op zaterdag 7 december 2024 @ 23:37:
Ik probeer een modbus netwerk op te zetten met HomeAutomation.CoDeSys3.

Met de volgende PLC: PFC200 / 750-8122 en een wago 750-652 RS-232/485 module in codesys 3.5.

Nou staat de module onder Kbus vermeld maar er staat maar 1 COM poort onder "serial" vermeld en ik zie niet hoe ik daar de poort van de 750-652 bij kan krijgen.

Iemand een idee? Heb ik Wago IO Check nodig om de kaart in te stellen?

EDIT: Ik heb onderhand via WAGO IO Check de modules gereset, maar ik heb nog niet genoeg aan de hint hieronder en wat er in de documentatie staat om het aan de praat te krijgen.

EDIT2: Verse import van HomeAutomation.CoDeSys3 maakt het wat duidelijker, ik zat tegen een lege RS485_RUN te kijken, dus ik kon de serial port initialization maar niet vinden.

dit zijn enkele tips die ik kreeg van een gebruiker die ook even geworsteld heeft met een externe module:
https://github.com/Michie...dicated-wago-rs485-module

[Kanze]

Heb twee PFC200'S G2 op de kop kunnen tikken voor 470 euro het stuk. Die dingen komen wel in prijs naar beneden precies.

éCockpit doet wat het moet doen maar je merkt wel dat de interface van native codesys een stuk reponsiever werkt. Volgende week eens kijken of een dropin replacement gewoon werkt zoals het hoort.

Het kriebelt om een nieuwe guide te schrijven voor beginners maar het ontbreekt zoals altijd aan tijd

[Kanze]

Inhoudtafel

0. Inleiding
1. PLC Basis
2. PLC's van Wago
3. Basisopstelling

0. Inleiding

Een gerichte handleiding om een domotica-systeem op te zetten met de hulp van een WAGO PLC in een woonhuis. Ik schrijf hoofdzakelijk over wat essentieel is en probeer de lezer zo veel mogelijk (verloren) tijd te besparen. Als je ergens op vastloopt kom dan zeker posten.

1. PLC Basis

1.1 Overzicht

PLC's (Programmable Logic Controllers) zijn compacte computers die in elektrische kasten op een DIN-rail geplaatst kunnen worden. Normaal leven ze in fabrieken maar ze kunnen net zo goed je woonhuis aansturen.

Een PLC heeft Ingangen, Uitgangen, Serieële poort(en), en netwerkconnectiviteit. Dat zijn de hardwarefuncties. De software die gebruik maakt van die hardwarefuncties kan je zelf programmeren.

De PLC heeft alle capabiliteiten om je woonhuis aan te sturen. Sommige commerciële domoticasystem zijn trouwens gewoon PLC's in vermomming.

2. PLC's van Wago

2.1 Waarom Wago?

1. Beschikbaarheid en Prijs. Wago is een Duits merk waardoor hun PLC's goed voorradig zijn op de Europese markt. Omdat PLC's industrieel materiaal zijn leert de ervaring bovendien dat ze tweedehands zeer betrouwbaar zijn. Met name de Duitse eBay en alternatieven zijn een goede plaats om aan scherpe prijzen de nodige harware aan te kopen.

2. Softwarepakket. Om je PLC te programmeren heb je een softwarepakket van Wago nodig. De PLC beschikt reeds over een hardwarelicentie voor dat pakket. Je hoeft dus geen dure software aan te kopen. Dit is ongebruikelijk in de wereld van industrieële automatisatie en dus een groot voordeel.

### 2.2 Hardware

We focussen op de modellen Wago PFC200 G1, en Wago PFC200 G2, of nieuwer. Generaties G1 en G2 zijn onderverdeeld in een reeks submodellen. De basisversie van elke generatie is reeds overkill voor je woonhuis. De andere submodellen beschikken over speciale thermische of chemische hardeningen en extra industrieële communicatieprotocollen. Geen van die dingen hebben we nodig in een woonhuis.

1. PFC200 G1 model 750-8202
2. PFC200 G2 model 750-8212
3. (optioneel) PFC300

Als je een ander model kiest let erop dat het een RS232/485 seriële poort ingebouwd heeft.

2.2.1 PFC200

Een PFC200 PLC-systeem bestaat uit 2 onderdelen:

- De Controller (CPU) is het brein van je installatie. Hierop draait de programmatie die je zelf geschreven hebt.
- De Veldbus (Fieldbus) is de interface (aansluitpunt) tussen de controller en je elektrische installatie.

De controller + veldbus op de foto hierboven is al redelijk volledig. Deze elementen zullen ook in jouw installatie zeker aan bod komen:

1. Ingebouwde seriële poort (COM1) voor RS232 en RS485. Het Modbus protocol gebruik RS485 voor signalisatie
2. Twee ethernet poorten (X1/X2). X1 voor aansluiting met het thuisnetwerk. X2 voor koppeling met een andere controller.
3. LED's voor debugging
4. SD-kaart slot voor updates (G1)
5. Status schakelaar
6. Serial-USB poort. Met een speciale USB-kabel (zie 2.3) kan bij netwerkstoring nog geprogrammeerd worden.
8. Controller built-in powersupply 24VDC
9. Redundante veldbus voeding
10. Digitale Ingangen 2-poort
11. Digitale Uitgangen 2-poort
12. Digitale Ingangen 16-poort
13. Veldbus eindmodule

We komen later uitgebreider terug op items 10 tot en met 13.

2.2.2 Digitale of Analoge Kaarten

Digitale kaarten zijn binaire systemen als in Aan of Uit. Analoge kaarten vertalen een stroomsterkte naar een analoog voltage. Dat wordt dan weer geïnterpreteert als een analoge waarde, bijvoorbeeld temperatuur. In deze handleiding gebruiken we geen analoge kaarten omdat ze zeer duur zijn.

Later gaan we sensoren koppelen aan onze PLC via Modbus. Die sensoren versturen hun meetwaarden naar de PLC als digitale waarden. Deze opstelling is goedkoper en kent heel weinig calibratieproblemen.

2.3 Software

Er zijn twee softwarepakketen. De keuze hangt af van de generatie.

1. PFC200 G1 gebruikt Wago e!Cockpit
2. PFC200 G2 gebruikt Wago Codesys
3. (optioneel) PFC300 gebruikt Wago Codesys

Codesys is een standaard IDE voor PLC's. Wago heeft lange tijd codesys gebruikt als de basis voor haar eigen IDE (Wago éCockpit). Bij de release van G2 is overgschakeld naar zuiver Codesys.

Beide softwarepakketen werken enkel op Windows. Linux of macOS gebruikers kunnen een virtual machine gebruiken. De programmatie van de PLC gaat via je thuisnetwerk. Koop ook de speciale Wago usb-naar-serieel kabel die je direct aansluit op een Windows computer en de PLC.

1. Wago Serial-USB Cable

2.3.1 e!Cockpit (G1)

Zonder een activatiesleutel werkt Wago e!Cockpit voor 30 gebruiksdagen. Dat zijn geen kalenderdagen. Gebruik e!cockpit in een virtual machine die je kan resetten. De evaluatiemodus is 100% functioneel.

Update je installatie van e!Cockpit 1.11.2.0 naar 1.11.3.1! Er is een CVE ontdekt in een hulpprogramma wat bij versie 1.11.2.0 mee geïnstalleerd wordt. Dit probleem is verholpen ins 1.11.3.1

De installatie van e!Cockpit installeert ook:

1. WAGO I/O Check
2. WAGO Ethernet Settings

2.3.2 Firmware (G1)

Firmware voor G1 staan op Wago's Github

Voor de update-procedure volg je dit filmpje:

Installeer in e!Cockpit dezelfde firmwareversie als op je PFC200!

2.3.3 Codesys

Wago Codesys heeft geen activatiesleutel of evaluatiemodus.

De installatie van Wago Codesys installeert ook Wago Navigator. Een soort Wago App Store. Vanuit Wago Navigator installeer je nu:

1. WAGO I/O Check
2. WAGO Ethernet Settings

2.3.4 Firmware (G2)

Firmware voor G2 staan op Wago's Download Center of Wago Navigator

Firmware PFC is voor PFC200 G2

Voor de update-procedure volg je dit filmpje:

3.0 Basisopstelling

Dit is een basisopstelling voor een woonhuis:

1. PFC200 G2 750-8212
2. Digitale Inputkaart (8 ingangen) 750-430
3. Digitale Outputkaart (8 uitgangen) 750-530
4. (Optioneel) Seriële Multifunctionkaart (RS485 Modbus/DMX) 750-652
5. Veldbus Eindkaart 750-600



De seriële multifunctionkaart is optioneel omdat de 750-8212 controller een ingebouwde seriële poort heeft. Ik plaats ze erbij omdat zo bijkomende functies gedemonstreerd kunnen worden.

Draden aansluiten kan door met een platte schroevendraaien het springcontact in de vierkante gaten voorzichtig omhoog te duwen waardoor het klemcontact in het ronde gat eronder open gaat en je de draad kan aansluiten.

3.1 Wago Ethernet Settings & WBM

1. Met Wago Ethernet Settings lees je algemene gegevens uit van de PLC. Kies voor seriële communicatie (USB-kabel COM1) of TCP/IP (Netwerkaansluiting X1).





2. De PLC draait ook een web-based management (WMB) interface op het eigen IP adres. Hiermee kan je uitgebreider gegevens uitlezen en meer opties configureren. Noteer het paswoord wanneer je het aanpast want je hebt het later nodig om je programma te kunnnen uploaden uit e!cockpit of codesys

Default username: admin
Default password: wago

3.2 Wago I/O Check

1. Je logt met Wago I/O Check in op je PLC zoals je dat deed met Wago Ethernet Settings



2. Wago I/O Check toont je welke expansiekaarten door de PLC werden gedetecteerd. Merk op dat de schematische tekening exact gelijk is aan hoe de basisopstelling er uitziet.



3. Wago I/O Check in MONITOR-MODE geeft realtime de status van inputs en outputs aan. Als je ergens in huis een knop indruk die op een input is aangesloten zie je in I/O Check het corresponderende lampje op de expansiekaart aangaan. Handig tijdens de elektrische installatie.

(Voorbeeld van een andere PLC)


4. Wago I/O Check in CONTROL-MODE (Direct) geeft je realtime controle over outputs. Hier dwing ik alle 8 uitgangen van mijn expansiekaart hoog. Handig bij het testen van relais of andere schakelingen in je elektrische installatie




5. (Voorproevertje) Sommige expansiekaarten hebben speciale functies die je via I/O Check kan instellen. Deze 750-652 kan seriële data versturen én als DMX master functioneren. DMX is een protocol specifiek voor lichtbesturing.




Wago I/O Check is een handige tool om de basisfuncties van je PLC te testen zonder dat er een programma moet worden geschreven. Neem uitgebreid de tijd om hier wat in rond te klikken voor je verder gaat.

[ Voor 164% gewijzigd door Kanze op 15-01-2025 20:49 ]

[mjkl]

Giblet schreef op maandag 15 april 2024 @ 09:50:
[...]

Ik heb toevallig recent dit nog afgerond. Ik heb gekozen voor deze labelprinter: https://www.brother.nl/labels-en-bonnen/pt-p710bth en daarin dan krimpkous te kopen (HSe-221). Deze krimpkous kun je overigens voor veel schappelijkere prijzen vinden bij de bekende chinese websites
Deze specifieke labelprinter kun je ook gebruiken in combinatie met de desktop software welke veel meer mogelijkheden biedt dan de app-based software.

Ik ben daar supertevreden mee

Hier ben ik wel benieuwd naar, ik sta op het punt om een labelprinter te kopen. Ik kan echter nergens terugvinden dat de pt-p710bth heat shrink labels ondersteund. (de HSe-221) dus. Weet je zeker dat je naar de juiste printer linkt? @Giblet

Zo ja kan dat behoorlijk schelen, want de eerstvolgende printer die officieel HSe-221 ondersteunt, de PTP750WVP is 3x zo duur.

[Giblet]

mjkl schreef op dinsdag 31 december 2024 @ 00:38:
[...]


Hier ben ik wel benieuwd naar, ik sta op het punt om een labelprinter te kopen. Ik kan echter nergens terugvinden dat de pt-p710bth heat shrink labels ondersteund. (de HSe-221) dus. Weet je zeker dat je naar de juiste printer linkt? @Giblet

Zo ja kan dat behoorlijk schelen, want de eerstvolgende printer die officieel HSe-221 ondersteunt, de PTP750WVP is 3x zo duur.

Bij mij werkt het als een trein
Ik durf niet te zeggen of de originele brother krimpkousen erin werken, maar de chinese kloons die ik gebruik wel. Mogelijk zijn die behuizingen iets anders (dat werkt in beginsel vrij simpel, een aantal pinnen die wel of niet ingedrukt worden).

[mjkl]

Giblet schreef op dinsdag 31 december 2024 @ 15:39:
[...]

Bij mij werkt het als een trein
Ik durf niet te zeggen of de originele brother krimpkousen erin werken, maar de chinese kloons die ik gebruik wel. Mogelijk zijn die behuizingen iets anders (dat werkt in beginsel vrij simpel, een aantal pinnen die wel of niet ingedrukt worden).

We gaan het zien! ik heb de cube plus besteld en bij de bekende chinese webshop een 5 pack labels. Wel heb ik zelf de voorkeur voor zwart op geel.

Zowaar stond bij de listing dat de cube plus (pb710BT) idd ondersteund wordt. Maar wel voor de 24mm labels. Niet de 9mm wat de de HSe-221 (in zwart op wit) lijkt te zijn?

[TLDNL]

Ik ben even een testje aan het doen om een Esera Gateway-10 via een 750-352 en 750-653/003-000 uit te lezen. Echter lukt dit niet. Ik krijg een error in het owd device

Goed om te weten:
- Een 750-8212 is als master ingesteld en de 750-352 als slave (Modbus/TCP).
- Via de 750-352 en de 750-653/003-000 probeer ik dus de Esera Gateway-10 uit te lezen.
- Ik gebruik e!Cockpit
- Ik gebruik de HomeAutomation van Michel als basis
- De 750-653/003-000 is goed geconfigureerd en werkt naar behoren als die direct op de master PLC zit.
- De Esera gateway werkt ook naar behoren

Ik vermoed dat het in de volgende regels zit:

code:

module_aIn_2 : ARRAY[0..3] OF BYTE; 
module_aOut_1 : ARRAY[0..3] OF BYTE; 
IPort : WagoSysFieldbusModule.FbModule_75x_653 :=( PASizeInput := 4, PASizeOutput := 4);

Wie kan en wil mij verder helpen? Ik vermoed dat het iets heel stom kleins is, maar ik zie het even niet.

Dank vast!

[Kanze]

TLDNL schreef op woensdag 15 januari 2025 @ 14:37:
Ik ben even een testje aan het doen om een Esera Gateway-10 via een 750-352 en 750-653/003-000 uit te lezen. Echter lukt dit niet. Ik krijg een error in het owd device

Goed om te weten:
- Een 750-8212 is als master ingesteld en de 750-352 als slave (Modbus/TCP).
- Via de 750-352 en de 750-653/003-000 probeer ik dus de Esera Gateway-10 uit te lezen.
- Ik gebruik e!Cockpit
- Ik gebruik de HomeAutomation van Michel als basis
- De 750-653/003-000 is goed geconfigureerd en werkt naar behoren als die direct op de master PLC zit.
- De Esera gateway werkt ook naar behoren

Ik vermoed dat het in de volgende regels zit:

code:

module_aIn_2 : ARRAY[0..3] OF BYTE; 
module_aOut_1 : ARRAY[0..3] OF BYTE; 
IPort : WagoSysFieldbusModule.FbModule_75x_653 :=( PASizeInput := 4, PASizeOutput := 4);

Wie kan en wil mij verder helpen? Ik vermoed dat het iets heel stom kleins is, maar ik zie het even niet.

Dank vast!

Kan je een screenshot posten van de error die je krijgt?

[Rob Z]

@TLDNL Dus het werkt als je het Esera ding vanaf de 750-653 benadert?

[TLDNL]

Kanze schreef op woensdag 15 januari 2025 @ 16:51:
[...]
Kan je een screenshot posten van de error die je krijgt?

Ik zal morgen even screenshots maken. Maar het is het error bitje in het OWD device die actief word.

Rob Z schreef op woensdag 15 januari 2025 @ 17:06:
@TLDNL Dus het werkt als je het Esera ding vanaf de 750-653 benadert?

De 750-653 klem communiceert met de Esera gateway zolang deze verbonden is via de 750-8212 PLC. Maar niet via de 750-352 FC.

Waar ik ook nog achter kwam is dat als ik 2 RS485 masters heb (Een 750-653/003-000 zowel aan de master PLC als de 750-352 fieldbus connector) dat ik wel een temperatuur waarde binnen krijg.

[TLDNL]

Dank voor de reacties tot zover.

Hierbij de screenshots:

Fout: (zie het error bitje wat true word)


Netwerk:


Modbus Relatie:


Na het maken van de modbus relatie tussen de 750-8212 en de 750-352 worden er een aantal dingen aangemaakt:

- Global Variabel

code:

VAR_GLOBAL
    DK1_FC_tcp: typDK1_FC_tcp;
END_VAR

- TYPE 1

code:

TYPE typDK1_FC_tcp_FC_DK1_COM2:
    STRUCT
        module_aIn_2 : ARRAY[0..3] OF BYTE; 
        module_aOut_1 : ARRAY[0..3] OF BYTE; 
        IPort : WagoSysFieldbusModule.FbModule_75x_653 :=( PASizeInput := 3, PASizeOutput := 3); 
    END_STRUCT
END_TYPE

-TYPE 2

code:

TYPE typDK1_FC_tcp:
    STRUCT
        FC_DK1_COM2 : typDK1_FC_tcp_FC_DK1_COM2; 
    END_STRUCT
END_TYPE

- En een INIT PRG:

code:

PROGRAM DK1_FC_tcp_IPortInit
VAR
END_VAR

---------------------
(*generated code for slave DK1_FC_tcp for modules with available iport interface*)
(*Initialization code for slave module 'FC_DK1_COM2'*)
Modbus.DK1_FC_tcp.FC_DK1_COM2.IPort.SetNewPaInputs(ADR(Modbus.DK1_FC_tcp.FC_DK1_COM2.module_aIn_2),Modbus.DK1_FC_tcp.FC_DK1_COM2.IPort.PA_SIZE_INPUT);
Modbus.DK1_FC_tcp.FC_DK1_COM2.IPort.GetNewPaOutputs(ADR(Modbus.DK1_FC_tcp.FC_DK1_COM2.module_aOut_1),Modbus.DK1_FC_tcp.FC_DK1_COM2.IPort.PA_SIZE_OUTPUT);

Vervolgens draait de code uit de HomeAutomation van Michel:
- Variabelen:

code:

PROGRAM FC_PRG_RS485
VAR
    (* é!COCKPIT version*)
    
    ModbusMaster        : WagoAppPlcModbus.FbMbMasterSerial := (
                                            xConnect    := TRUE,
                                            udiBaudrate := 19200,
                                            usiDataBits := 8,
                                            eParity     := WagoTypesCom.eTTYParity.None,
                                            eStopBits   := WagoTypesCom.eTTYStopBits.One,
                                            eHandshake  := WagoTypesCom.eTTYHandshake.None,
                                            ePhysical   := WagoTypesCom.eTTYPhysicalLayer.RS485_HalfDuplex,
                                            eFrameType  := eMbFrameType.RTU,
                                            tTimeOut    := T#500MS);
                
    RtuQuery            : WagoAppPlcModbus.typMbQuery;
    RtuResponse         : WagoAppPlcModbus.typMbResponse;
    
    
    (* Shared variables for é!COCKPIT and CODESYS 3S Version *)
    Trigger             : BOOL:=FALSE;
    InitRS485           : BOOL:=FALSE;
    ActiveRtuQuery      : RS485_RtuQuery;
    RS485BusController : FB_RS485_BUSCONTROLLER;
        
    

    (* RS485 *)

    FB_RS485_ESERA_1WIRE_GATEWAY_MQTT_HOME : FB_RS485_ESERA_1WIRE_GATEWAY_MQTT;
    
END_VAR

- INIT Programma:

code:

IF NOT InitRS485 THEN
    InitRS485 := TRUE;

(* INIT RS485 BUS CONTROLLER; é!COCKPIT version *)
RS485BusController.Init(
    StartupDelay := T#5S,               (* Time to wait after startup to start using the bus, prevents boot delay issues when RS485 are not ready yet on startup *)     
    SilenceTime := T#50MS,              (* Silence time between two requests, important to not get faulty data on bus *)
    BusTrigger := ADR(Trigger),         (* Pointer to the bool used to initiate bus requests *)
    BusData := ADR(RtuResponse.awData), (* Pointer to the array containing the bus response data *)
    BusError := ADR(ModbusMaster.xError));(* Pointer to the bus error bool *)

RS485BusController.RegisterDevice(device := FB_RS485_ESERA_1WIRE_GATEWAY_MQTT_HOME);

FB_RS485_ESERA_1WIRE_GATEWAY_MQTT_HOME.InitRS485(
    DeviceAddress := 1);


FB_RS485_ESERA_1WIRE_GATEWAY_MQTT_HOME.EnableOwd(
    OwdNumber := 1,
    DataPollingInterval := T#2M);

END_IF

- RUN Programma:

code:

RtuQuery.bUnitId := RS485BusController.ActiveRtuQuery.DeviceId; 
RtuQuery.bFunctionCode := RS485BusController.ActiveRtuQuery.FunctionCode;   
RtuQuery.uiReadAddress := RS485BusController.ActiveRtuQuery.ReadAddress;    
RtuQuery.uiReadQuantity := RS485BusController.ActiveRtuQuery.ReadQuantity;
ModbusMaster(
    I_Port := modbus.DK1_FC_tcp.FC_DK1_COM2.IPort,
    utQuery:= RtuQuery,
    xTrigger := Trigger,
    utResponse:= RtuResponse);

//modbus.FC_DK1_COM2

(* Shared variables for é!COCKPIT and CODESYS 3S Version *)
RS485BusController();

(* RS485 devices *)
FB_RS485_ESERA_1WIRE_GATEWAY_MQTT_HOME();

Ik vermoed dus dat het in TYPE 1 misgaat. Maar ik zie het even niet. Ik hoop jullie wel?

[Kanze]

[b]TLDNL in "Domotica met plc's"**snip**

Ik zie dat de ModbusMaster hier specifiek naar een .IPort veld wordt verwezen bij die FB call.

code:

ModbusMaster(
    I_Port := modbus.DK1_FC_tcp.FC_DK1_COM2.IPort,
    utQuery:= RtuQuery,
    xTrigger := Trigger,
    utResponse:= RtuResponse);

In mijn eigen code geef ik de reference naar de gehele interface mee

code:

(* Link layer execution *)
ModbusMaster(
    I_Port := IoConfig_Globals.RS232_485_Interface, // Hier dus geen .IPport veld aangesproken
    utQuery:= MasterQuery,
    xTrigger := xTrigger,
    utResponse:= MasterResponse
    );

Kan je dat aanpassen? Ik heb geen ervaring met Modbuskaarten in een ethernet coupler.

[TLDNL]

Kanze schreef op donderdag 16 januari 2025 @ 18:26:
[...]


Ik zie dat de ModbusMaster hier specifiek naar een .IPort veld wordt verwezen bij die FB call.

code:

ModbusMaster(
    I_Port := modbus.DK1_FC_tcp.FC_DK1_COM2.IPort,
    utQuery:= RtuQuery,
    xTrigger := Trigger,
    utResponse:= RtuResponse);

In mijn eigen code geef ik de reference naar de gehele interface mee

code:

(* Link layer execution *)
ModbusMaster(
    I_Port := IoConfig_Globals.RS232_485_Interface, // Hier dus geen .IPport veld aangesproken
    utQuery:= MasterQuery,
    xTrigger := xTrigger,
    utResponse:= MasterResponse
    );

Kan je dat aanpassen? Ik heb geen ervaring met Modbuskaarten in een ethernet coupler.

Het laatste .IPort moet ik wel invullen anders compiled ie überhaupt niet.
De .IPort word aangemaakt in TYPE 1

code:

TYPE typDK1_FC_tcp_FC_DK1_COM2:
    STRUCT
        module_aIn_2 : ARRAY[0..3] OF BYTE; 
        module_aOut_1 : ARRAY[0..3] OF BYTE; 
        IPort : WagoSysFieldbusModule.FbModule_75x_653 :=( PASizeInput := 3, PASizeOutput := 3); 
    END_STRUCT
END_TYPE

Vandaar dat ik vermoed dat de gegeven instelling in dit TYPE niet correct is.

[Kanze]

Fraggar schreef op vrijdag 17 april 2020 @ 10:09:
[...]


P0: Deze poort gebruikt de monteur om lokaal gegevens uit de meter te halen.

P1: Deze poort heet de gebruikersinterface. Door het aansluiten van daarvoor geschikte apparatuur, kunt u gedetail- leerde informatie over uw energieverbruik uit de meter halen. Er zijn energieverbruiksmanagers zoals apps of slimme thermostaten te koop die u kunt verbinden met de slimme meter, waardoor u continu inzicht heeft in uw energieverbruik.

Aldus de handleiding van mijn slimme meter. Ik lees hem via een RPi ieder uur uit en sla de standen dan op in een database.

Ik haal even deze post eruit na een search op de term "P1" in onze thread.

Ik heb besloten dat het tijd is om mijn P1 meter aan te sluiten op mijn PLC. Bedoeling is die waarden dan door te publiceren via MQTT om ze te gebruiken in Home Assistant, onder meer voor de load balancing van onze laadpaal. De informatie online is redelijk schaars maar dit lijken twee goede bronnen te zijn:

https://jensd.be/1205/lin...ale-meter-met-de-p1-poort

https://github.com/lvzon/dsmr-p1-parser

Uit die tweede link haal ik deze hardware-oplossing:

Using an RS232-port (or a USB-RS232-converter) and a pull-up resistor. This is often the easiest solution, as this can be done without soldering, cheap USB RS232-converters are easy to find and you can add as many interfaces as you need (e.g. using multiple USB-devices or even a 4-port device based on an MCS7840 quad serial controller). The RS232 serial standard and the P1 standard both use an inverted serial signal, and altough the LOW voltage levels are technically incompatible (-15V to -3V for RS232, 0V to 1V for P1), most RS232-interfaces accept 0V as LOW and are able to decode the data transmitted by the P1-port without any problems. Just connect the signal ground of the two interfaces, and connect TXD on the P1-port to RXD on the RS232-interface. You will also still need to connect a 1-10 kOhm pull-up resistor between Vcc and the data line, and connect RTS on the P1-port to Vcc. You may also have to connect VccGND and GND.

Mijn initieel plan is om een dergelijk kabel zelf te maken en dan aan te sluiten op de PLC via COM1. Het uitlezen wil ik dan proberen met de library CAA SerialCom.

Voor ik begin: heeft iemand hier ervaring mee?

[Femme]

Kanze schreef op woensdag 5 februari 2025 @ 12:50:
[...]

Voor ik begin: heeft iemand hier ervaring mee?

Waarom via de plc uitlezen en de p1-poort niet direct aan je Home Assistent machientje hangen?

[Kanze]

Femme schreef op woensdag 5 februari 2025 @ 12:53:
[...]


Waarom via de plc uitlezen en de p1-poort niet direct aan je Home Assistent machientje hangen?

Mijn HA instance is een container op een server. Een fysieke connectie is niet mogelijk. Ik heb een kabel voorzien naar de PLC, én in zie het als een uitdaging om dat via de PLC te doen

[Rob Z]

@Kanze Hier een HA draaiend in docker en die ziet prima het P1 ding in de usb poort

[RedPas]

Kanze schreef op woensdag 5 februari 2025 @ 17:03:
[...]


Mijn HA instance is een container op een server. Een fysieke connectie is niet mogelijk. Ik heb een kabel voorzien naar de PLC, én in zie het als een uitdaging om dat via de PLC te doen

Als je het dan toch via je PLC wilt doen, koop de geschikte kaart voor je Wago.
3 Stroomtransfo's (CT klem) en hupla.

[KoBolD54]

RedPas schreef op donderdag 6 februari 2025 @ 07:45:
[...]


Als je het dan toch via je PLC wilt doen, koop de geschikte kaart voor je Wago.
3 Stroomtransfo's (CT klem) en hupla.

Of een meter kopen die modbus ondersteund en het op die manier in je PLC inbouwen. Dan kan je tevens de waarden sneller uitlezen dan via de P1.

[thomke]

Het probleem bij een meting is dat je veel andere relevante gegevens misloopt.

De P1-poort biedt aanzienlijk meer data die interessant kan zijn.

Zo is in België, met het capaciteitstarief, zowel je huidige kwartierpiek als je maandpiek van belang.

Ik doe het uitlezen van de P1 ook gewoon via HomeAssistant, via een wifi module, dan moet je niet zoeken naar hoe je het via USB uitgelezen moet krijgen in de docker. (verder lijkt het mij handiger om HomeAssistant als OS in een VM te draaien ipv docker container)

Dan zou je via mqtt misschien wel de informatie kunnen doorsturen naar de PLC, maar ik doe de regeling binnen HomeAssistant (nodered) zelf.

[Femme]

Met een modbusmeter zoals een Eastron SDM630 heb je ook alle relevante data.

Het zal vast kunnen, en p1-poort uitlezen via een PLC. Naast de fysieke communicatie moet je ook nog DSMR telegrammen gaan decoderen. Het is maar net hoeveel tijd je erin wil stoppen.

Je kunt het jezelf makkelijker maken door een p1 ethernet dongle te gebruiken die de data via MQTT en een REST API beschikbaar stelt:
https://smart-stuff.nl/pr...imme-meter-lezer/#reviews

[RedPas]

Femme schreef op donderdag 6 februari 2025 @ 12:17:
Met een modbusmeter zoals een Eastron SDM630 heb je ook alle relevante data.

Het zal vast kunnen, en p1-poort uitlezen via een PLC. Naast de fysieke communicatie moet je ook nog DSMR telegrammen gaan decoderen. Het is maar net hoeveel tijd je erin wil stoppen.

Je kunt het jezelf makkelijker maken door een p1 ethernet dongle te gebruiken die de data via MQTT en een REST API beschikbaar stelt:
https://smart-stuff.nl/pr...imme-meter-lezer/#reviews

Ik lees mn energie meter uit met de P1, na de meter zit een Schneider Iem 2150 modbus, en dan heb ik nog een smartpi met 3 CT klemmen.

Ja het maar hoeveel tijd je erin wil steken...

Oja de P1 is aangesloten op de SmartPi en die zend alles uit via mqtt.

De Schneider praat met ET 200 SP.
Home Assistant Energie Dashboard voor dagelijks gebruik. Grafana en Influx voor diepgaander onderzoek

[Kanze]

Ondertussen is het gelukt! Er zijn wel wat voordelen aan de P1 poort direct uitlezen ipv met een eigen meter. Je krijgt toegang tot meer data (Maandpiek, stroomonderbreking, dag&dal-uren, ...). Het is ook een zuivere seriële connectie zonder Modbus er bovenop. De meter heeft 1 seconde resolutie waar ik nu toegang toe heb en dat vind ik wel fijn. Als je een SDM630 aan die rate moet pollen hangt er best niets anders op die bus wat ietsofwat snel bereikbaar moet zijn.

De hardware setup is wat complexer als verwacht. Een RS232-connector op COM1 werkt niet op de PLC (maar wel op je home assistant met RS232-USB) omdat de PLC strikt RS232 voltages verwacht en die kan je nooit produceren met een 5V TTL output van je P1.

De oplossing was onderstaande logic-inverter bouwen en die te koppelen aan een MAX485. Dat alles past gelukkig mooi onder die groene kap van de meter dus valt verder niet op.



De PLC publiceert nu de gelezen waarden in MQTT om te gebruiken in HA.

Als er interesse voor is wil ik iets uitgebreider erover schrijven, laat maar weten

[Kanze]

P1-Poort lezen via Wago PLC

Doel

We willen een DSMR "slimme meter" uitlezen via de COM1 poort van een Wago PLC. De data van de meter kan dan gepubliceerd worden via MQTT.

DSMR

1. Bronmateriaal
   1. https://jensd.be/1205/linux/data-lezen-van-de-belgische-digitale-meter-met-de-p1-poort
   2. https://github.com/lvzon/dsmr-p1-parser
   3. https://domoticx.com/p1-poort-slimme-meter-uitlezen-hardware/
2. Er zijn verschillende versies van het DSMR protocol. De laatste versie (5.0.2) is al sinds 2016 van kracht. In België krijg je in principe een meter met versie 5.0.2. Oudere versies kunnen ook uitgelezen worden maar er zijn hardware verschillen.
3. Vanaf DSMR 4.0 zenden meters op de P1 poort elke second een ASCII bericht (Telegram) uit met alle gegevens. De gebruiker moet deze zelf weten uit te lezen en te verwerken.
4. Bij sommige netbeheerders (Bijvoorbeeld Fluvius in België) moet je P1 geactiveerd worden via een webportaal van de beheerder.

Hardware

Theorie

1. Er staat redelijk wat misinformatie over de P1 poort online. De poort gebruikt geen RS422 en ook geen RS232. Het is een 5V TTL Inverted Logic poort. Dat wil zeggen +V5 is False en GND is True
2. Met een PC kan je de poort direct uitlezen via een USB-RS232 kabel en enkele weerstanden. Meer uitleg hier.
3. Wago PLC's kunnen RS232 lezen en schrijven via hun COM1 poort maar verwachten voltages die strikt aan de RS232 specificatie voldoen (+15V tot +3V, en -3V tot -15V). Die kan de P1 poort nooit produceren via een RS232-RS232 kabel.
4. De oplossing is een signaalomvormer bouwen die de 5V TTL van de P1 poort flipt en via RS485 naar je PLC stuurt. Omdat we overstappen op RS485 is afstand niet meer van belang. RS485 werkt over honderden meters.

Praktijk

1. Dit is de weg die het signaal gaat afleggen
   
   
   code:
   

   P1 RJ12 -> Logic Inverter -> MAX485 -> PLC COM1

2. De P1 poort is een RJ12 (6P6C) connector. Je kan die zelf maken met een gewone UTP kabel waarvan je het laatste paar (bruin-wit) niet gebruikt. Ik raad aan om overal T568B aan te houden zodat pinnummer en aderkleuren altijd overeen komen.
3. Je kan een andere transistor kiezen zolang hij maar gelijkaardig is. ChatGPT geeft als voorbeelden de BC548, BC549, 2N2222, 2N3904, S8050.
4. De diodes zijn optioneel.
5. Dit is mijn versie. De rode connector is RS485 A en B. De Groene connector geeft inverter 5V TTL en GND
6. Aan de PLC zijde gebruik je een D-SUB connector waarmee je je RS485 aansluit op pinnen 3, 5, en 8, van de PLC. Zie de Wago documentatie.

Software

1. Data uitlezen doen we via de CAA SerialCom library. Deze heeft alleen ondersteuning voor COM1. Je kan dus helaas niet via een 750-652 of gelijkaardige kaart uitlezen tenzij je je eigen serial library ervoor schrijft.
2. Hier is een voorbeeld van hoe het uitlezen kan worden geïmplementeerd. Je moet eerst de poort initiëren en activeren, daarna kan je hem uitlezen. Mijn Belgische meter produceert Telegrammen van exact 1255 bytes. Omdat de stream ASCII is kan je de data die je wil gewoon per byteoffset uit die stream halen
3. Het programma hieronder is beta software maar geeft al een idee welke richting je uit kan gaan.

POU_SERIAL_COM1

code:

PROGRAM POU_SERIAL_COM1
VAR
    //Visu Variables
    xBtnClear       : BOOL := FALSE;
    xClearAll       : BOOL; // flag to clear all
    
    //Current State
    iState : INT := 0;

    (* Settings to communicate with the COM Port *)
    aCom1Params : ARRAY [1..7] OF COM.PARAMETER; 
    
    hCom    : CAA.HANDLE; (* handle of the port*)
    como1   : COM.Open;
    comc1   : COM.Close;
    comr1   : COM.Read; 
    
    sWrite  : STRING;
    szRead  : CAA.SIZE;
    uiRead  : UINT;
    
    bReadBuffer : ARRAY [1..10001] OF BYTE; (*Used to read data from the serial port*)
    sReadText   : STRING(10001);
    
    xReadSuccess    : BOOL;

    // errors
    xCom1OpenError  : BOOL;
    xCom1ReadError  : BOOL;
    iError          : INT;
    errRead         : INT;

    tTimer          : TON;
    DSMRPaser       : fbDSMRParser;
    MismatchCounter : UINT := 0;
    AlignTimer      : TON;
    AlignTime       : TIME := T#1000ms;
    bAligned        : BOOL;
    
    // sSend        : STRING(255);  // send message
    sStatus     : STRING(25);   // status message
    
    Received    :STRING(10001);
    intReceived :INT;
    iCnt        : INT;

    (* This PLC's MQTT prefix *)
    sMqttPrefix         : STRING(100) := 'pfc8204/';    
END_VAR

-----------------------------------------------------------

// COM_INIT

IF iState = 0 THEN
 // Init
    sStatus := 'INIT';
    iState:= 5; //Goto 5: Set Parameters    
    IF xClearAll THEN
        // reset errors
        POU_SERIAL_COM1.xCom1ReadError  := FALSE;
        //POU_SERIAL_TEST.xCom1WriteError := FALSE;
        POU_SERIAL_COM1.xCom1OpenError  := FALSE;           
        xClearAll := FALSE;
    END_IF
    
DSMRPaser.InitMqtt(MQTTPublishPrefix:= ADR(sMqttPrefix), pMqttPublishQueue := ADR(MqttVariables.fbMqttPublishQueue));
END_IF  

----------------------

// COM_ACTIVATE

    //Set COM port parameters
    IF iState = 5 THEN
            sStatus := 'Prepare';
            // port number
            aCom1Params[1].udiParameterId := COM.CAA_Parameter_Constants.udiPort;
            aCom1Params[1].udiValue := 1;
            // baudrate
            aCom1Params[2].udiParameterId := COM.CAA_Parameter_Constants.udiBaudrate;   
            aCom1Params[2].udiValue := 115200;
            // parity
            aCom1Params[3].udiParameterId := COM.CAA_Parameter_Constants.udiParity;
            aCom1Params[3].udiValue := INT_TO_UINT(COM.PARITY.NONE);
            // stopbit
            aCom1Params[4].udiParameterId := COM.CAA_Parameter_Constants.udiStopBits;
            aCom1Params[4].udiValue := INT_TO_UINT(COM.STOPBIT.ONESTOPBIT);
            // timeout
            aCom1Params[5].udiParameterId := COM.CAA_Parameter_Constants.udiTimeout;
            aCom1Params[5].udiValue := 0;
            // byte size
            aCom1Params[6].udiParameterId := COM.CAA_Parameter_Constants.udiByteSize;
            aCom1Params[6].udiValue := 8;
            // mode of transmission
            aCom1Params[7].udiParameterId := COM.CAA_Parameter_Constants.udiBinary;
            aCom1Params[7].udiValue := 0;
            
            // open COM port
            como1(xExecute := TRUE, usiListLength:=UINT_TO_USINT(SIZEOF(aCom1Params)/SIZEOF(COM.PARAMETER)),pParameterList:= ADR(aCom1Params), hCom=> hCom);
            
            // Successful
            IF como1.xDone THEN
                como1(xExecute := FALSE);   // Reset xExecute Flag
                iState := 10;               // Goto 10: Start Reading
            // Error
            ELSIF como1.xError THEN
                xCom1OpenError := TRUE;
                iError := como1.eError;
                iState := 1000; // Error occurred
            END_IF
    END_IF  

------------------------------------------

// COM_READ

IF iState = 10 THEN
 // Start Reading COM port
        
        IF xClearAll THEN
            // reset errors
            POU_SERIAL_COM1.xCom1ReadError  := FALSE;
            //POU_SERIAL_TEST.xCom1WriteError := FALSE;
            POU_SERIAL_COM1.xCom1OpenError  := FALSE;       
            xClearAll := FALSE;
        END_IF
        
        // read COM port
        AlignTimer(IN := TRUE, PT := T#1000MS);
        
        IF AlignTimer.Q THEN
            sStatus := 'Read';
            comr1(xExecute:= TRUE, hCom:= hCom, pBuffer:= ADR(bReadBuffer), szBuffer:= SIZEOF(bReadBuffer));
            IF comr1.xDone THEN
                szRead:= comr1.szSize;
                uiRead:= ANY_TO_UINT(comr1.szSize);
                
                IF uiRead <> 0 THEN
                    IF uiRead = 1255 THEN               
                        // Copy text from the read buffer to sReadText
                        MEM.MemMove(ADR(bReadBuffer), ADR(sReadText), uiRead);  // move bReadBuffer to sReadText
                        MEM.MemFill(ADR(sReadText) + uiRead, 1, 0);             // write ASCII 000 to byte after received string
                        
                        IF sReadText <> '' THEN 
                            //arsReceived[0,iCounter] := GetTime(1);    // get timestamp
                            Received := sReadText;  // copy read string to array
        
                            intReceived := STRING_TO_INT(Received);
                            sReadText   := '';                      // reset read string
                            
                            DSMRPaser(sTelegram := ADR(Received));
                            bAligned := TRUE;
                        END_IF
                    
                        xReadSuccess:= TRUE;
                    ELSE
                        MismatchCounter := MismatchCounter + 1;
                        bAligned := False;
                    END_IF
                END_IF
                
                AlignTimer(IN := FALSE);
                comr1(xExecute:= FALSE);    // Reset xExecute Flag
                iState:= 15;                // Goto 15: Delay after Reading
                
            // error
            ELSIF comr1.xError THEN
                xCom1ReadError := TRUE;
                errRead := comr1.eError;
                iError := comr1.eError;
                comr1(xExecute:= FALSE);
                iState:= 1000; // Error occurred
            END_IF
    END_IF
    
END_IF
IF iState = 15 THEN     
        //Delay after Reading is finished
            sStatus := 'Read Wait';
            xReadSuccess:= FALSE;
            iState := 10;   // Goto 10: read
END_IF

FB DSMRParser

code:

{attribute 'reflection' := ''}
FUNCTION_BLOCK fbDSMRParser
VAR_INPUT
    sTelegram : POINTER TO STRING(1500); (* Input string containing DSMR telegram *)
END_VAR
VAR_OUTPUT

END_VAR
VAR
    (* MQTT *)
    {attribute 'instance-path'}
    {attribute 'noinit'}
    (* object's full instance name DO NOT REMOVE PRAGMA or MQTT fails*)
    InstanceName            : STRING;
    Startup                 : BOOL := TRUE;
    InitMqttDone            : BOOL;
    MqttPublishTopicPrefix  : POINTER TO STRING;
    MqttPublishTopicSuffix  : STRING(50);
    pMqttPublishQueue       : POINTER TO FB_MqttPublishQueue;   


    (* PRO JSON *)
    stP1State           : typeP1State;
    fbStructToJson      : STRUCT_TO_JSON;
    sJsonString         : STRING(1024);
    sPlaceholder        : STRING(255);
END_VAR

------------------------

// MEMCOPY(ADR(sPlaceholder), sTelegram + 51, 28);
// THIS^.stP1State.Equipment_ID.AsString := LEFT(sPlaceholder, 28);
// 
MEMCOPY(ADR(sPlaceholder), sTelegram + 875, 6);
sPlaceholder := DELETE(sPlaceholder, 1, 3);
THIS^.stP1State.Instantaneous_Power_Consumption.Integer := STRING_TO_INT(LEFT(sPlaceholder, 5)); // Current power consumption (kW) (OBIS code: 1-0:1.7.0)


MEMCOPY(ADR(sPlaceholder), sTelegram + 897, 6);
sPlaceholder := DELETE(sPlaceholder, 1, 3);
THIS^.stP1State.Instantaneous_Power_Production.Integer := STRING_TO_INT(LEFT(sPlaceholder, 5)); // Current power production (kW) (OBIS code: 1-0:2.7.0)

fbStructToJson.JSONString       := ADR(sJsonString);
fbStructToJson.JSONStringSize   := SIZEOF(sJsonString);
fbStructToJson.JSONVars         := ADR(stP1State);
fbStructToJson.NumberOfVars     := SIZEOF(stP1State) / SIZEOF(JSONVAR);
fbStructToJson.MaxLevel         := 1;
fbStructToJson(Execute := TRUE);

IF InitMqttDone THEN
    (* Resets STRUCT_TO_JSON block ready for the next composition *)
    fbStructToJson(Execute := FALSE);
    (* Send off MQTT *)
    pMqttPublishQueue^.AddMessage(
        Payload := sJsonString,
        Topic := CONCAT(CONCAT(MqttPublishTopicPrefix^, MqttPublishTopicSuffix), '/read/state' ),
        Qos := MQTT.QoS.AtMostOnce,
        MqttRetain := FALSE
    );
END_IF

[ Voor 19% gewijzigd door Kanze op 12-02-2025 22:01 ]

[cotton_eye_joe]

Ik ben bezig mijn eckelmann controller uit te wisselen voor een Wago 750-8112, maar krijg met geen mogelijkheid modbus via de seriële poort in de benen. Heeft iemand hier een idee?

-Slave is getest met een modbus programma en converter via laptop dus die is goed.
-Communicatie instellingen kloppen (baud, slaveadres, etc).
-Via browser Seriele poort ingesteld op RS485
-Op DBsub9 pin 3 gebruikt voor A en pin 8 gebruikt voor B
-Voor de zekerheid ook voeding op IO klemmen gezet al gaat volgens mij de voeding van de seriele poort via de voeding van de CPU
-Ik heb geen eindmodule geplaatst, geen idee of dit invloed heeft maar het is een verschil dat ik zie vergeleken met een instructie filmpje.
-Het enige grote verschil dat ik zie is dat ze op de video de modbus master van wago gebruiken, ik kan alleen de modbus master van 3s selecteren. Zou dit iets uitmaken?



Sugusties zijn zeer welkom

[Kanze]

cotton_eye_joe schreef op woensdag 26 februari 2025 @ 19:11:
Ik ben bezig mijn eckelmann controller uit te wisselen voor een Wago 750-8112, maar krijg met geen mogelijkheid modbus via de seriële poort in de benen. Heeft iemand hier een idee?

-Slave is getest met een modbus programma en converter via laptop dus die is goed.
-Communicatie instellingen kloppen (baud, slaveadres, etc).
-Via browser Seriele poort ingesteld op RS485
-Op DBsub9 pin 3 gebruikt voor A en pin 8 gebruikt voor B
-Voor de zekerheid ook voeding op IO klemmen gezet al gaat volgens mij de voeding van de seriele poort via de voeding van de CPU
-Ik heb geen eindmodule geplaatst, geen idee of dit invloed heeft maar het is een verschil dat ik zie vergeleken met een instructie filmpje.
-Het enige grote verschil dat ik zie is dat ze op de video de modbus master van wago gebruiken, ik kan alleen de modbus master van 3s selecteren. Zou dit iets uitmaken?

[Afbeelding]

Sugusties zijn zeer welkom

1. Altijd een eindmodule plaatsen. Ik heb geen ervaring met PFC100's maar op mijn PFC200 G1 is dit verplicht als ik me goed herinner.
2. A en B connecteren maar ook FB_GND (pin 5 denk ik) connecteren aan je slave. Technisch is het een zuiver differentieel protocol maar ik merk dat er wel eens problemen optreden zonder die common ground
3. Stap over naar WagoAppPlcModbus

[Kanze]

In die handleiding van de PFC100 lees ik hieronder dat Wago een specifieke configuratie vraagt voor baudrates onder 115200. Lijkt me sterk dat nét dat het probleem zou zijn maar je weet maar nooit...

[cotton_eye_joe]

Bedankt voor het meedenken!

Ik heb net een andere slave geleend en getest (Chint DTSU666 kWh meter), die doet het wel gewoon. Heel erg vreemd. Kan nog niet ontdekken waarom mijn P1 naar modbus converter het wel doet via de laptop maar niet via de wago. Als ik meer weet post ik het hier.

[Kanze]

Opgepast bij het uitlezen van je P1 poort dat je rekening houdt met de cycles van je PLC en de timing van de inkomende data. Mijn teller maakt telegrammen van 1255 bytes. Ik had bij de ontvangst een ongewenste offset van 1 byte in mijn code. Het verschil tussen de code met en zonder die ene byte offset zie je onderaan.

code:

    sStatus := 'Read';
    comr1(xExecute:= TRUE, hCom:= hCom, pBuffer:= ADR(bReadBuffer), szBuffer:= SIZEOF(bReadBuffer));
    
    IF comr1.xDone THEN
        
        (* How many bytes read from COM1 this cycle *)  
        szRead              := comr1.szSize;
        uiRead              := ANY_TO_UINT(comr1.szSize);
        
        (* Buffered data during startup is ignored *)
        IF uiRead > 1255 THEN
            ;
                    
        (* Complete or Incomplete telegram - 3 options
            1. First char "/" and exactly 1255 bytes -> Perfect hit
            2. First char "/" but not 1255 bytes -> First Half
            3. First char NOT "/" and NOT 1255 bytes -> Second Half *Careful!**)
        ELSIF uiRead > 0 AND uiRead <= 1255 THEN

            IF bReadBuffer[1] = 47 THEN
                MEM.MemMove(ADR(bReadBuffer), ADR(sReadText), uiRead);
                uiReadTotal := uiReadTotal + uiRead;    

            ELSIF sReadText <> '' THEN
                MEM.MemMove(ADR(bReadBuffer) + uiReadTotal + 1, ADR(sReadText) + uiReadTotal + 1, uiRead);
                uiReadTotal := uiReadTotal + uiRead;
            END_IF

            IF uiReadTotal = 1255 THEN
                Received        := sReadText;                   // copy read string to array
                intReceived     := STRING_TO_INT(Received);
                sReadText       := '';                          // reset read string
                iState          := 10;
                uiReadTotal     := 0;
                DSMRParser(sTelegram := ADR(Received));
            END_IF
            
        (* No P1 telegram -- 0 bytes *) 
        ELSE
            ;
        END_IF

        comr1(xExecute:= FALSE, hCom:= hCom);
    END_IF