Domotica met plc's

[KoBolD54]

MichVw schreef op zondag 25 oktober 2020 @ 14:01:
[...]


Leuk om te horen dat je de basis vlot in gang hebt gekregen. waar het precies kan aan liggen is moeilijk t zeggen. Is het PLC_PRG_MQTT programma ook effectief gescheduled als een task op de PLC?

In de Task Configuration staat een 'MqttCommunication' die 'PLC_PRG_MQTT' aanroept. Als de het programma niet wordt aangeroepen zou de U1 LED het volgens mij ook niet doen toch?

In de monitor zie ik ook dat hij actief is.

[ Voor 28% gewijzigd door KoBolD54 op 25-10-2020 15:11 ]

[MichVw]

KoBolD54 schreef op zondag 25 oktober 2020 @ 15:09:
[...]

In de Task Configuration staat een 'MqttCommunication' die 'PLC_PRG_MQTT' aanroept. Als de het programma niet wordt aangeroepen zou de U1 LED het volgens mij ook niet doen toch?

In de monitor zie ik ook dat hij actief is.
[Afbeelding]

Stefan (persoon die de MQTT lib gemaakt heeft) heeft wat docs over hoe je kan debuggen:
https://github.com/stefan.../integration.md#debugging

Normaal staat er wel een duidelijke fout in de errorhistory!

[KoBolD54]

MichVw schreef op maandag 26 oktober 2020 @ 08:26:
[...]


Stefan (persoon die de MQTT lib gemaakt heeft) heeft wat docs over hoe je kan debuggen:
https://github.com/stefan.../integration.md#debugging

Normaal staat er wel een duidelijke fout in de errorhistory!

Probleem gevonden. Ik had de dynamic memmory allocation wel aangezet maar heb de "maximum size of memory" op de default 1000 bytes laten staan. Dit heb ik nu aangepast naar de 50000 bytes zoals de GitHub van Stefan aangeeft.

[KoBolD54]

Kan iemand mij helpen met MQTT op de PLC? Wat ik probeer te bereiken is dat als een DO true of false is, ik dit terug wil zien in HA via MQTT. En dat ik via HA of de schakelaar een DO kan schakelen.

Daarvoor heb ik de volgende regel in WRITE_SWITCHES toegevoegd:

code:

DO_001:=FB_VIRTUAL_BOOL_001.OUT;

Echter kan ik dan wel de uitgang schakelen via HA maar niet meer via de schakelaar. Haal ik die regel weg dan werkt de schakelaar weer.

edit:

Na dagen zoeken heb ik het probleem gevonden:
Ik moet: "FB_OUTPUT_SWITCH_MQTT" gebruiken en geen virtual device

[ Voor 13% gewijzigd door KoBolD54 op 28-10-2020 20:55 ]

[MichVw]

Voor mensen die op zoek naar een ventilatiesysteem: de DUCO systemen hebben een modbus RTU interface waarmee je alles kan uitlezen & zaken kan gaan aansturen.

Duco focus als voorbeeld (C+ systeem):
https://www.duco.eu/be_nl...ilatie-units/ducoboxfocus

Onder technische documentatie staat alles voor modbus mooi uitgelegd.
Ik ga dan ook proberen dit allemaal uit te lezen en aan te sturen via m'n PLC
Hoe dan ook (PLC of niet), Modbus RTU over RS485 integratie by default is zeer mooi meegenomen!

[KoBolD54]

Ik probeer via mijn Wago PLC met LED lampen te dimmen. Daarvoor heb ik een Wago 750-559 4AO 0-10V DC module gekocht en een Finders 15.11 Slave dimmer.

De volgende stukken structured text heb ik gebruikt:

PLC_PRG_MAIN

code:

    (* DIMMER FUNCTION BLOCKS *)
    MqttPubDimmerPrefix         :STRING(100) := 'WAGO-PFC200/Out/Dimmers/';
    MqttSubDimmerPrefix         :STRING(100) := 'WAGO-PFC200/In/Dimmers/';
    FB_AO_DIMMER_001            :FB_OUTPUT_DIMMER_MQTT; 
    AO_001                      :BYTE;

READ_PUSHBUTTONS

code:

FB_DI_PB_002(PB:= DI_002);

WRITE_SWITCHES

code:

FB_AO_DIMMER_001(SINGLE:=   FB_DI_PB_002.SINGLE,    (* for toggling the output Q *)
    DOUBLE:=                FB_DI_PB_002.DOUBLE,    (* for controlling the output DBL *)
    LONG:=                  FB_DI_PB_002.LONG,      (* for controlling the dimmer output OUT *)
    P_LONG:=                FB_DI_PB_002.P_LONG,    (* for controlling the dimmer output OUT *)
//    Q=>                     DO_002,                 (* couple the function block to the physical digital output *)
    OUT:=                   AO_001                 (* couple the function block to the physical anolog output *)
);

Als ik de code run gebeurt er vervolgens helemaal niets als ik vervolgens de pulse schakelaar indruk. Met een multimeter meet ik op uitgang AO_001 dan ook 0 volt. Wel zie ik dat "OUT" en "AO_001" beginnen bij 0 en dan soms naar 1 of 50 gaan als ik de pulse schakelaar indruk / long press, al zit er geen logica in.

Dit dit iets te maken hebben met het feit dat AO_001 van het type WORD is en dat OUT een BYTE is? Kan iemand mij verder help?

[Santford]

KoBolD54 schreef op vrijdag 30 oktober 2020 @ 23:26:
Ik probeer via mijn Wago PLC met LED lampen te dimmen. Daarvoor heb ik een Wago 750-559 4AO 0-10V DC module gekocht en een Finders 15.11 Slave dimmer.

De volgende stukken structured text heb ik gebruikt:

PLC_PRG_MAIN

code:

    (* DIMMER FUNCTION BLOCKS *)
    MqttPubDimmerPrefix         :STRING(100) := 'WAGO-PFC200/Out/Dimmers/';
    MqttSubDimmerPrefix         :STRING(100) := 'WAGO-PFC200/In/Dimmers/';
    FB_AO_DIMMER_001            :FB_OUTPUT_DIMMER_MQTT; 
    AO_001                      :BYTE;

READ_PUSHBUTTONS

code:

FB_DI_PB_002(PB:= DI_002);

WRITE_SWITCHES

code:

FB_AO_DIMMER_001(SINGLE:=   FB_DI_PB_002.SINGLE,    (* for toggling the output Q *)
    DOUBLE:=                FB_DI_PB_002.DOUBLE,    (* for controlling the output DBL *)
    LONG:=                  FB_DI_PB_002.LONG,      (* for controlling the dimmer output OUT *)
    P_LONG:=                FB_DI_PB_002.P_LONG,    (* for controlling the dimmer output OUT *)
//    Q=>                     DO_002,                 (* couple the function block to the physical digital output *)
    OUT:=                   AO_001                 (* couple the function block to the physical anolog output *)
);

Als ik de code run gebeurt er vervolgens helemaal niets als ik vervolgens de pulse schakelaar indruk. Met een multimeter meet ik op uitgang AO_001 dan ook 0 volt. Wel zie ik dat "OUT" en "AO_001" beginnen bij 0 en dan soms naar 1 of 50 gaan als ik de pulse schakelaar indruk / long press, al zit er geen logica in.

Dit dit iets te maken hebben met het feit dat AO_001 van het type WORD is en dat OUT een BYTE is? Kan iemand mij verder help?

Voor alle zekerheid, heb je de in- en uitgangen van de functie blokken gekoppeld aan fysieke op de in- en uitgangskaarten?

[KoBolD54]

Santford schreef op zaterdag 31 oktober 2020 @ 00:06:
[...]

Voor alle zekerheid, heb je de in- en uitgangen van de functie blokken gekoppeld aan fysieke op de in- en uitgangskaarten?

Is dat niet wat ik doe bij READ_PUSHBUTTONS en WRITE_SWITCHES met onderstaande. Daar koppel ik FB_DI_PB_002 aan DI_002 en FB_AO_DIMMER_001.OUT aan AO_001 toch?

code:

FB_DI_PB_002(PB:= DI_002);

code:

FB_AO_DIMMER_001(SINGLE:=   FB_DI_PB_002.SINGLE,    (* for toggling the output Q *)
    DOUBLE:=                FB_DI_PB_002.DOUBLE,    (* for controlling the output DBL *)
    LONG:=                  FB_DI_PB_002.LONG,      (* for controlling the dimmer output OUT *)
    P_LONG:=                FB_DI_PB_002.P_LONG,    (* for controlling the dimmer output OUT *)
//    Q=>                     DO_002,                 (* couple the function block to the physical digital output *)
    OUT:=                   AO_001                 (* couple the function block to the physical anolog output *)
);

Na wat debuggen lijkt het probleem hem inderdaad in de BYTE vs WORD te zitten. Als ik namelijk het volgende doe meet ik netjes 10v.

code:

AO_001:= 32767

[ Voor 15% gewijzigd door KoBolD54 op 31-10-2020 15:04 ]

[MichVw]

KoBolD54 schreef op zaterdag 31 oktober 2020 @ 13:51:
[...]

Is dat niet wat ik doe bij READ_PUSHBUTTONS en WRITE_SWITCHES met onderstaande. Daar koppel ik FB_DI_PB_002 aan DI_002 en FB_AO_DIMMER_001.OUT aan AO_001 toch?

code:

FB_DI_PB_002(PB:= DI_002);

code:

FB_AO_DIMMER_001(SINGLE:=   FB_DI_PB_002.SINGLE,    (* for toggling the output Q *)
    DOUBLE:=                FB_DI_PB_002.DOUBLE,    (* for controlling the output DBL *)
    LONG:=                  FB_DI_PB_002.LONG,      (* for controlling the dimmer output OUT *)
    P_LONG:=                FB_DI_PB_002.P_LONG,    (* for controlling the dimmer output OUT *)
//    Q=>                     DO_002,                 (* couple the function block to the physical digital output *)
    OUT:=                   AO_001                 (* couple the function block to the physical anolog output *)
);

Na wat debuggen lijkt het probleem hem inderdaad in de BYTE vs WORD te zitten. Als ik namelijk het volgende doe meet ik netjes 10v.

code:

AO_001:= 32767

Ik heb die function block in de tijd gemaakt zonder effectief te kunnen testen aangezien ik geen analoge kaart heb.. Kan je een issue maken op github? dan maak ik een aanpassing!

Alvast bedankt om dit te bekijken, toont mooi hoe de moeite van één iemand een hoop andere mensen helpt adhv een community rond het project

[KoBolD54]

MichVw schreef op zaterdag 31 oktober 2020 @ 19:31:
[...]


Ik heb die function block in de tijd gemaakt zonder effectief te kunnen testen aangezien ik geen analoge kaart heb.. Kan je een issue maken op github? dan maak ik een aanpassing!

Alvast bedankt om dit te bekijken, toont mooi hoe de moeite van één iemand een hoop andere mensen helpt adhv een community rond het project

Done: https://github.com/Michie...mation.CoDeSys3/issues/72

Alvast bedankt voor het aanpassen, zodra het klaar is zal ik het gelijk testen.

[UglyDinosaur]

Na een tijdje goed gelopen te hebben, heb ik nu toch weer het probleem dat het RAM geheugen van mijn PFC200 stilaan vol loopt waarna de PLC stopt met werken. Zeer vervelend aangezien alle verlichting 's nachts geen verlichting op het toilet ineens...) en verwarming van het huis ('s ochtends koud huis) hier op hangt... De voeding er af en terug op is het enige dat werkt. Maar na een aantal weken weer het zelfde dan.

Ik begin het eigenlijk allemaal een beetje beu te worden en kan de oplossing niet vinden. Nu ben ik aan het overwegen de boel op te splitsen. De PFC200 gebruiken voor de verwarming en dan de verlichting e.d. via een veldbuscoupler op bvb een raspberry (met SSD voor betrouwbaarheid) met Node-red te hangen.

Iemand al ervaring met dat laatste?

[ Voor 5% gewijzigd door UglyDinosaur op 01-11-2020 12:17 ]

[Ethirty]

Dat laatste is sowieso wel een interessante gedachte voor mensen die de PLC primair als IO gebruiken en er weinig of geen logica in willen.

Dit is ook waarom ik nog steeds twijfel aan 1 grote IO pool of het te splitsen in meerdere kleinere pools.

[UglyDinosaur]

Ja, moest ik destijds geweten hebben wat ik nu weet denk ik niet dat ik voor de PFC200 zou zijn gegaan.

Met Node red kan je echt wel heel veel en als je dan de wago componenten kan gebruiken voor input en output zie ik niet veel meerwaarde in de PFC200.

[TLDNL]

Kan je geen watchdog instellen die de PFC200 automatisch herstart?
Wel vreemd dat die zo volloopt. Misschien Wago support vragen of ze daar een oplossing voor hebben? De PLC's zijn immers bedoeld om lange tijd zonder problemen stand alone te draaien.

Ik ga in mijn huis alles verdelen over 3 pools (Begane grond 750-8212, 1e Verdieping 750-880 en Centrale Verwarming 750-841). Ik ben na testen juist van node-red terug gegaan naar alles in de wago PLC's programmeren. Het idee is om de pfc200 als master met de logica te gebruiken en de andere plc's aan te sturen met modbus TCP en MQTT.

Voor de visuele laag ben ik nog hangend op node-red of domoticz.

[Sandolution]

TLDNL schreef op zondag 1 november 2020 @ 14:18:
Voor de visuele laag ben ik nog hangend op node-red of domoticz.

Ik heb lang getwijfeld wat hier te doen, maar ben uiteindelijk op Domoticz blijven hangen. Vind de dashboards van NodeRed niet zo mooi. En hoef eigenlijk niks te besturen, want alles gaat vanzelf. Daarom gekozen om hier verder maar geen tijd in te steken.

Voor interfacing met Domoticz heb ik een eigen gemaakte library beschikbaar, moet in alleen nog op GitHub zetten. Vergelijkbaar met die van MitchVw, alleen dan puur voor Domoticz. Let me know als je deze wilt testen of gebruiken

[TLDNL]

Ja heel graag. Ben er wel benieuwd naar. Is die gemaakt in Node-Red of Codesys/e!Cockpit?

[ Voor 3% gewijzigd door TLDNL op 02-11-2020 09:58 . Reden: Niet goed gelezen. ]

[Sandolution]

TLDNL schreef op zondag 1 november 2020 @ 14:56:
Ja heel graag. Ben er wel benieuwd naar. Is die gemaakt in Node-Red of Codesys/e!Cockpit?

De libraries zijn gemaakt met PLC Designer (Lenze), maar zijn gewoon CoDeSys libraries en projecten.
Ik heb vanmorgen alles so far op GitHub gezet, inclusief een klein voorbeeldproject.
Kijk er gerust eens doorheen, maar er is nog weinig docu.

https://github.com/Sandolution/CoDeSys_Domoticz

[UglyDinosaur]

TLDNL schreef op zondag 1 november 2020 @ 14:18:
Kan je geen watchdog instellen die de PFC200 automatisch herstart?
Wel vreemd dat die zo volloopt. Misschien Wago support vragen of ze daar een oplossing voor hebben? De PLC's zijn immers bedoeld om lange tijd zonder problemen stand alone te draaien.

Af en toe ad random de PLC laten herstarten met een watchdog is geen aanvaardbare oplossing omdat dan één keer per week de verlichting zal uitvallen...

Support van Wago zal me niet graag zien komen denk ik, aangezien het probleem eerder bij de programmatie zit en dit niet met hun software is gedaan.

Ik heb het probleem op het Codesys forum gezet dus nu hopen dat ze daar een oplossing weten.

[xelnaha]

interessante vraag:

ik meet een 72v wisselstroom voltage tussen de plc en een aarde van een andere groep. Aangezien dit nogal hoog is vraag ik me af waar dit vandaan komt? de standaard kit heeft geen geaarde voeding, dus vermoed ik dat die aan het zweven is, maar heeft iemand anders dit al meegemaakt?

[UglyDinosaur]

Even een update i.v.m. mijn geheugen probleem. Na heel wat heen en weer gemail met de codesys support hadden ze na het inkijken van mijn logs opgemerkt dat de sessies niet werden afgesloten nadat ik met de browser naar de webvisu gegaan was. Blijkbaar een bug in de vorige versies van de software die met de laatste versie opgelost zou zijn.

Heb nu alles geupdate naar de laatste versie en ondertussen draait de PLC al een 3-tal uren en is het RAM verbruik nog niets toegenomen.

Ik ben dus licht optimistisch dat ik misschien eindelijk een oplossing heb.

Verder nog even melden dat de support van Codesys echt wel top is.

[MichVw]

UglyDinosaur schreef op dinsdag 3 november 2020 @ 19:36:
Even een update i.v.m. mijn geheugen probleem. Na heel wat heen en weer gemail met de codesys support hadden ze na het inkijken van mijn logs opgemerkt dat de sessies niet werden afgesloten nadat ik met de browser naar de webvisu gegaan was. Blijkbaar een bug in de vorige versies van de software die met de laatste versie opgelost zou zijn.

Heb nu alles geupdate naar de laatste versie en ondertussen draait de PLC al een 3-tal uren en is het RAM verbruik nog niets toegenomen.

Ik ben dus licht optimistisch dat ik misschien eindelijk een oplossing heb.

Verder nog even melden dat de support van Codesys echt wel top is.

Ik heb ook zeer goede ervaring met Codesys support, zelfde kan ook gezegd worden van Wago support echter.

Ik heb in het verleden ook problemen gehad met Codesys die toen te wijden waren aan een bug. Helaas ook veel tijd aan verloren toen. Helaas bestaat er niet iets als een pagina waar alle known bugs per versie gedocumenteerd staan.

[UglyDinosaur]

Ik wordt stilaan wanhopig. Het probleem is alleen maar groter geworden ondertussen.

Het geheugengebruik van de PLC is stabiel nu, maar na enkele uren stopt de PLC gewoon...
Vreselijk frustrerend.

Edit: De Codesys helpdesk had laten weten dat de Roßmann Engineering library die ik gebruik voor MQTT wel vaker voor problemen zorgt dus ik heb deze er deze morgen uit gegooid.
Voorlopig nog geen uitval gehad sinds deze morgen...

EDIT 2: vannacht weer ermee gestopt...

[ Voor 41% gewijzigd door UglyDinosaur op 07-11-2020 07:45 ]

[xelnaha]

xelnaha schreef op maandag 2 november 2020 @ 22:44:
interessante vraag:

ik meet een 72v wisselstroom voltage tussen de plc en een aarde van een andere groep. Aangezien dit nogal hoog is vraag ik me af waar dit vandaan komt? de standaard kit heeft geen geaarde voeding, dus vermoed ik dat die aan het zweven is, maar heeft iemand anders dit al meegemaakt?

Kleine update, nadat ik de din rail met aarde verbonden heb is spanningsverschil nog maar 1.2v AC. Lijkt me sterk op dat zonder 0v == aarde de transfo een zwevend voltage heeft gehad.

Ik weet niet of deze intern geaard is via de din rail, maar dat gaan we eens uitzoeken

[Sandolution]

Vaak wordt in besturingskasten de min van de 24V voeding ook met de aarde verbonden. Althans, zo zie ik ze vaak voorbij komen. Hiermee hef je in 1 klap alle zwevende verschillen op.

[jellevictoor]

Ik ben een modbus noob en ben nu from the ground up modbus aan het leren, maar wanneer ik via modbus de 750-881 uitlees, dan lukt dit voor alles van 1-512 via FC1, maar wanneer ik meer wil uitlezen, 513-1024 krijg ik een 0x02 terug, invalid adress.
Maar in de documentatie zie ik (p238 http://www.farnell.com/datasheets/2626640.pdf) dat de adressen die je met FC1 en FC2 uitgelezen kunnen worden oplopen tot 65535

Enig idee waar ik de mist in ga?

[thomke]

Dag iedereen!

Ik ben ook begonnen met mijn Wago PFC200 eens uit te testen en dankzij de goede documentatie van MichVw ben ik al goed opgeschoven. Maar ik zit met een probleem tijdens het 'builden' van het programma...
ik draai codesys v3.5 SP16 patch5

hier loop ik tegen onderstaand probleem aan:


probleem (volgens mij) is dat er een variabele gedeclareerd wordt genaamd 'LDT' van het type 'DT'
maar ziet het systeem 'LDT' reeds als een type..
(juis zoals een fout zou krijgen als je een variabele 'BOOl' zou willen aanmaken. - Bool : bool ; dit genereert ook een fout.. ik denk dat ik hetzelfde scenario zit..


wat ik wel raar vind is dat ik de enige ben met dit probleem?

groeten,
Thomas

[Sandolution]

thomke schreef op donderdag 12 november 2020 @ 22:11:
hier loop ik tegen onderstaand probleem aan:
[Afbeelding]

probleem (volgens mij) is dat er een variabele gedeclareerd wordt genaamd 'LDT' van het type 'DT'
maar ziet het systeem 'LDT' reeds als een type..
(juis zoals een fout zou krijgen als je een variabele 'BOOl' zou willen aanmaken. - Bool : bool ; dit genereert ook een fout.. ik denk dat ik hetzelfde scenario zit..

Je geeft zelf het antwoord al: er is een naam gebruikt die gebruikt wordt als keyword. LDT is een datatype (long date time). Deze is erbij gekomen toen CoDeSys 64bit ging ondersteunen. Niet alle controllers doen dat, dus niet alle controllers geven problemen met het compileren. Als je in de build log kijkt, zal er ook een soortgelijke error beschrijving staan.

Betreft benaming; ik (en ook op het werk) gebruik de Hongaarse notatie. Kun je altijd alles uit elkaar houden. Dat is bij OSCAT meestal ver te zoeken.

[ Voor 9% gewijzigd door Sandolution op 12-11-2020 22:46 ]

[MichVw]

Sandolution schreef op donderdag 12 november 2020 @ 22:43:
[...]


Je geeft zelf het antwoord al: er is een naam gebruikt die gebruikt wordt als keyword. LDT is een datatype (long date time). Deze is erbij gekomen toen CoDeSys 64bit ging ondersteunen. Niet alle controllers doen dat, dus niet alle controllers geven problemen met het compileren. Als je in de build log kijkt, zal er ook een soortgelijke error beschrijving staan.

Betreft benaming; ik (en ook op het werk) gebruik de Hongaarse notatie. Kun je altijd alles uit elkaar houden. Dat is bij OSCAT meestal ver te zoeken.

wat is de Hongaarse notatie precies? Als ik het goed begrijp ligt het aan CodeSys die een datatype toevoegd vanaf een bepaalde versie? Ik veronderstel dat de fix is de OSCAT library aanpassen?

[MichVw]

UglyDinosaur schreef op donderdag 5 november 2020 @ 06:52:
Ik wordt stilaan wanhopig. Het probleem is alleen maar groter geworden ondertussen.

Het geheugengebruik van de PLC is stabiel nu, maar na enkele uren stopt de PLC gewoon...
Vreselijk frustrerend.

Edit: De Codesys helpdesk had laten weten dat de Roßmann Engineering library die ik gebruik voor MQTT wel vaker voor problemen zorgt dus ik heb deze er deze morgen uit gegooid.
Voorlopig nog geen uitval gehad sinds deze morgen...

EDIT 2: vannacht weer ermee gestopt...

Zou je beter eens niet door de zure appel bijten, wat ST leren en m'n project overnemen? Ik begrijp dat je programmeer ervaring beperkt is maar zal het je niet op lange termijn flink wat tijd uitsparen?

[thomke]

MichVw schreef op vrijdag 13 november 2020 @ 08:29:
[...]


wat is de Hongaarse notatie precies? Als ik het goed begrijp ligt het aan CodeSys die een datatype toevoegd vanaf een bepaalde versie? Ik veronderstel dat de fix is de OSCAT library aanpassen?

zelf gebruik ik oook vaak de hongaarse notitie inderdaad
(dit is dat de beginletter van uw variablee uw type voorstelt ( bSwitch is dan een boolean, iNummer is dan een Integer..)

Maar ik denk ook dat het dan moet zijn dat LDT (in siemens inderdaad gebuikt als Long Date Time) vroeger niet gekend was als een type in codesys en dat deze nu wel ook gebruikt wordt als een type.. want ik heb het inderdaad gewoon van de OSCAT library deze zal moeten aangepast worden dan vermoed ik inderdaad..
maar vandaar dus dat ik het raar vind dat ik de enige met dit probleem zou zijn.. iedereen die de OSCAT basic bibliotheek gebruikt zou dit probleem moeten hebben dan vermoed ik..

Edit:
wat gezocht op het forum van OSCAT. en inderdaad, ik ben niet de enige met het probleem, iedereen vanaf Codesys V3.5 SP16 zal hier tegenaan lopen. (er zijn een aantal variablen die hernoemd moeten worden in de bibliotheek.. ik weet niet als OSCAT nog veel ontwikkelingen doet en dit zal aanpassen (laatste updaties is van 2012 dacht is dus vrees ik er voor)
http://www.oscat.de/community/index.php/topic,5794.0.html

[ Voor 17% gewijzigd door thomke op 13-11-2020 10:13 ]

[MichVw]

@thomke , @Sandolution , aangezien jullie professioneel bezig zijn met PLC programmatie had ik volgende vraag; hoe gaan jullie precies om met library management?

Waar ik nu tegenloop is wanneer ik een restore doe van het project op m'n nieuwe laptop dat hij klaagt over library 'CAA File' die versie 3.15.40 ipv 3.13.00 (bijvoorbeeld, heb de exacte nummers nu niet bij de hand).

Ik vind het verleidelijk om alle library files te backupen in de git repo zelf maar vraag me af of dat wel de juiste manier is. Hoe pakken jullie dat normaal aan?

[thomke]

thomke schreef op vrijdag 13 november 2020 @ 09:04:
[...]


zelf gebruik ik oook vaak de hongaarse notitie inderdaad
(dit is dat de beginletter van uw variablee uw type voorstelt ( bSwitch is dan een boolean, iNummer is dan een Integer..)

Maar ik denk ook dat het dan moet zijn dat LDT (in siemens inderdaad gebuikt als Long Date Time) vroeger niet gekend was als een type in codesys en dat deze nu wel ook gebruikt wordt als een type.. want ik heb het inderdaad gewoon van de OSCAT library deze zal moeten aangepast worden dan vermoed ik inderdaad..
maar vandaar dus dat ik het raar vind dat ik de enige met dit probleem zou zijn.. iedereen die de OSCAT basic bibliotheek gebruikt zou dit probleem moeten hebben dan vermoed ik..

Edit:
wat gezocht op het forum van OSCAT. en inderdaad, ik ben niet de enige met het probleem, iedereen vanaf Codesys V3.5 SP16 zal hier tegenaan lopen. (er zijn een aantal variablen die hernoemd moeten worden in de bibliotheek.. ik weet niet als OSCAT nog veel ontwikkelingen doet en dit zal aanpassen (laatste updaties is van 2012 dacht is dus vrees ik er voor)
http://www.oscat.de/community/index.php/topic,5794.0.html

ik heb de BASIC library van de OSCAT site gehaald en de variabel namen aangepast.
probleem is dat de library waar moeilijk over gedaan wordt de basic in de building is.. de building kan ik niet downloaden (niet voor codesys) van op de oscat site.. ik kan mijn aangepaste library wel toevoegen nu.. maar ik zou eigenlijk de basic onder de building moeten kunnen updaten en niet een extra 'basic' toevoegen.. iemand een idee hoe ik dit doe?

MichVw schreef op vrijdag 13 november 2020 @ 09:38:
@thomke , @Sandolution , aangezien jullie professioneel bezig zijn met PLC programmatie had ik volgende vraag; hoe gaan jullie precies om met library management?

Waar ik nu tegenloop is wanneer ik een restore doe van het project op m'n nieuwe laptop dat hij klaagt over library 'CAA File' die versie 3.15.40 ipv 3.13.00 (bijvoorbeeld, heb de exacte nummers nu niet bij de hand).

Ik vind het verleidelijk om alle library files te backupen in de git repo zelf maar vraag me af of dat wel de juiste manier is. Hoe pakken jullie dat normaal aan?

bij ons op het werk maken we geen gebruik van libraries (omdat dit omslachtig is ^^ ) wij maken gebruik van een 'bibliotheek' project.. we halen de fuctieblokken die we nodig hebben dan gewoon van dit project en kopiëren deze naar ons project. -ik heb zelf nog nooit geprobeerd te werken met bibliotheken, dit is de manier hoe ze het hier doen op het het werk en hoe ik er ook ingerold ben-

[Sandolution]

thomke schreef op vrijdag 13 november 2020 @ 09:04:
[...]
Edit:
wat gezocht op het forum van OSCAT. en inderdaad, ik ben niet de enige met het probleem, iedereen vanaf Codesys V3.5 SP16 zal hier tegenaan lopen. (er zijn een aantal variablen die hernoemd moeten worden in de bibliotheek.. ik weet niet als OSCAT nog veel ontwikkelingen doet en dit zal aanpassen (laatste updaties is van 2012 dacht is dus vrees ik er voor)
http://www.oscat.de/community/index.php/topic,5794.0.html

Wellicht kunnen we veelgebruikte functies in de OSCAT library 'porten' naar een nieuwe automation library. Ben sowieso nooit fan geweest van OSCAT. Veel dingen zijn reeds achterhaald, zeker na 8 jaar Wellicht kunnen we dit naast de library van @MichVw en die van mij doen? Een verzameling van veelgebruikte functies?

MichVw schreef op vrijdag 13 november 2020 @ 09:38:
@thomke , @Sandolution , aangezien jullie professioneel bezig zijn met PLC programmatie had ik volgende vraag; hoe gaan jullie precies om met library management?

Waar ik nu tegenloop is wanneer ik een restore doe van het project op m'n nieuwe laptop dat hij klaagt over library 'CAA File' die versie 3.15.40 ipv 3.13.00 (bijvoorbeeld, heb de exacte nummers nu niet bij de hand).

Ik vind het verleidelijk om alle library files te backupen in de git repo zelf maar vraag me af of dat wel de juiste manier is. Hoe pakken jullie dat normaal aan?

Sowieso is het goed om van een bestaand project een project archive te maken, met daarin alle bestanden, libraries, device descriptions en dergelijken.

Ik werk dagelijks wekelijks met libraries en ontwikkel ook mee aan libraries. Wij gebruiken over het algemeen placeholders en zo min mogelijk fixed versions. Compatibility staat bij ons op nummer 1, maar 'nieuwe' versies werken niet met oudere controller firmware's danwel compiler versies. Dat is niet te handhaven / garanderen.

[ Voor 40% gewijzigd door Sandolution op 13-11-2020 12:46 ]

[thomke]

Sandolution schreef op vrijdag 13 november 2020 @ 12:44:
[...]


Wellicht kunnen we veelgebruikte functies in de OSCAT library 'porten' naar een nieuwe automation library. Ben sowieso nooit fan geweest van OSCAT. Veel dingen zijn reeds achterhaald, zeker na 8 jaar Wellicht kunnen we dit naast de library van @MichVw en die van mij doen? Een verzameling van veelgebruikte functies?

na lang zoeken zoeken en proberen met die OSCAT library denk ik er ook aan om gewoon alles zelf te schrijven.
@Sandolution heb jij dan ook ergens een library/vb project staan?
want het is tenslotte zonde om iets te schrijven wat reeds door iemand anders gedaan is en goed werkt.

[Sandolution]

thomke schreef op vrijdag 13 november 2020 @ 12:55:
[...]
@Sandolution heb jij dan ook ergens een library/vb project staan?
want het is tenslotte zonde om iets te schrijven wat reeds door iemand anders gedaan is en goed werkt.

Ja, zie Github en dan /Libraries/SNDLTN_Hestia/V1.1.200929/

Contents zien er nu zo uit:

[MichVw]

Sandolution schreef op vrijdag 13 november 2020 @ 12:44:
[...]


Wellicht kunnen we veelgebruikte functies in de OSCAT library 'porten' naar een nieuwe automation library. Ben sowieso nooit fan geweest van OSCAT. Veel dingen zijn reeds achterhaald, zeker na 8 jaar Wellicht kunnen we dit naast de library van @MichVw en die van mij doen? Een verzameling van veelgebruikte functies?


[...]


Sowieso is het goed om van een bestaand project een project archive te maken, met daarin alle bestanden, libraries, device descriptions en dergelijken.

Ik werk dagelijks wekelijks met libraries en ontwikkel ook mee aan libraries. Wij gebruiken over het algemeen placeholders en zo min mogelijk fixed versions. Compatibility staat bij ons op nummer 1, maar 'nieuwe' versies werken niet met oudere controller firmware's danwel compiler versies. Dat is niet te handhaven / garanderen.

Ik ben er zeker voor te vinden om OSCAT te porten naar iets anders. Hoe zie je dat precies? een eigen versie maken van zowel BASIC/BUILDING/NETWORK?

Misschien word het tijd dat we een git organisation beginnen om de meerdere projecten in te steken.. Kunnen we meteen ook een static website maken met bv het idee achter alles en misschien wat blogposts met tijd...

Enige nadeel is dat er flink wat tijd zal in kruipen denk ik...

ik heb een ecockpit project archive maar als ik dat open doe krijg ik nog altijd zelfde fout (op m'n nieuw device dan, archive is gemaakt op device waar alles prima werkte).

[Sandolution]

Ik zie het voor me dat we niet de library van OSCAT porten, maar alleen functies welke we bruikbaar achten, opnieuw schrijven en implementeren in een nieuwe library. Dat wil zeggen; schrijven vanaf scratch, maar wel met de kennis zoals deze in OSCAT zit. Anders is het gewoon kopieëren natuurlijk

We kunnen, naast onze integraties, een github repository maken waarin we meerdere contributors hebben en meerdere mensen een pull-request kunnen goedkeuren. Weet niet precies hoe dit op GitHub werkt, werk er niet dagelijks mee

[UglyDinosaur]

MichVw schreef op vrijdag 13 november 2020 @ 08:30:
[...]


Zou je beter eens niet door de zure appel bijten, wat ST leren en m'n project overnemen? Ik begrijp dat je programmeer ervaring beperkt is maar zal het je niet op lange termijn flink wat tijd uitsparen?

Ik DENK dat ik ondertussen weet wat het probleem veroorzaakt... De VISU van de HVAC bibliotheek die ik gekocht heb.

Als ik de PLC herstart en ik ga niet in de visualisatie van mijn verwarming blijft alles lopen. Als ik een keer naar de visu ga blijft de boel even later hangen.

Dat verklaart ook waarom alles is blijven bollen heel de zomer en de problemen pas de kop op staken toen ik mijn verwarmingsinstallatie terug aan gezet heb...

[MichVw]

Sandolution schreef op vrijdag 13 november 2020 @ 13:57:
Ik zie het voor me dat we niet de library van OSCAT porten, maar alleen functies welke we bruikbaar achten, opnieuw schrijven en implementeren in een nieuwe library. Dat wil zeggen; schrijven vanaf scratch, maar wel met de kennis zoals deze in OSCAT zit. Anders is het gewoon kopieëren natuurlijk

We kunnen, naast onze integraties, een github repository maken waarin we meerdere contributors hebben en meerdere mensen een pull-request kunnen goedkeuren. Weet niet precies hoe dit op GitHub werkt, werk er niet dagelijks mee

Ik zou zeker ook niet alles porten, enkel wat we nodig hebben. Vraag is dan of we nog steeds een onderscheid maken tussen basic/building/network..?

Ik kan wel kijken voor de github setup.. een voorstel naar naam?

[thomke]

MichVw schreef op vrijdag 13 november 2020 @ 14:53:
[...]


Ik zou zeker ook niet alles porten, enkel wat we nodig hebben. Vraag is dan of we nog steeds een onderscheid maken tussen basic/building/network..?

Ik kan wel kijken voor de github setup.. een voorstel naar naam?

ik zou hier geen onderscheid in maken.. het is tenslotte allemaal voor home automation...

hieronder een afbeelding van iets hoe ik het zou zien.. de FB is nog in opmaak maar dit is de denkpiste waar ik nu op zit. (geen idee als jullie dit ook zo zien of niet)



(nu nog uitzoeken hoe de MQTT communicatie werkt - heb ik nog nooit mee gewerkt en dan ook nog eventueel code voor long press toevoegen )

het idee is dan van gewoon per pushbutten die FB op te roepen, de DI er aan koppelen een een publish naam voor MQTT en that's it...

op die manier kan je alles dan mooi op een bovenliggend domotica systeem binnen pakken, indien je toch intern in de PLC nog verder logica wilt bouwen kan je dit doen via de outputs van de FB


ik ben benieuwd naar jullie gedachtegang

Groeten,
Thomas

[Sandolution]

thomke schreef op vrijdag 13 november 2020 @ 15:28:
[...]
het idee is dan van gewoon per pushbutten die FB op te roepen, de DI er aan koppelen een een publish naam voor MQTT en that's it...

Ziet er al goed uit. Heb je de Hestia lib al bekeken? Daar zit onder "InputClicks" ook al iets dergelijks.
Ik roep dergelijke functies ook alleen op waar ik ze nodig heb, oftewel, ik koppel ze aan variabelen waar nodig. Werkt dus 100% los van de Domoticz library. Hetzelfde geldt voor de OutputHistory en OutputDelay, die gebruik ik veel in mijn project.

MichVw schreef op vrijdag 13 november 2020 @ 14:53:
[...]
Ik kan wel kijken voor de github setup.. een voorstel naar naam?

HomeAutomation Utilities?


Overigens geldt dat ik allerhande code en dergelijken vrij snel kan testen. Heb (zeker met het thuiswerken) altijd wel een paar PLC's aanstaan

[ Voor 8% gewijzigd door Sandolution op 13-11-2020 15:51 ]

[MichVw]

Als ik wat verder kijk zie ik dat ook Stefan (MQTT lib publisher) gebruik maakt van de OSCAT libs (basic + network). Is het dan het uiteindelijke doel dat ook die MQTT lib onze lib kan gebruiken of willen we niet zover gaan? (wat zijn de voordelen?)

[thomke]

Sandolution schreef op vrijdag 13 november 2020 @ 15:50:
[...]


Ziet er al goed uit. Heb je de Hestia lib al bekeken? Daar zit onder "InputClicks" ook al iets dergelijks.
Ik roep dergelijke functies ook alleen op waar ik ze nodig heb, oftewel, ik koppel ze aan variabelen waar nodig. Werkt dus 100% los van de Domoticz library. Hetzelfde geldt voor de OutputHistory en OutputDelay, die gebruik ik veel in mijn project.

had ik nog niet bekeken maar ondertussen eens vlug bekeken en inderdaad ziet er goed uit!

het idee om alles dan nog aan variabelen te linken weet ik niet als ik zo volg.. (is extra werk uiteindelijk...)
terwijl je anders alles intern in de block zou kunnen doen (nog gewoon een sName voor MQTT publish meegeven?) langs de andere kant snap ik ook wel de redenering om dan onafhankelijk van communicatie protocol te kunnen werken.. maar ik zou wel durven alles inzetten op MQTT ziet er toch naar uit dat dit meer en meer de standaard wordt bij IoT

MichVw schreef op vrijdag 13 november 2020 @ 16:01:
Als ik wat verder kijk zie ik dat ook Stefan (MQTT lib publisher) gebruik maakt van de OSCAT libs (basic + network). Is het dan het uiteindelijke doel dat ook die MQTT lib onze lib kan gebruiken of willen we niet zover gaan? (wat zijn de voordelen?)

ik zou proberen zo min mogelijk afhankelijk te zijn van 3rd party bibliotheken...
eventueel dit eens bekijken:
https://store.codesys.com...=en&___from_store=default
wat nu eigenlijk hieronder valt: (geen idee als je dat dan effectief ook moet kopen? - ik weet nog niet zo goed hoe de hele licentie policy werkt van codesys..
https://store.codesys.com/iiot-libraries-sl.html

[Sandolution]

thomke schreef op vrijdag 13 november 2020 @ 16:58:
het idee om alles dan nog aan variabelen te linken weet ik niet als ik zo volg.. (is extra werk uiteindelijk...)
terwijl je anders alles intern in de block zou kunnen doen (nog gewoon een sName voor MQTT publish meegeven?) langs de andere kant snap ik ook wel de redenering om dan onafhankelijk van communicatie protocol te kunnen werken.. maar ik zou wel durven alles inzetten op MQTT ziet er toch naar uit dat dit meer en meer de standaard wordt bij IoT

Mee eens dat het doorlinken extra werk is, maar het geeft je ook totale vrijheid. Ik heb niet overal dezelfde functionaliteit nodig dus door dit specifiek te doen, minimaliseer ik overhead. In mijn Domoticz library zitten al allerlei verschillende apparaten vooraf ingebouwd. Bij een Hue Dimmer zijn kort/lang indrukken bijvoorbeeld al ingebouwd. Veel meer drukknoppen gebruik ik eigenlijk niet.

Mee eens dat MQTT de standaard is, maar bij Domoticz is dat een plug-in en niet native ingebouwd. Dus de integratie draait daar ook volledig rondom HTTP en is MQTT bijzaak. Vandaar dat de library van @MichVw en mij zoveel verschillen

thomke schreef op vrijdag 13 november 2020 @ 16:58:
https://store.codesys.com...=en&___from_store=default
wat nu eigenlijk hieronder valt: (geen idee als je dat dan effectief ook moet kopen? - ik weet nog niet zo goed hoe de hele licentie policy werkt van codesys..
https://store.codesys.com/iiot-libraries-sl.html

CoDeSys werkt met License Dongles die per laptop het gebruik van een library toestaan. Weet verder ook niet precies hoe dit werkt. Zoveel mogelijk library afhankelijk is inderdaad een goed uitgangspunt.

[MichVw]

ik zou proberen zo min mogelijk afhankelijk te zijn van 3rd party bibliotheken...
eventueel dit eens bekijken:
https://store.codesys.com...=en&___from_store=default
wat nu eigenlijk hieronder valt: (geen idee als je dat dan effectief ook moet kopen? - ik weet nog niet zo goed hoe de hele licentie policy werkt van codesys..
https://store.codesys.com/iiot-libraries-sl.html

De lib van Stefan is volledig open source:
https://github.com/stefandreyer/CODESYS-MQTT

Dus lijkt me een betere dependency dan die uit de Codesys store? (Die kunnen plots licentie kost x 10 doen).

Mochten we willen kunnen we dus de dependencies naar OSCAT zelf uit z'n lib halen, alhoewel ik denk dat hij wel te vinden zal zijn om ze er zelf uit te halen (ik heb veel met hem samengewerkt om z'n lib te testen en te finetunen).

Lijkt het jullie ook interessant om een github repo te hebben met allerlei libraries? (alle versies die we kunnen vinden). Lijkt me handig om dependency problemen makkelijk te kunnen oplossen?

[thomke]

MichVw schreef op vrijdag 13 november 2020 @ 18:37:
[...]


De lib van Stefan is volledig open source:
https://github.com/stefandreyer/CODESYS-MQTT

Dus lijkt me een betere dependency dan die uit de Codesys store? (Die kunnen plots licentie kost x 10 doen).

Mochten we willen kunnen we dus de dependencies naar OSCAT zelf uit z'n lib halen, alhoewel ik denk dat hij wel te vinden zal zijn om ze er zelf uit te halen (ik heb veel met hem samengewerkt om z'n lib te testen en te finetunen).

Lijkt het jullie ook interessant om een github repo te hebben met allerlei libraries? (alle versies die we kunnen vinden). Lijkt me handig om dependency problemen makkelijk te kunnen oplossen?

Ik zou juist met 1 enkele library werken, die op zijn beurt niet gebruik maakt van andere libraries (juist om problemen met comptabiliteit te voorkomen. en alles wat we nodig hebben in die ene libraty te voorzien)

Dus dus ik persoonlijk zou opteren om alles wat nodig is om die MQTT werkend te krijgen zelf te integereren in de library.

(ik weet niet als dit de beste manier is natuurlijk, zoals ik al zei heb ik niet echt ervaring met het gebruik van libraries, maar ik zou niet willen in een scenario terrecht komen in de toekomst dat een onderdeel die een paar libraries diep zit niet meer compileerbaar zou zijn..) .

Sandolution schreef op vrijdag 13 november 2020 @ 18:32:
[...]


Mee eens dat het doorlinken extra werk is, maar het geeft je ook totale vrijheid. Ik heb niet overal dezelfde functionaliteit nodig dus door dit specifiek te doen, minimaliseer ik overhead. In mijn Domoticz library zitten al allerlei verschillende apparaten vooraf ingebouwd. Bij een Hue Dimmer zijn kort/lang indrukken bijvoorbeeld al ingebouwd. Veel meer drukknoppen gebruik ik eigenlijk niet.

Mee eens dat MQTT de standaard is, maar bij Domoticz is dat een plug-in en niet native ingebouwd. Dus de integratie draait daar ook volledig rondom HTTP en is MQTT bijzaak. Vandaar dat de library van @MichVw en mij zoveel verschillen

ik persoonlijk zou de MQTT toch durven integreren in de FB,
je kan nog altijd via de output doorlinken en de gewenste functionaliteit aan koppelen.
wat misschien een idee kan zijn is door te spelen met de input 'sName' van de FB die gebruikt wordt voor MQTT, indien 'sName' niet ingevuld is , het stukje code dat MQTT afhandelt niet uitvoeren..
(ik ben hier maar eens 'luidop' aan het denken)

[UglyDinosaur]

UglyDinosaur schreef op vrijdag 13 november 2020 @ 14:01:
[...]


Ik DENK dat ik ondertussen weet wat het probleem veroorzaakt... De VISU van de HVAC bibliotheek die ik gekocht heb.

Als ik de PLC herstart en ik ga niet in de visualisatie van mijn verwarming blijft alles lopen. Als ik een keer naar de visu ga blijft de boel even later hangen.

Dat verklaart ook waarom alles is blijven bollen heel de zomer en de problemen pas de kop op staken toen ik mijn verwarmingsinstallatie terug aan gezet heb...

Kleine update: ik heb dit weekend de knoop doorgehakt en alles wat betreft HVAC programmering uit de PLC gegooid en het in node-red op een Raspberry geprogrammeerd. Met OPC-UA stuur ik dan de uitgangen van de PLC aan waar de zone-ventielen aan gekoppeld zijn. Het was heel wat uurtjes zweten dit weekend, maar ik hoop dat ik er nu ongeveer van af ben.

De PLC draait nu onder een VEEL lagere belasting en het PLC programma is nu een factor 10 kleiner. Voorlopig draait alles zeer stabiel.

[Robbiedobbie]

Oystein schreef op maandag 16 december 2019 @ 09:29:
Zo heb ik nog 2 pulsdrukkers binnen over (de andere bedienen de zonneschermen) waarmee ik straks in de tuin (wordt Logo nr. 4) de verlichting verdeeld over 2 groepen aan en uit kan zetten.

[Afbeelding]

Het is natuurlijk al bijna een jaar geleden dat dit gepost is, maar bij het scrollen door dit topic kwam ik deze pulsdrukkers tegen en die vind ik wel erg mooi. Iemand enig idee welke dit zijn?

Ik ben ondertussen ook flink aan het oriënteren omdat ik als alles goed gaat ergens in februari een nieuwe woning ga betrekken. In die woning gaan we door de jaren heen alles erg grof renoveren, wat betekent dat ik overal lekker bekabeld domotica kan integreren.

Mijn keuze hierbij is dan ook al snel op een PLC gevallen. Echter blijven bij mij een paar vragen openstaan, vooral op het gebied van regelgeving bij het combineren van laag en hoogspanning.

Wat zijn de eisen (in Nederland) aan 230v schakelingen die in een domotica kast als deze plaatsvinden?
Vooral wanneer er meerdere groepen gecombineerd zouden gaan worden met relais die door de domotica aangestuurd gaan worden ontstaan er twijfels bij mij.
Normaal zijn de eisen namelijk dat je losse groepen nooit door dezelfde buizen mag laten gaan. Hoe zit dit op het moment dat meerdere van deze buizen wel weer uitkomen in een schakelkast (in dit geval dus voor de domotica). Mag het dan wel weer "bij elkaar" zitten?

Is het überhaupt verstandig om bijvoorbeeld meerdere groepen voor verlichting te gebruiken om risico te spreiden bij uitval van verlichting? (De domotica wil ik verder sowieso op een losse groep zetten)

[deWit]

Ooit gekocht omdat een PLC een optie was voor de domotica, maar uiteindelijk gekozen voor KNX. Wago 750-881 met de nodige DI en DO. Heeft het nog zin om dit in V&A te gooien? Ook nog een hele bak moet voedingen, 24V relais en meer...

[ Voor 3% gewijzigd door deWit op 16-11-2020 20:08 ]

[Rob Z]

@deWit Ja, dat levert je nog genoeg op

[TLDNL]

@deWit Ebay lijkt wel meer op te leveren dan Marktplaats.

[Oystein]

Robbiedobbie schreef op maandag 16 november 2020 @ 19:59:
[...]


Het is natuurlijk al bijna een jaar geleden dat dit gepost is, maar bij het scrollen door dit topic kwam ik deze pulsdrukkers tegen en die vind ik wel erg mooi. Iemand enig idee welke dit zijn?

Ik ben ondertussen ook flink aan het oriënteren omdat ik als alles goed gaat ergens in februari een nieuwe woning ga betrekken. In die woning gaan we door de jaren heen alles erg grof renoveren, wat betekent dat ik overal lekker bekabeld domotica kan integreren.

Mijn keuze hierbij is dan ook al snel op een PLC gevallen. Echter blijven bij mij een paar vragen openstaan, vooral op het gebied van regelgeving bij het combineren van laag en hoogspanning.

Wat zijn de eisen (in Nederland) aan 230v schakelingen die in een domotica kast als deze plaatsvinden?
Vooral wanneer er meerdere groepen gecombineerd zouden gaan worden met relais die door de domotica aangestuurd gaan worden ontstaan er twijfels bij mij.
Normaal zijn de eisen namelijk dat je losse groepen nooit door dezelfde buizen mag laten gaan. Hoe zit dit op het moment dat meerdere van deze buizen wel weer uitkomen in een schakelkast (in dit geval dus voor de domotica). Mag het dan wel weer "bij elkaar" zitten?

Is het überhaupt verstandig om bijvoorbeeld meerdere groepen voor verlichting te gebruiken om risico te spreiden bij uitval van verlichting? (De domotica wil ik verder sowieso op een losse groep zetten)

Het gebruikte schakelmateriaal is van Niko, de pulsdrukkers zijn deze (ik heb ze wel een kwart slag gedraaid) en gebruik de "Pure White Steel" afdekraampjes:

https://www.niko.eu/nl-nl...55-52e1-98c7-bfd1bf6aa940

Wat betreft de meerdere groepen in één kast / buis:

Je groepenkast heeft tenslotte ook meerdere groepen in één kast dus dan is je domotica kast een ondervrrdeler waarin je ook meerdere groepen kunt hebben. Deze zijn natuurlijk wel van elkaar gescheiden maar dat al die bedrading langs elkaar loopt is geen probleem.
Natuurlijk zorg je wel dat alle aankomende en afgaande buizen alleen bedrading hebben welke bij dezelfde groep horen.

Zo is mijn domotica kast ook, de geschakelde WCD's zitten op verschillende groepen omdat de woonkamer / keuken ook over 3 groepen verdeeld is.

Zo zag mijn kast er nog in het begin uit ... ondertussen zit er al wat meer in:

De domotica heeft een eigen automaat en dan 3 automaten voor de groepen.
Hier alles B10 ivm selectiviteit met de groepenkast waar alles B16 is.
De grijze klemmenstrook is door schotjes ook opgedeeld in 3 delen voor de herkenbaarheid.

[Robbiedobbie]

Oystein schreef op dinsdag 17 november 2020 @ 09:08:
[...]


Het gebruikte schakelmateriaal is van Niko, de pulsdrukkers zijn deze (ik heb ze wel een kwart slag gedraaid) en gebruik de "Pure White Steel" afdekraampjes:

https://www.niko.eu/nl-nl...55-52e1-98c7-bfd1bf6aa940

Wat betreft de meerdere groepen in één kast / buis:

Je groepenkast heeft tenslotte ook meerdere groepen in één kast dus dan is je domotica kast een ondervrrdeler waarin je ook meerdere groepen kunt hebben. Deze zijn natuurlijk wel van elkaar gescheiden maar dat al die bedrading langs elkaar loopt is geen probleem.
Natuurlijk zorg je wel dat alle aankomende en afgaande buizen alleen bedrading hebben welke bij dezelfde groep horen.

Zo is mijn domotica kast ook, de geschakelde WCD's zitten op verschillende groepen omdat de woonkamer / keuken ook over 3 groepen verdeeld is.

Zo zag mijn kast er nog in het begin uit ... ondertussen zit er al wat meer in:

De domotica heeft een eigen automaat en dan 3 automaten voor de groepen.
Hier alles B10 ivm selectiviteit met de groepenkast waar alles B16 is.
De grijze klemmenstrook is door schotjes ook opgedeeld in 3 delen voor de herkenbaarheid.

[Afbeelding]

[Afbeelding]

Helder! Ik neem aan dat je dan wel de kabels die bij het 230v gedeelte komen (Dus bijv de signaalkabels naar de relais) moet uitvoeren met kabel die een huls heeft die genoeg isolatie heeft om tussen de 230v kabels te mogen liggen?

[UglyDinosaur]

Helaas blijven bij mij de problemen maar aanslepen...

Gisterenavond het programma eens van 0 af aan heropgebouwd (het programma waar ik mee werkte daar ben ik al 2 jaar zaken aan het invoegen en uitgooien dus ik dacht dat er daar misschien iets fout zat) en alleen gehouden wat ik echt nodig heb.
Dat is dus enkel:
-Schakelaars op de ingangen
- relais voor de verlichting op de uitgangen
- Programmatie van de koppelingen tussen deze 2
- Modbus TCP voor het uitlezen van de arduino met de temperatuursensoren
- uitgangen naar de relais van de zoneventielen
- OPC UA koppeling tussen PLC en node red.

Het programma is nu zeer klein en de belasting van de PLC zeer laag.

Maar toch is hij vannacht weer uitgevallen... Het linux deel van de PLC blijft draaien want ik kan er op via de console maar codesys is uitgevallen. Ik geraak er ook niet meer aan via de codesys software.

Aangezien ik nu toch veronderstel dat de code OK is, begin ik nu maar aan het hardware gedeelte te zoeken... Allereerst ga ik de voeding eens vervangen door een Siemens LOGO voeding.

[Giblet]

Tjemig ik heb echt met je te doen @UglyDinosaur . Wat vervelend om te horen en het moet echt enorm frustrerend zijn! Bedankt dat je ons op de hoogte houdt. Ik kan helaas ook niks bedenken wat je nog zou kunnen proberen anders dan wat je aan het doen bent, een voor een de componenten vervangen/herschrijven.

[UglyDinosaur]

Giblet schreef op donderdag 19 november 2020 @ 14:11:
Tjemig ik heb echt met je te doen @UglyDinosaur . Wat vervelend om te horen en het moet echt enorm frustrerend zijn! Bedankt dat je ons op de hoogte houdt. Ik kan helaas ook niks bedenken wat je nog zou kunnen proberen anders dan wat je aan het doen bent, een voor een de componenten vervangen/herschrijven.

Bedankt

Het is echt vreselijk frustrerend en ik laat er hopen slaap door...

De vriendin is het ondertussen ook grondig beu en heeft eigenlijk liever dat ik de boel er uit gooi...

Als laatste stap zou ik nog naar een Raspberri Pi met alles op en een ethernet coupler kunnen gaan, maar da's dan 700 eur voor de PLC weggegooid (en de 300 eur die ik kwijt ben voor coupler + rasperry + licentie)

[kuhlivisj]

UglyDinosaur schreef op donderdag 19 november 2020 @ 14:09:
Helaas blijven bij mij de problemen maar aanslepen...

Gisterenavond het programma eens van 0 af aan heropgebouwd (het programma waar ik mee werkte daar ben ik al 2 jaar zaken aan het invoegen en uitgooien dus ik dacht dat er daar misschien iets fout zat) en alleen gehouden wat ik echt nodig heb.
Dat is dus enkel:
-Schakelaars op de ingangen
- relais voor de verlichting op de uitgangen
- Programmatie van de koppelingen tussen deze 2
- Modbus TCP voor het uitlezen van de arduino met de temperatuursensoren
- uitgangen naar de relais van de zoneventielen
- OPC UA koppeling tussen PLC en node red.

Het programma is nu zeer klein en de belasting van de PLC zeer laag.

Maar toch is hij vannacht weer uitgevallen... Het linux deel van de PLC blijft draaien want ik kan er op via de console maar codesys is uitgevallen. Ik geraak er ook niet meer aan via de codesys software.

Aangezien ik nu toch veronderstel dat de code OK is, begin ik nu maar aan het hardware gedeelte te zoeken... Allereerst ga ik de voeding eens vervangen door een Siemens LOGO voeding.

Als alleen de codesys runtime er mee stopt dan is de kans groter dat het wel in het programma zit. Je zou kunnen proberen om de POU's for implicit checks toe te voegen. Deze functies zorgen ervoor dat bijvoorbeeld een deling door 0 niet fout gaat en de runtime dan niet crashed.

Verder is het aan te bevelen om de laatste firmware en de laatste codesys runtime te gebruiken.

[UglyDinosaur]

kuhlivisj schreef op donderdag 19 november 2020 @ 14:56:
[...]


Als alleen de codesys runtime er mee stopt dan is de kans groter dat het wel in het programma zit. Je zou kunnen proberen om de POU's for implicit checks toe te voegen. Deze functies zorgen ervoor dat bijvoorbeeld een deling door 0 niet fout gaat en de runtime dan niet crashed.

Verder is het aan te bevelen om de laatste firmware en de laatste codesys runtime te gebruiken.

Allemaal al gedaan vrees ik...

Edit: Ik heb toen alleen de check voor bounds gedaan. Ik zal de rest er ook eens aan toevoegen. Zijn er speciale zaken waar ik op moet letten? Kan ik de standaard gegenereerde code gewoon gebruiken?

[ Voor 15% gewijzigd door UglyDinosaur op 19-11-2020 16:11 ]

[kuhlivisj]

De standaard code is in principe voldoende om eventuele fouten af te vangen.

Mocht het met deze functies wel door blijven draaien dan zou je de functies aan kunnen passen om bijvoorbeeld te loggen waar het ergens fout gaat.

[UglyDinosaur]

kuhlivisj schreef op donderdag 19 november 2020 @ 16:17:
De standaard code is in principe voldoende om eventuele fouten af te vangen.

Mocht het met deze functies wel door blijven draaien dan zou je de functies aan kunnen passen om bijvoorbeeld te loggen waar het ergens fout gaat.

OK, bedankt. Ik ga het vanavond aanpassen. Voorlopig laat ik de voeding nog even liggen dan

[Ethirty]

Als zo'n simpel programma al niet werkt, kan je dan niet bij Codesys support krijgen?

[Sandolution]

Kun je niet in het logboek van de controller kijken? Daar haal ik altijd hele waardevolle info uit bij klantproblemen...:)

[Rob Z]

jellevictoor schreef op woensdag 11 november 2020 @ 17:53:
Ik ben een modbus noob en ben nu from the ground up modbus aan het leren, maar wanneer ik via modbus de 750-881 uitlees, dan lukt dit voor alles van 1-512 via FC1, maar wanneer ik meer wil uitlezen, 513-1024 krijg ik een 0x02 terug, invalid adress.
Maar in de documentatie zie ik (p238 http://www.farnell.com/datasheets/2626640.pdf) dat de adressen die je met FC1 en FC2 uitgelezen kunnen worden oplopen tot 65535

Enig idee waar ik de mist in ga?

Lees je echt bits (coils) uit of per ongeluk registers?
(kan niet met FC1, sorry)

[UglyDinosaur]

Ethirty schreef op donderdag 19 november 2020 @ 16:32:
Als zo'n simpel programma al niet werkt, kan je dan niet bij Codesys support krijgen?

Daar ben ik nu ook al een tijdje mee aan het mailen. Voorlopig zit het een beetje vast. Ze vragen het volgende:
"Stop the PLC runtime
​
Open one terminal and start the PLC by typing the command:
LD_PRELOAD=/lib/libuio.so /opt/codesys/bin/codesyscontrol.bin -d /etc/CODESYSControl.cfg
​
open a second terminal and type this command
tail -f /tmp/codesyscontrol.log
​
then when it crashes send us the output of both windows."

Maar met dat eerste commando krijg ik volgende fout: error while loading shared libraries: libnvram.so.0...

[UglyDinosaur]

Sandolution schreef op donderdag 19 november 2020 @ 18:04:
Kun je niet in het logboek van de controller kijken? Daar haal ik altijd hele waardevolle info uit bij klantproblemen...:)

Alle logs die ik kan vinden worden zo te zien gereset bij een heropstart, kan dat zijn? Daar is het dan moeilijk om uit te zoeken wat er verkeer gelopen is

Of moet ik dan de logs bekijken na het crashen en voor het herstarten? Of zijn er ergens logs die behouden blijven?

[Sandolution]

UglyDinosaur schreef op donderdag 19 november 2020 @ 21:31:
[...]

Alle logs die ik kan vinden worden zo te zien gereset bij een heropstart, kan dat zijn? Daar is het dan moeilijk om uit te zoeken wat er verkeer gelopen is

Of moet ik dan de logs bekijken na het crashen en voor het herstarten? Of zijn er ergens logs die behouden blijven?

Bij het opstarten wordt een nieuwe log gemaakt. Wij kunnen op onze controllers de gehele log exporteren, inclusief degene voor het opstarten. Maar erin kijken voordat je hem opnieuw opstart is altijd een goed idee en altijd de eerste stap. Bij PLC's is opnieuw opstarten een vers begin.

[thomke]

UglyDinosaur schreef op donderdag 19 november 2020 @ 21:31:
[...]

Alle logs die ik kan vinden worden zo te zien gereset bij een heropstart, kan dat zijn? Daar is het dan moeilijk om uit te zoeken wat er verkeer gelopen is

Of moet ik dan de logs bekijken na het crashen en voor het herstarten? Of zijn er ergens logs die behouden blijven?

de plc gaat niet gewoon in 'stop'? maar herstart effectief? ik heb nog nooit gehoord van een fout die een PLC doet herstarten... en als hij dan herstart.. staat die dan gewoon in 'run'?

[UglyDinosaur]

thomke schreef op donderdag 19 november 2020 @ 21:34:
[...]


de plc gaat niet gewoon in 'stop'? maar herstart effectief? ik heb nog nooit gehoord van een fout die een PLC doet herstarten... en als hij dan herstart.. staat die dan gewoon in 'run'?

Neenee, zo is het niet. De PLC stopt (alle lampjes blijven groen maar hij doet niets meer). Maar aangezien dat vaak 's nachts gebeurt, herstart ik hem altijd liefst zo snel mogelijk...

Ik heb nu op mijn nas een console open staan waarin het log wordt bijgehouden. Als hij nu moest stilvallen kan ik daar de laatste stand van zaken zien.

[UglyDinosaur]

Sandolution schreef op donderdag 19 november 2020 @ 21:34:
[...]


Bij het opstarten wordt een nieuwe log gemaakt. Wij kunnen op onze controllers de gehele log exporteren, inclusief degene voor het opstarten. Maar erin kijken voordat je hem opnieuw opstart is altijd een goed idee en altijd de eerste stap. Bij PLC's is opnieuw opstarten een vers begin.

OK, bij de volgende crash ga ik er in kijken.

[drled]

Ik heb m'n wago pfc200 ondertussende draaiende en probeer aan de slag te gaan met MQTT.

Nu heb ik het probleem dat de missing libraries niet kan downloaden.
Iemand een idee?

[UglyDinosaur]

Sandolution schreef op donderdag 19 november 2020 @ 21:34:
[...]


Bij het opstarten wordt een nieuwe log gemaakt. Wij kunnen op onze controllers de gehele log exporteren, inclusief degene voor het opstarten. Maar erin kijken voordat je hem opnieuw opstart is altijd een goed idee en altijd de eerste stap. Bij PLC's is opnieuw opstarten een vers begin.

En net weer een crash

Helaas in het logboek niets te vinden dat een antwoord kan geven. Het laatste bericht in het logboek is van 1,5u voordat hij gecrashed is...

2020-11-21T02:10:45Z, 0x0000008d, 2, 0, 0, !!!! Warning: OpcUa_TcpListener_ReadEventHandler: Process Request returned an error (0x80220000)!
2020-11-21T05:39:25Z, 0x0000008d, 4, 0, 0, **** ERROR: SecureListener - OpcUa_SecureListener_ChannelManager_GetChannelBySecureChannelID: Searched SecureChannel NOT found!
2020-11-21T05:39:25Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_ProcessRequest: Closing channel due error 0x80220000!
2020-11-21T05:39:25Z, 0x0000008d, 2, 0, 0, !!!! Warning: OpcUa_TcpListener_ReadEventHandler: Process Request returned an error (0x80220000)!
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: SecureChannel 8394 has no transport connection!
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: Error 0x80310000 while sending message
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_Endpoint_EndSendResponse: Error 0x80310000! Cancelling response!
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: SecureChannel 8394 has no transport connection!
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: Error 0x80310000 while sending message
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_Endpoint_EndSendResponse: Error 0x80310000! Cancelling response!
2020-11-21T05:39:27Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: SecureChannel 8394 has no transport connection!
2020-11-21T05:39:27Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: Error 0x80310000 while sending message
2020-11-21T05:39:27Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_Endpoint_EndSendResponse: Error 0x80310000! Cancelling response!
2020-11-21T05:39:28Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: SecureChannel 8394 has no transport connection!
2020-11-21T05:39:28Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: Error 0x80310000 while sending message
2020-11-21T05:39:28Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_Endpoint_EndSendResponse: Error 0x80310000! Cancelling response!
2020-11-21T11:03:02Z, 0x00000009, 1, 418, 0, Channel timeout (<curtime>191797927</curtime>, <lasttime>191767925</lasttime>)
2020-11-21T11:03:02Z, 0x00000009, 1, 418, 0, Closing connection to <address>0317:8301</address>

[Oystein]

Robbiedobbie schreef op dinsdag 17 november 2020 @ 09:14:
[...]

Helder! Ik neem aan dat je dan wel de kabels die bij het 230v gedeelte komen (Dus bijv de signaalkabels naar de relais) moet uitvoeren met kabel die een huls heeft die genoeg isolatie heeft om tussen de 230v kabels te mogen liggen?

De relais worden geschakeld met 24 Vdc (de rode en zwarte draden) maar het draad is wel geschikt voor 230 Vac dus wat onderlinge isolatie zit dat wel goed.

[poeterdebier]

Goedemiddag, ik ben vol interesse bezig met het doorlezen van dit draadje maar ik ben nog maar op pagina 10. Ik realiseer me dat ik een beetje ongeduldig ben maar toch deze vraag:

kan iemand met helpen om een 750-559 aan te sturen vanaf Node-red? Ik kan inmiddels wel kaarten uitlezen in Node-red maar het schrijven lukt me nog niet. Dit is een Analoge output module 0-10v. Ik gebruik de modbus plugin. Zelf zal ik ik vermoedelijk iets verkeer doen met het specifiekere van de tags. Ik snap dat namelijk nog niet helemaal namelijk.

Achtergrond info:

750-841 1x
750-559 1x
750-430 1x

Ook nog een verdwaalde Micrologix 1400 waar het me ook niet lukt om output te schakelen (wel lezen). Misschien als ik in de toekomst wat meer kennis heb vergaard over het Modbus principe kan ik deze ook aansturen.

Ondertussen lees ik rustig door..

groeten,

[MichVw]

UglyDinosaur schreef op zaterdag 21 november 2020 @ 13:41:
[...]


En net weer een crash

Helaas in het logboek niets te vinden dat een antwoord kan geven. Het laatste bericht in het logboek is van 1,5u voordat hij gecrashed is...

2020-11-21T02:10:45Z, 0x0000008d, 2, 0, 0, !!!! Warning: OpcUa_TcpListener_ReadEventHandler: Process Request returned an error (0x80220000)!
2020-11-21T05:39:25Z, 0x0000008d, 4, 0, 0, **** ERROR: SecureListener - OpcUa_SecureListener_ChannelManager_GetChannelBySecureChannelID: Searched SecureChannel NOT found!
2020-11-21T05:39:25Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_ProcessRequest: Closing channel due error 0x80220000!
2020-11-21T05:39:25Z, 0x0000008d, 2, 0, 0, !!!! Warning: OpcUa_TcpListener_ReadEventHandler: Process Request returned an error (0x80220000)!
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: SecureChannel 8394 has no transport connection!
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: Error 0x80310000 while sending message
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_Endpoint_EndSendResponse: Error 0x80310000! Cancelling response!
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: SecureChannel 8394 has no transport connection!
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: Error 0x80310000 while sending message
2020-11-21T05:39:26Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_Endpoint_EndSendResponse: Error 0x80310000! Cancelling response!
2020-11-21T05:39:27Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: SecureChannel 8394 has no transport connection!
2020-11-21T05:39:27Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: Error 0x80310000 while sending message
2020-11-21T05:39:27Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_Endpoint_EndSendResponse: Error 0x80310000! Cancelling response!
2020-11-21T05:39:28Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: SecureChannel 8394 has no transport connection!
2020-11-21T05:39:28Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_SecureListener_EndSendResponse: Error 0x80310000 while sending message
2020-11-21T05:39:28Z, 0x0000008d, 4, 0, 0, **** ERROR: OpcUa_Endpoint_EndSendResponse: Error 0x80310000! Cancelling response!
2020-11-21T11:03:02Z, 0x00000009, 1, 418, 0, Channel timeout (<curtime>191797927</curtime>, <lasttime>191767925</lasttime>)
2020-11-21T11:03:02Z, 0x00000009, 1, 418, 0, Closing connection to <address>0317:8301</address>

kan je die OPC functionaliteit uitzetten?

[UglyDinosaur]

MichVw schreef op zondag 22 november 2020 @ 16:44:
[...]


kan je die OPC functionaliteit uitzetten?

Ik begin stilaan die OPC UA ook te verdenken... Dat uitzetten gaat niet zomaar omdat ik dat ondertussen overal gebruiken in mijn programmatie

Ik heb gisteren alle Node-reds die ik hier gebruik geupdate en ook de node die de communicatie via OPC UA regelt. Eens zien of het nu misschien stabiel is. Indien niet ga ik alles eens om zetten naar MQTT denk ik en kijken of OPC UA afzetten soelaas brengt...

[Roekeloos]

Ik heb een Wago PLC waarop de hier bekende MQTT software draait via e!Cockpit, een vloerverwarming verdeler met 24VDC kleppen en een Onewire sensor in ieder vertrek. Ik wil graag een eenvoudige zoneregeling bouwen, liefst direct in de PLC en anders op mijn Odroid met Home Assistant.

Ik heb wel wat puzzelstukjes, maar weet niet hoe ik de puzzel het beste kan leggen: Onewire interface via PLC of via USB op de Odroid? Voor aansturing een PLC library of Home Assistant?

Hebben jullie input of best practices voor me? Ik krijg een library geïnstalleerd, maar ben geen PLC programmeur.

[Ethirty]

Zonder je de details te kunnen vertellen, maar verwarming lijkt me een essentieel basis proces.

Ik zou alle IO op de PLC zetten en ook proberen om daar alles te regelen. Het proces van setpoint en huidige temperatuur samen met een simpele curve zou niet het meest ingewikkeld moeten zijn.

Maar Femme doet alle IO al jaren op de PLC en alle logica via een single board en ik denk dat hij daar vast van afgestapt zou zijn als zijn vriendin alweer in een koud huis zou hebben gezeten.

Dus alles staat of valt denk ik met je eigen skillset en hoe snel je denkt te kunnen schakelen bij een probleem of storing.

[UglyDinosaur]

UglyDinosaur schreef op maandag 23 november 2020 @ 08:15:
[...]


Ik begin stilaan die OPC UA ook te verdenken... Dat uitzetten gaat niet zomaar omdat ik dat ondertussen overal gebruiken in mijn programmatie

Ik heb gisteren alle Node-reds die ik hier gebruik geupdate en ook de node die de communicatie via OPC UA regelt. Eens zien of het nu misschien stabiel is. Indien niet ga ik alles eens om zetten naar MQTT denk ik en kijken of OPC UA afzetten soelaas brengt...

Ondertussen al enkele dagen geen uitval meer en ook de foutmeldingen van OPCUA in het logboek blijven weg...

Ik begin dus te vermoeden dan een verouderde versie van node-red of de OPC UA node het probleem was...

[MichVw]

Roekeloos schreef op dinsdag 24 november 2020 @ 19:29:
Ik heb een Wago PLC waarop de hier bekende MQTT software draait via e!Cockpit, een vloerverwarming verdeler met 24VDC kleppen en een Onewire sensor in ieder vertrek. Ik wil graag een eenvoudige zoneregeling bouwen, liefst direct in de PLC en anders op mijn Odroid met Home Assistant.

Ik heb wel wat puzzelstukjes, maar weet niet hoe ik de puzzel het beste kan leggen: Onewire interface via PLC of via USB op de Odroid? Voor aansturing een PLC library of Home Assistant?

Hebben jullie input of best practices voor me? Ik krijg een library geïnstalleerd, maar ben geen PLC programmeur.

het is helaas niet mogelijk om Onewire rechstreeks op je PLC in te lezen.
Je hebt dus volgende opties:
- je koopt een RS232 gateway van Esera en leest de data dan binnen van de gateway op je PLC adhv een serial port (je kan de onboard serial port gebruiken of een apparte 750 module)
- je leest de Onewire data binnen op Home Assistant en stuurd het dan via MQTT naar je PLC en doet de sturing daar
- je leest de Onewire data binnen op Home Assistant en je stuurd in HA de ventielen op je PLC via MQTT

Ik vind verwarming ook vrij essentieel en verkies daarom ook de PLC als sturing aangezien die het robuusts is. Dat je daarvoor in jouw geval een Esera gateway nog eens nodig hebt is een spijtig zaak...

Ter info voor alle lezers; ik ben van plan om een sensor netwerk uit te bouwen via Modbus RTU over RS485 die wel rechtstreeks kan worden binnengelezen op de PLC:
https://github.com/Michie...mation.ModbusRtuSensorHub
Nadeel is wel dat je moet beginnen solderen.. (ik heb contact opgenomen met een webshop om ze te laten maken ook maar ben nog in afwachting van een antwoord)

Naar sturing toe van je vloerverwarming zou het volgens Femme simpel moeten zijn:
ventiel open als de effectieve temperatuur lager is dan de gewenste temperatuur
ventiel gesloten als de effectieve temperatuur hoger (of gelijk) is dan de gewenste temperatuur

De opmerking van @Ethirty in verband met je comfortzone is zeker iets om over na te denken!

[Rob Z]

Voor Onewire (DS18B20 sensoren lezen) en I2C (licht- en RHsensor lezen) heb ik hier een Arduino Uno met Ethernet shield in gebruik die het via Modbus TCP naar de PLC stuurt (Wago 750-881).
Dat loopt al ruim een jaar prima.
HA toont uiteraard die temperaturen etc. ook maar is hier puur visualisatie en sporadische niet-kritische bediening.

[ Voor 37% gewijzigd door Rob Z op 25-11-2020 11:03 ]

[Robbiedobbie]

Wat voor kabels gebruiken jullie eigenlijk om verschillende componenten in de schakelkast te verbinden (voor laagspanning)? Buiten de schakelkast weet ik dat veel cat5/6 kabel gebruikt wordt, of svv kabel met een gewenst aantal aders. Dit lijkt me echter minder handig binnen in de kast. Zijn daar eventueel al kant en klare kabels te koop met adereindhulzen eraan?

[Sandolution]

Beste wat je in een schakelkast kan nemen is denk ik gewoon 0,5mm2 of 0,75mm2.
Vroeger als bijbaan schakelkasten gebouwd, dus ben er wel handig in geworden
Genoeg kleuren voorhanden, maar er zijn ook standaarden in wat je waarvoor gebruikt.
Bij ons was het:

Blauw: 24V (voeding + schakel)
Blauw/Wit: 0V
Wit: Analoog
Oranje: Vreemde spanning van buitenaf
Rood: 230V (schakel)
Zwart: 230/380V (voeding)
Lichblauw: 0V (voeding 230/380)

Soms werd er klantspecifiek nog wel eens andere kleuren gebruikt.
Een doosje van 100m kost zo'n 15 á 20 euro.

[Kanze]

Het is al weer een tijdje geleden dat ik hier nog heb gepost. Dat komt omdat we hoofdzakelijk bezig zijn met de afwerking van ons huis. Maar ondertussen heb ik dus tijd gevonden om de elektrische installatie af te werken voor de keuring. Dat wil dus zeggen enkel en alleen het 230VAC gedeelte inclusief een bank teleruptors. Plaatsing van de PLC komt over de feestdagen. Ondertussen zijn er wel wat praktische zaken die ik geleerd heb.

• @MichVw Deze is misschien ook interessant voor jouw. Ik heb besloten om over te stappen van een design rond een ATTiny3216 naar een ontwerp met de ESP32 voor de sensorkits in de muren. De ESP32 heeft twee grote voordelen voor mij. Als eerste is het dezelfde chip die ook gebruikt wordt in onze PWM LED dimmer modules en ten tweede bezit hij reeds een WiFi en BLE module. Je kan heel compacte dev bordjes kopen met micro USB poort zodat je de chip rechtstreeks kan programmeren geconnecteerd aan je laptop met Arduino IDE. Dat is wel handiger als dat FTDI gedoe. Ons huis zit stampensvol bekabeling en toch heb ik reeds enkele locaties gevonden waar ik toch beter een kabel meer had getrokken of gewoon stomweg ben vergeten. Dan is een connectie via WiFi als backup wel handig. Voor de duidelijkheid; ik blijf gebruikmaken van een RS485 bus met een bijkomende Maxwell chip. Ik probeer het RF spectrum zo proper mogelijk te houden
• Ik heb gekozen voor een installatie met Eltako teleruptors maar die werken initieel wel in relais modus. Ze kosten meer per uitgang als gewoon (Finder) relais maar ze hebben een groot bijkomend voordeel. Je kan deze (manueel) omschakelen naar teleruptor modus wanneer de PLC faalt. Mijn inkomende stuurbekabelen is afgewerkt op WAGO 727 klemmen (4 etages met elk 2 slots) en een reeks doorvoerklemmen met onderbrekingsfunctie. Ik heb een harde bypass ingebouwd waardoor elke lamp in het huis ook dom kan geschakeld worden indien de PLC faalt. Hiervoor moet je wel de teleruptors manueel omschakelen en enkele onderbrekers manueel induwen in de kast. Maar de PLC kan nu dus helemaal de geest geven en met 3 minuutjes werk in de kast heb je weer overal licht in huis. Toch belangrijk.
• Achteraf gezien had ik misschien toch beter overal 5G1,5 of 5G2,5 getrokken zodat er iets meer schakelmogelijkheden waren bij stopcontacten. Maar uiteindelijk kan ik met een zelf ontworpen ESP32 bordje overal wel een relais of PWM dimmer kanaal maken.
• Bij een stevige installatie zou ik toch op z'n minst een kast van 800x1250 installeren. De mijne zal inclusief PLC helemaal volzitten. En dan zitten er niet eens dimmers in (die gaan in een aparte kast)
• Indien mogelijk voorzie een plaats op je verdieping waar je nog aan de doorvoer van alle kabels kan voor verlichting in het plafond van je verdiep. Als je PWM moet gaan dimmen vanuit de centrale kast zit je al snel met afstanden van 15 meter naar spots of strips op je verdiep. Die kan je al halveren door boven nog een tweede kastje te voorzien (moet niet groot zijn)
• Eastron verkoopt z'n meters nu ook met CE certificaat in Europa. Dat maakt de brandverzekering blij!

[yniezink]

Kanze schreef op zondag 29 november 2020 @ 10:02:
Het is al weer een tijdje geleden dat ik hier nog heb gepost. Dat komt omdat we hoofdzakelijk bezig zijn met de afwerking van ons huis. Maar ondertussen heb ik dus tijd gevonden om de elektrische installatie af te werken voor de keuring. Dat wil dus zeggen enkel en alleen het 230VAC gedeelte inclusief een bank teleruptors. Plaatsing van de PLC komt over de feestdagen. Ondertussen zijn er wel wat praktische zaken die ik geleerd heb.

• @MichVw Deze is misschien ook interessant voor jouw. Ik heb besloten om over te stappen van een design rond een ATTiny3216 naar een ontwerp met de ESP32 voor de sensorkits in de muren. De ESP32 heeft twee grote voordelen voor mij. Als eerste is het dezelfde chip die ook gebruikt wordt in onze PWM LED dimmer modules en ten tweede bezit hij reeds een WiFi en BLE module. Je kan heel compacte dev bordjes kopen met micro USB poort zodat je de chip rechtstreeks kan programmeren geconnecteerd aan je laptop met Arduino IDE. Dat is wel handiger als dat FTDI gedoe. Ons huis zit stampensvol bekabeling en toch heb ik reeds enkele locaties gevonden waar ik toch beter een kabel meer had getrokken of gewoon stomweg ben vergeten. Dan is een connectie via WiFi als backup wel handig. Voor de duidelijkheid; ik blijf gebruikmaken van een RS485 bus met een bijkomende Maxwell chip. Ik probeer het RF spectrum zo proper mogelijk te houden
• Ik heb gekozen voor een installatie met Eltako teleruptors maar die werken initieel wel in relais modus. Ze kosten meer per uitgang als gewoon (Finder) relais maar ze hebben een groot bijkomend voordeel. Je kan deze (manueel) omschakelen naar teleruptor modus wanneer de PLC faalt. Mijn inkomende stuurbekabelen is afgewerkt op WAGO 727 klemmen (4 etages met elk 2 slots) en een reeks doorvoerklemmen met onderbrekingsfunctie. Ik heb een harde bypass ingebouwd waardoor elke lamp in het huis ook dom kan geschakeld worden indien de PLC faalt. Hiervoor moet je wel de teleruptors manueel omschakelen en enkele onderbrekers manueel induwen in de kast. Maar de PLC kan nu dus helemaal de geest geven en met 3 minuutjes werk in de kast heb je weer overal licht in huis. Toch belangrijk.
• Achteraf gezien had ik misschien toch beter overal 5G1,5 of 5G2,5 getrokken zodat er iets meer schakelmogelijkheden waren bij stopcontacten. Maar uiteindelijk kan ik met een zelf ontworpen ESP32 bordje overal wel een relais of PWM dimmer kanaal maken.
• Bij een stevige installatie zou ik toch op z'n minst een kast van 800x1250 installeren. De mijne zal inclusief PLC helemaal volzitten. En dan zitten er niet eens dimmers in (die gaan in een aparte kast)
• Indien mogelijk voorzie een plaats op je verdieping waar je nog aan de doorvoer van alle kabels kan voor verlichting in het plafond van je verdiep. Als je PWM moet gaan dimmen vanuit de centrale kast zit je al snel met afstanden van 15 meter naar spots of strips op je verdiep. Die kan je al halveren door boven nog een tweede kastje te voorzien (moet niet groot zijn)
• Eastron verkoopt z'n meters nu ook met CE certificaat in Europa. Dat maakt de brandverzekering blij!

Foto’s? :-)

[MichVw]

Kanze schreef op zondag 29 november 2020 @ 10:02:
Het is al weer een tijdje geleden dat ik hier nog heb gepost. Dat komt omdat we hoofdzakelijk bezig zijn met de afwerking van ons huis. Maar ondertussen heb ik dus tijd gevonden om de elektrische installatie af te werken voor de keuring. Dat wil dus zeggen enkel en alleen het 230VAC gedeelte inclusief een bank teleruptors. Plaatsing van de PLC komt over de feestdagen. Ondertussen zijn er wel wat praktische zaken die ik geleerd heb.

• @MichVw Deze is misschien ook interessant voor jouw. Ik heb besloten om over te stappen van een design rond een ATTiny3216 naar een ontwerp met de ESP32 voor de sensorkits in de muren. De ESP32 heeft twee grote voordelen voor mij. Als eerste is het dezelfde chip die ook gebruikt wordt in onze PWM LED dimmer modules en ten tweede bezit hij reeds een WiFi en BLE module. Je kan heel compacte dev bordjes kopen met micro USB poort zodat je de chip rechtstreeks kan programmeren geconnecteerd aan je laptop met Arduino IDE. Dat is wel handiger als dat FTDI gedoe. Ons huis zit stampensvol bekabeling en toch heb ik reeds enkele locaties gevonden waar ik toch beter een kabel meer had getrokken of gewoon stomweg ben vergeten. Dan is een connectie via WiFi als backup wel handig. Voor de duidelijkheid; ik blijf gebruikmaken van een RS485 bus met een bijkomende Maxwell chip. Ik probeer het RF spectrum zo proper mogelijk te houden
• Ik heb gekozen voor een installatie met Eltako teleruptors maar die werken initieel wel in relais modus. Ze kosten meer per uitgang als gewoon (Finder) relais maar ze hebben een groot bijkomend voordeel. Je kan deze (manueel) omschakelen naar teleruptor modus wanneer de PLC faalt. Mijn inkomende stuurbekabelen is afgewerkt op WAGO 727 klemmen (4 etages met elk 2 slots) en een reeks doorvoerklemmen met onderbrekingsfunctie. Ik heb een harde bypass ingebouwd waardoor elke lamp in het huis ook dom kan geschakeld worden indien de PLC faalt. Hiervoor moet je wel de teleruptors manueel omschakelen en enkele onderbrekers manueel induwen in de kast. Maar de PLC kan nu dus helemaal de geest geven en met 3 minuutjes werk in de kast heb je weer overal licht in huis. Toch belangrijk.
• Achteraf gezien had ik misschien toch beter overal 5G1,5 of 5G2,5 getrokken zodat er iets meer schakelmogelijkheden waren bij stopcontacten. Maar uiteindelijk kan ik met een zelf ontworpen ESP32 bordje overal wel een relais of PWM dimmer kanaal maken.
• Bij een stevige installatie zou ik toch op z'n minst een kast van 800x1250 installeren. De mijne zal inclusief PLC helemaal volzitten. En dan zitten er niet eens dimmers in (die gaan in een aparte kast)
• Indien mogelijk voorzie een plaats op je verdieping waar je nog aan de doorvoer van alle kabels kan voor verlichting in het plafond van je verdiep. Als je PWM moet gaan dimmen vanuit de centrale kast zit je al snel met afstanden van 15 meter naar spots of strips op je verdiep. Die kan je al halveren door boven nog een tweede kastje te voorzien (moet niet groot zijn)
• Eastron verkoopt z'n meters nu ook met CE certificaat in Europa. Dat maakt de brandverzekering blij!

interessant!
welke plaatsen ben je vergeten of heb je niet aan gedacht voor een kabel? (we kunnen er maar uit leren)
waar kan je de Eastron meters kopen met CE certificaat in Europa?
Een foto zou inderdaad leuk zijn

[Rob Z]

Voor 'als de PLC uitvalt' (wat nog niet is gebeurd) heb ik de relais van de belangrijkste lampen (WC etc.) achter een diodeklem gezet. Met een schakelaar komt er dan alsnog 24VDC op de spoelen (als die voeding nog werkt op dat moment).

Vergeten kabels? Alle raamkozijnen hadden een loze leiding moeten krijgen (bij de belangrijkste ramen is het wel aanwezig gelukkig)

[ Voor 22% gewijzigd door Rob Z op 29-11-2020 20:57 ]

[drled]

Kanze schreef op zondag 29 november 2020 @ 10:02:
Het is al weer een tijdje geleden dat ik hier nog heb gepost. Dat komt omdat we hoofdzakelijk bezig zijn met de afwerking van ons huis. Maar ondertussen heb ik dus tijd gevonden om de elektrische installatie af te werken voor de keuring. Dat wil dus zeggen enkel en alleen het 230VAC gedeelte inclusief een bank teleruptors. Plaatsing van de PLC komt over de feestdagen. Ondertussen zijn er wel wat praktische zaken die ik geleerd heb.

• @MichVw Deze is misschien ook interessant voor jouw. Ik heb besloten om over te stappen van een design rond een ATTiny3216 naar een ontwerp met de ESP32 voor de sensorkits in de muren. De ESP32 heeft twee grote voordelen voor mij. Als eerste is het dezelfde chip die ook gebruikt wordt in onze PWM LED dimmer modules en ten tweede bezit hij reeds een WiFi en BLE module. Je kan heel compacte dev bordjes kopen met micro USB poort zodat je de chip rechtstreeks kan programmeren geconnecteerd aan je laptop met Arduino IDE. Dat is wel handiger als dat FTDI gedoe. Ons huis zit stampensvol bekabeling en toch heb ik reeds enkele locaties gevonden waar ik toch beter een kabel meer had getrokken of gewoon stomweg ben vergeten. Dan is een connectie via WiFi als backup wel handig. Voor de duidelijkheid; ik blijf gebruikmaken van een RS485 bus met een bijkomende Maxwell chip. Ik probeer het RF spectrum zo proper mogelijk te houden
• Ik heb gekozen voor een installatie met Eltako teleruptors maar die werken initieel wel in relais modus. Ze kosten meer per uitgang als gewoon (Finder) relais maar ze hebben een groot bijkomend voordeel. Je kan deze (manueel) omschakelen naar teleruptor modus wanneer de PLC faalt. Mijn inkomende stuurbekabelen is afgewerkt op WAGO 727 klemmen (4 etages met elk 2 slots) en een reeks doorvoerklemmen met onderbrekingsfunctie. Ik heb een harde bypass ingebouwd waardoor elke lamp in het huis ook dom kan geschakeld worden indien de PLC faalt. Hiervoor moet je wel de teleruptors manueel omschakelen en enkele onderbrekers manueel induwen in de kast. Maar de PLC kan nu dus helemaal de geest geven en met 3 minuutjes werk in de kast heb je weer overal licht in huis. Toch belangrijk.
• Achteraf gezien had ik misschien toch beter overal 5G1,5 of 5G2,5 getrokken zodat er iets meer schakelmogelijkheden waren bij stopcontacten. Maar uiteindelijk kan ik met een zelf ontworpen ESP32 bordje overal wel een relais of PWM dimmer kanaal maken.
• Bij een stevige installatie zou ik toch op z'n minst een kast van 800x1250 installeren. De mijne zal inclusief PLC helemaal volzitten. En dan zitten er niet eens dimmers in (die gaan in een aparte kast)
• Indien mogelijk voorzie een plaats op je verdieping waar je nog aan de doorvoer van alle kabels kan voor verlichting in het plafond van je verdiep. Als je PWM moet gaan dimmen vanuit de centrale kast zit je al snel met afstanden van 15 meter naar spots of strips op je verdiep. Die kan je al halveren door boven nog een tweede kastje te voorzien (moet niet groot zijn)
• Eastron verkoopt z'n meters nu ook met CE certificaat in Europa. Dat maakt de brandverzekering blij!

Interessant, is dat ontwerp van je ESP32 bordje opensource? Of heb je hierover meer details?
Ik zit momenteel in de fase van het leggen van alle kabels, dus hier ook zeker interesse naar een paar foto's van je kast.

Gebruik je nog steeds de DMX302 dimmers? Ik twijfel nog of ik deze wil gaan gebruiken, uiteindelijk stuur je wel 230V door een niet CE/CEBEC gekeurde component, de prijs is natuurlijk wel heel erg aantrekkelijk..

[Kanze]

drled schreef op maandag 30 november 2020 @ 09:34:
[...]


Interessant, is dat ontwerp van je ESP32 bordje opensource? Of heb je hierover meer details?
Ik zit momenteel in de fase van het leggen van alle kabels, dus hier ook zeker interesse naar een paar foto's van je kast.

Gebruik je nog steeds de DMX302 dimmers? Ik twijfel nog of ik deze wil gaan gebruiken, uiteindelijk stuur je wel 230V door een niet CE/CEBEC gekeurde component, de prijs is natuurlijk wel heel erg aantrekkelijk..

De Dimmer zijn Quinled dimmers. Dat ontwerpt (niet van mij) is open source en gemakkelijk op het internet te vinden. Quinleds werken op basis van een ESP32 chip die PWM dimming toelaat door het sturen van een paar dikke MOSFETs. Alles is dus PWM 24VDC (of lager voor digitale LEDs). Ik wou eigenlijk liefst heel het dimmen in ZLVS houden. In België hadden die DMX302 dimmers anders mee op het eendraadschema voor de keuring gestaan en zoals je zegt het is een niet conform CE product uit China. Da's allemaal goed als het over microchips gaat ofzo maar alles wat 230VAC is moet in mijn huis CE zijn. Ik ben m'n leven niet beu

Ontwerp voor sensorskits met een ESP32 zit nog in de zeer vroege fase dus dat zal nog wel wat moeten wachten. Komt veel kijken bij zo'n huis en de tijd is gelimiteerd.

Als jullie wat foto's willen kan ik er wel wat online zetten binnenkort. Als je foto's wilt van de kast mét PLC moet je wachten tot kerst of later.

[Rob Z]

Sandolution schreef op donderdag 26 november 2020 @ 09:19:
Beste wat je in een schakelkast kan nemen is denk ik gewoon 0,5mm2 of 0,75mm2.
Vroeger als bijbaan schakelkasten gebouwd, dus ben er wel handig in geworden
Genoeg kleuren voorhanden, maar er zijn ook standaarden in wat je waarvoor gebruikt.
Bij ons was het:

Blauw: 24V (voeding + schakel)
Blauw/Wit: 0V
Wit: Analoog
Oranje: Vreemde spanning van buitenaf
Rood: 230V (schakel)
Zwart: 230/380V (voeding)
Lichblauw: 0V (voeding 230/380)

Soms werd er klantspecifiek nog wel eens andere kleuren gebruikt.
Een doosje van 100m kost zo'n 15 á 20 euro.

en @Robbiedobbie

Dit zijn gangbare kleuren bij besturingskasten in Nederland.
In huis heb ik voor de 5, 12 en 24VDC kleuren genomen die niet vallen binnen bruin, blauw, geel/groen, zwart, zwart/wit en grijs van de 230VAC om verwarring te voorkomen.

Voor de draaddikte moet het kortsluitvast zijn ten opzichte van de voorzekering: de bedrading mag niet te heet worden door kortsluiting.
Hier is het allemaal 0,5mm2 voor de DC maar dat is ook steeds afgezekerd met 2A.

[Robbiedobbie]

Rob Z schreef op maandag 30 november 2020 @ 11:02:
[...]
Dit zijn gangbare kleuren bij besturingskasten in Nederland.
In huis heb ik voor de 5, 12 en 24VDC kleuren genomen die niet vallen binnen bruin, blauw, geel/groen, zwart, zwart/wit en grijs van de 230VAC om verwarring te voorkomen.

Vergeet groen en rood niet als je nog met oude kabels in huis zit
All joking aside, die kleuren zijn wel een goede tip (Ook dat eerdere antwoord op mijn vraag). Thanks!

Rob Z schreef op maandag 30 november 2020 @ 11:02:
[...]
Voor de draaddikte moet het kortsluitvast zijn ten opzichte van de voorzekering: de bedrading mag niet te heet worden door kortsluiting.
Hier is het allemaal 0,5mm2 voor de DC maar dat is ook steeds afgezekerd met 2A.

Hier wil ik zeker voor zorgen. Is het los afzekeren ook nodig als je 24v voeding bijv. nooit meer dan die 2A kan leveren en een kortsluitbeveiliging heeft?


Ik heb ondertussen een PLC via ebay aangeschaft ivm de leukere kosten. Toch heb ik ook eens een account bij wago aangevraagd. De prijzen daar zijn nog best interessant als je geen 2e hands ebay spul wil. Als je zelf je btw nog afdraagt komen ze in ieder geval goedkoper uit dan Conrad, en vaak ook goedkoper dan andere leveranciers. (Misschien ook wel logisch omdat zij zelf de fabrikant zijn)

Het account is natuurlijk vooral handig mocht een keer iets echt kapot gaan en ik met haast een ouder artikel nodig heb

[Antonius]

Robbiedobbie schreef op maandag 30 november 2020 @ 17:24:
Is het los afzekeren ook nodig als je 24v voeding bijv. nooit meer dan die 2A kan leveren en een kortsluitbeveiliging heeft?

Ja, altijd afzekeren.

Hoe weet jij zeker dat jouw 24V voeding echt nooit meer dan 2A kan leveren? Zonder zekering is er doorgaans wel meer uit te trekken en als je dat niet afzekert dan is het ofwel de voeding ofwel de bekabeling die de geest zal geven. Doorgaans gaat dat op een onveilige manier, iets met rookwolkjes e.d.

Op zijn minst een glaszekeringetje ertussen. Haal een doosje spare zekeringen in huis. Als je niet dagelijks met bedrading in de weer bent is een fuck up bij het aanleggen snel gebeurd. Je kunt dan zomaar een paar glaszekeringen verder zijn voordat je inderdaad alle draadjes goed hebt aangesloten. Ze kosten geen drol (zeker in vergelijking met een afgefikt huis, of erger).

[Robbiedobbie]

Toevallig iemand tips voor goedkope smeltzekering houders voor op een DIN-rail?

[MewBie]

Robbiedobbie schreef op maandag 30 november 2020 @ 18:57:
Toevallig iemand tips voor goedkope smeltzekering houders voor op een DIN-rail?

Die dingen zijn gewoon duur.

Als ze blauw mogen zijn:
https://nl.rs-online.com/...-terminal-blocks/7767889/

[Robbiedobbie]

MewBie schreef op maandag 30 november 2020 @ 19:19:
[...]

Die dingen zijn gewoon duur.

Als ze blauw mogen zijn:
https://nl.rs-online.com/...-terminal-blocks/7767889/

Zie ik het nou verkeerd of is dat een met ingebouwde zekering ipv een vervangbare glaszekering?

[Rob Z]

Robbiedobbie schreef op maandag 30 november 2020 @ 18:57:
Toevallig iemand tips voor goedkope smeltzekering houders voor op een DIN-rail?

Glaszekeringhouders zijn inderdaad duur.
Er bestaan ook enkelpolige automaten die voor DC geschikt zijn en dat kost bijna hetzelfde.

[Kanze]

Waar zekeren jullie die voedingen dan af? Als je alles zo moet doen zit je kast wel snel vol van dir zekeringen.

Als je een transformator achter een automaat van 6A plaatst kan er al weinig fout gaan denk ik.

[MewBie]

Robbiedobbie schreef op maandag 30 november 2020 @ 20:21:
[...]

Zie ik het nou verkeerd of is dat een met ingebouwde zekering ipv een vervangbare glaszekering?

Nee, RS online heeft ze verkeerd gelabeld zie ik nu
https://www.phoenixcontac...923047&library=usen&tab=1
PC zelf zegt feed through.

[MewBie]

Kanze schreef op maandag 30 november 2020 @ 20:58:
Waar zekeren jullie die voedingen dan af? Als je alles zo moet doen zit je kast wel snel vol van dir zekeringen.

Als je een transformator achter een automaat van 6A plaatst kan er al weinig fout gaan denk ik.

Waarom denk je dat industriele kasten altijd zo groot zijn, je verliest makkelijk 25% aan beschikbare ruimte aan alleen maar de voedingen, zekeringen en automaten.

Het hangt een beetje af van hoe je alles opbouwt, maar het volgende is niet ongebruikelijk:
1x hoofdschakelaar per inkomende voeding.
1x automaat per DC voeding en elke andere verbruiker als er meerdere 230V verbruikers op een inkomende voeding zitten.
Redundante DC voeding met diode module.
2x zekering (+ en -) per verbuiker in de kast.

[ Voor 26% gewijzigd door MewBie op 30-11-2020 23:39 ]

[Ethirty]

Als zo'n simpel zekeringblok al zoveel kost, dan snap ik wel waarom er goed geld zit in de industriële automatisering.

Sowieso snap ik weinig van prijzen, waarom is een 5 of 10A automaat duurder dan eentje van 16A? Als je elke DC voeding apart wil afzekeren, dan heeft een 16A automaat ook weinig nut.

[joostboot]

drled schreef op maandag 30 november 2020 @ 09:34:
[...]
Gebruik je nog steeds de DMX302 dimmers? Ik twijfel nog of ik deze wil gaan gebruiken, uiteindelijk stuur je wel 230V door een niet CE/CEBEC gekeurde component, de prijs is natuurlijk wel heel erg aantrekkelijk..

Ik durf de DMX302 niet aan te raden... Wij hebben er zelf 10 in de kast hangen. Daarvan zijn er al drie spontaan kapot gegaan (interne voeding) en twee zijn op vrij dramatische wijze naar het hiernamaals gegaan tijdens een kortsluiting en een overbelasting (bedrading in oude lamp die kortsloot na omvallen en iemand die de strijkbout aansloot op een gedimde wcd). Als je in een jaar tijd al >30% moet vervangen wordt de prijs ook al snel minder aantrekkelijk.

Bij de kortsluiting was de fet oid geëxplodeerd en lagen meerdere groepen eruit. Logisch resultaat opzich. Maar bij de overbelasting was de dimmer vastgesmolten in gesloten stand..! Hij bleef gewoon spanning geven en daar komt een geweldige elektronische rookwalm vanaf kan ik je vertellen. Het brandgevaar zal enigzins meevallen, maar toch..

Wat kun je daar van leren? Een heleboel: geen gedimde wcd, niet altijd voor de goedkoopste chinese rommel gaan, oude apparatuur bedrading eens controleren, echt alles afzekeren etc.

Overigens moet je goed opletten met de DMX302's, want er blijft gewoon spanning op de fase staan als je de lamp 'uitschakelt'. De dimmer zit namelijk op de neutraal, dus de fase behoud standaard zijn spanning. nu kun je in de toevoer de fase en neutraal wel omdraaien om dit te verhelpen...

Al met al hebben wij de dimmers voorlopig in ieder geval nog eens extra afgezekerd met een 2A smeltzekering per kanaal, terwijl we op zoek gaan naar passende vervanging voor onze 230V verlichting.