Domotica met plc's

[Kanze]

Vandaag heb ik de tijd genomen om mijn testopstelling te herbouwen voor het testen van het RS485 sensornetwerk en de interactie met DMX.

[sjoerd1980]

Ik heb net een hele reeks klemmen binnengekregen. Voornamelijk digitaal in / uit, maar ook een Dali klem erbij. Volgens mij moest hij van de spullen af, want ik heb totaal 16 klemmen besteld en er 20 gekregen ;-)

Wat I/O betreft is de PLC nu klaar en heb ik hem op de rail gezet. Voor mensen die de kast nog moeten bouwen: kies 15mm rail voor de plc. Ik heb alles in 7.5mm rail, maar de PLC modules vallen in de rail waardoor er dus geen ruimte meer is voor schroefkoppen.

[Kanze]

MichVw schreef op woensdag 19 februari 2020 @ 17:25:
[...]


Ik zie niet in waarom niet, die ATtiny zal dan gewoon meer modbus registers hebben die de PLC kan uitlezen..

Vandaag een bestelling geplaatst voor een devkit met een ATTiny3216 reeds op gemonteerd. Deze beschikt reeds over een onboard UART zodat er in geen bijkomende RS485 chip moet worden gebruikt zoals bij de Tiny85.

Voor mensen die kijken naar de Tinyxx16 serie van chips nog de waarschuwing dat deze een nieuwe interface gebruiken om geprogrammeerd te worden. Gelukkig is al werk verzet en bestaat een library voor je Arduino om de nieuwere attiny chips te programmeren over hun UPDI interface.

Terwijl dat in de post zit is de volgende stap om mijn 750-652 te laten communiceren met een DMX302. Dan weliswaar met DMX als link layer bovenop RS485 maar het gaat in deze hoofdzakelijk over het testen van de opzet van de onderliggende RS485 physical layer.

Wie eens een weekend wil verliezen raad ik het webportaal van Texas Instruments aan. Voor dit soort zaken is dat een wormhole waar je helemaal kan invallen.

http://www.ti.com/lit/an/slla272c/slla272c.pdf

https://www.renesas.com/e...-transceiver-tutorial.pdf

https://www.ccontrols.com/pdf/ExtV1N1.pdf

[MichVw]

Kanze schreef op zaterdag 22 februari 2020 @ 23:56:
[...]


Vandaag een bestelling geplaatst voor een devkit met een ATTiny3216 reeds op gemonteerd. Deze beschikt reeds over een onboard UART zodat er in geen bijkomende RS485 chip moet worden gebruikt zoals bij de Tiny85.

Voor mensen die kijken naar de Tinyxx16 serie van chips nog de waarschuwing dat deze een nieuwe interface gebruiken om geprogrammeerd te worden. Gelukkig is al werk verzet en bestaat een library voor je Arduino om de nieuwere attiny chips te programmeren over hun UPDI interface.

Terwijl dat in de post zit is de volgende stap om mijn 750-652 te laten communiceren met een DMX302. Dan weliswaar met DMX als link layer bovenop RS485 maar het gaat in deze hoofdzakelijk over het testen van de opzet van de onderliggende RS485 physical layer.

Wie eens een weekend wil verliezen raad ik het webportaal van Texas Instruments aan. Voor dit soort zaken is dat een wormhole waar je helemaal kan invallen.

http://www.ti.com/lit/an/slla272c/slla272c.pdf

https://www.renesas.com/e...-transceiver-tutorial.pdf

https://www.ccontrols.com/pdf/ExtV1N1.pdf

Interresant! Ik zit helaas nog niet zover op het vlak van de microcontroller voor het modbus netwerk als ik zelf zou willen.. vanwaar hebje die devkit besteld?

[Kanze]

MichVw schreef op zondag 23 februari 2020 @ 08:06:
[...]


Interresant! Ik zit helaas nog niet zover op het vlak van de microcontroller voor het modbus netwerk als ik zelf zou willen.. vanwaar hebje die devkit besteld?

https://www.tindie.com/pr...board-arduino-compatible/

Deze devkit is ontworpen door dezelfde persoon die de UPDI library heeft geschreven voor Arduino.

Mijn roadmap voor dit onderdeel ziet er zo uit;

1. Arduino UNO aansluiten als UPDI programmer via de bovengenoemde library
2. MODBUS RTU over RS485 communicatie opzetten tussen de Tiny3216 UART en een onboard serial interface op de PFC200 ofwel via 750-652
3. Uitzoeken welke sensors kunnen worden aangesloten op de Tiny3216. De bedoeling is temperatuur, douwpunt, lichtsterkte, luchtdruk, en infrarood beweging, te kunnen aansluiten
4. Het einddoel is dat dit geheel kan worden ingebouwd in een standaard inbouwpotje in de muur als een sensorkit. Daarvoor zal dan wel een custom PCB moeten worden ontwikkeld maar dat is ook niet echt een probleem

Als iemand weet heeft van een off-the-shelf oplossing die alle bovenstaande vakjes aanvinkt én over RS485 kan communiceren lees ik het ook graag.

[MichVw]

Kanze schreef op zondag 23 februari 2020 @ 09:15:
[...]


https://www.tindie.com/pr...board-arduino-compatible/

Deze devkit is ontworpen door dezelfde persoon die de UPDI library heeft geschreven voor Arduino.

Mijn roadmap voor dit onderdeel ziet er zo uit;

1. Arduino UNO aansluiten als UPDI programmer via de bovengenoemde library
2. MODBUS RTU over RS485 communicatie opzetten tussen de Tiny3216 UART en een onboard serial interface op de PFC200 ofwel via 750-652
3. Uitzoeken welke sensors kunnen worden aangesloten op de Tiny3216. De bedoeling is temperatuur, douwpunt, lichtsterkte, luchtdruk, en infrarood beweging, te kunnen aansluiten
4. Het einddoel is dat dit geheel kan worden ingebouwd in een standaard inbouwpotje in de muur als een sensorkit. Daarvoor zal dan wel een custom PCB moeten worden ontwikkeld maar dat is ook niet echt een probleem

Als iemand weet heeft van een off-the-shelf oplossing die alle bovenstaande vakjes aanvinkt én over RS485 kan communiceren lees ik het ook graag.

Ik volg je in die roadmap 😁. Ik denk niet dat er iets off-the-shelf bestaat en betwijfel ook of dat een "probleem" is. Als je voor custom PCB gaat kan je eventueel werken met JST connectoren (of andere) om de sensoren en microcontroller los te koppelen van elkaar.. kan je de PCB hergebruiken voor meerdere doeleinden (bv stand waterput, waterlekken opsporen, waterverbruik etc...)

Ik ga me ook een devkit bestellen.

[MichVw]

Femme schreef op dinsdag 17 september 2019 @ 12:21:
[...]


Ik heb zelf afgelopen zomer mijn meterkast een upgrade gegeven (in verband met de komst van 24 kWp aan PV-panelen) en daarbij alle groepen meetbaar gemaakt met behulp van Eastron SDM630MCT-2L energiemeters. Dat is een variant die twee 3-fase groepen meet met behulp van externe current transformers. Die CT's heb ik met behulp van een zelf geprint bracket geplaatst tussen de klemmenstrook waar de drie fases en nul op worden verdeeld vanaf de hoofdschakelaar naar de aardlekautomaten.

[Afbeelding: Brackets voor ct's]

Hier waren ze half verwerkt in de meterkast:

[Afbeelding: Nieuwe meterkast]

Ik heb een module gemaakt om Eastron-meters te integeren in IP-Symcon. De module maakt automatisch de benodigde variabelen aan (een stuk of 50 bij een 3-fase meter), voert modbus requests waarbij ik prioriteit kan geven aan bepaalde metrics zodat die vaker worden uitgelezen. Er zit ook nog een scheduler achter die prioriteit kan geven aan bepaalde meters op dezelfde bus zodat die relatief vaker worden uitgelezen. Op die manier kan ik met 14 3-fase meters op één bus bijna elke seconde de stroomsterkte en het vermogen uitlezen van de meter op de hoofdaansluiting terwijl alle andere meters ook nog regelmatig worden uitgelezen.

Dat zou snel genoeg moeten zijn om later nog wat slimme loadbalancing te kunnen doen op een laadpaal .

Ik lag alles naar Symcon die een eigen data store heeft. Van daaruit gaat het voor visualisatie direct naar Grafana om grafiekjes zoals de onderstaande te maken. Hiervoor heb ik een simple Json datasource voor Grafana geïmplementeerd in een module voor IP-Symcon. Het voordeel van deze oplossing voor mij is dat ik maar van twee services afhankelijk ben (Symcon en Grafana, die op hetzelfde machientje draaien).

[Afbeelding: Opwek en export 25 augustus]

Wat betreft je wens om iets krachtigers dan een single board computer te gebruiken: er zijn tegenwoordig echt leuke bordjes met goede performance en veel mogelijkheden. Zo heb ik nu thuis een Khadas VIM3 liggen die net zo compact is als een RPi, maar wel een hexacore heeft (4x A73 op 2,2GHz en 2x A53 op 1,8GHz) met 4GB RAM, 32GB eMMC geheugen en een m.2-slot voor een ssd. Dus snel, zuinig en betrouwbare opslag.

@Femme , ik ben er net ook in geslaagd om een hoop data uit te lezen via een Eastron energie meter.
Welke waarden log jij allemaal bij? Het zijn er echt wel een hoop (https://bg-etech.de/download/manual/SDM220Register.pdf, pagina 2). Ik vraag me af wat wat precies allemaal is, zeker alsje ook wilt gaan meten hoeveel je zonnepanelen enzo opbrengen..

[Femme]

MichVw schreef op maandag 24 februari 2020 @ 17:49:
[...]


@Femme , ik ben er net ook in geslaagd om een hoop data uit te lezen via een Eastron energie meter.
Welke waarden log jij allemaal bij? Het zijn er echt wel een hoop (https://bg-etech.de/download/manual/SDM220Register.pdf, pagina 2). Ik vraag me af wat wat precies allemaal is, zeker alsje ook wilt gaan meten hoeveel je zonnepanelen enzo opbrengen..

Hier is een stuk json dat ik gebruik als config van de modbusadressen voor m'n SDM630-module voor IP-Symcon:

code:

{
  "voltageL1":
  {
    "name"              : "L1 Voltage",
    "readAddress"       : 0,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "voltageL2":
  {
    "name"              : "L2 Voltage",
    "readAddress"       : 2,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "voltageL3":
  {
    "name"              : "L3 Voltage",
    "readAddress"       : 4,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "currentL1":
  {
    "name"              : "L1 Current",
    "readAddress"       : 6,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "currentL2":
  {
    "name"              : "L2 Current",
    "readAddress"       : 8,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "currentL3":
  {
    "name"              : "L3 Current",
    "readAddress"       : 10,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "activePowerL1":
  {
    "name"              : "L1 Power",
    "readAddress"       : 12,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "activePowerL2":
  {
    "name"              : "L2 Power",
    "readAddress"       : 14,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "activePowerL3":
  {
    "name"              : "L3 Power",
    "readAddress"       : 16,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "apparentPowerL1":
  {
    "name"              : "L1 Volt Amps",
    "readAddress"       : 18,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "apparentPowerL2":
  {
    "name"              : "L2 Volt Amps",
    "readAddress"       : 20,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "apparentPowerL3":
  {
    "name"              : "L3 Volt Amps",
    "readAddress"       : 22,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "reactivePowerL1":
  {
    "name"              : "L1 Volt Amps Reactive",
    "readAddress"       : 24,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "reactivePowerL2":
  {
    "name"              : "L2 Volt Amps Reactive",
    "readAddress"       : 26,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "reactivePowerL3":
  {
    "name"              : "L3 Volt Amps Reactive",
    "readAddress"       : 28,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "powerFactorL1":
  {
    "name"              : "L1 Power Factor",
    "readAddress"       : 30,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "powerFactorL2":
  {
    "name"              : "L2 Power Factor",
    "readAddress"       : 32,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "powerFactorL3":
  {
    "name"              : "L3 Power Factor",
    "readAddress"       : 34,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "phaseAngleL1":
  {
    "name"              : "L1 Phase Angle",
    "readAddress"       : 36,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 25000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "phaseAngleL2":
  {
    "name"              : "L2 Phase Angle",
    "readAddress"       : 38,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 25000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "phaseAngleL3":
  {
    "name"              : "L3 Phase Angle",
    "readAddress"       : 40,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 25000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "currentTotal":
  {
    "name"              : "Total current",
    "readAddress"       : 48,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "activePowerTotal":
  {
    "name"              : "Total power",
    "readAddress"       : 52,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "apparentPowerTotal":
  {
    "name"              : "Total VoltAmps",
    "readAddress"       : 56,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "reactivePowerTotal":
  {
    "name"              : "Total VoltAmps Reactive",
    "readAddress"       : 60,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "powerFactorTotal":
  {
    "name"              : "Total power factor",
    "readAddress"       : 62,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 25000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 33
  },
  "phaseAngleTotal":
  {
    "name"              : "Total Phase Angle",
    "readAddress"       : 66,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 25000,
    "emulateStatus"     : true,
    "priority"          : 20
  },
  "frequency":
  {
    "name"              : "Frequency of supply voltages",
    "readAddress"       : 70,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 25000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 10
  },
  "energyImported":
  {
    "name"              : "Import Wh since last reset",
    "readAddress"       : 72,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 50
  },
  "energyExported":
  {
    "name"              : "Export Wh since last reset",
    "readAddress"       : 74,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 5
  },
  "reactiveEnergyImported":
  {
    "name"              : "Import VArh since last reset",
    "readAddress"       : 76,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 10
  },
  "reactiveEnergyExported":
  {
    "name"              : "Export VArh since last reset",
    "readAddress"       : 78,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 10
  },
  "currentNeutral":
  {
    "name"              : "Neutral current",
    "readAddress"       : 224,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 5000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 100
  },
  "totalHarmonicVoltageDistortionL1":
  {
    "name"              : "L1/N Volts THD",
    "readAddress"       : 234,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 20000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "totalHarmonicVoltageDistortionL2":
  {
    "name"              : "L2/N Volts THD",
    "readAddress"       : 236,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 20000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "totalHarmonicVoltageDistortionL3":
  {
    "name"              : "L3/N Volts THD",
    "readAddress"       : 238,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 20000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "totalHarmonicCurrentDistortionL1":
  {
    "name"              : "L1 Current THD",
    "readAddress"       : 240,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 20000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "totalHarmonicCurrentDistortionL2":
  {
    "name"              : "L2 Current THD",
    "readAddress"       : 242,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 20000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "totalHarmonicCurrentDistortionL3":
  {
    "name"              : "L3 Current THD",
    "readAddress"       : 244,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 20000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "totalHarmonicVoltageDistortion":
  {
    "name"              : "Average Line to Neutral Volts THD",
    "readAddress"       : 248,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 20000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "totalHarmonicCurrentDistortion":
  {
    "name"              : "Average Line Current THD",
    "readAddress"       : 250,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 20000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 20
  },
  "maximumCurrentL1":
  {
    "name"              : "L1 Maximum Current Demand",
    "readAddress"       : 264,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 5
  },
  "maximumCurrentL2":
  {
    "name"              : "L2 Maximum Current Demand",
    "readAddress"       : 266,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 5
  },
  "maximumCurrentL3":
  {
    "name"              : "L3 Maximum Current Demand",
    "readAddress"       : 268,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 5
  },
  "energyConsumed":
  {
    "name"              : "Total kWh",
    "readAddress"       : 342,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 10
  },
  "reactiveEnergyConsumed":
  {
    "name"              : "Total kVARh",
    "readAddress"       : 344,
    "writeAddress"      : 0,
    "dataType"          : 7,
    "readFunctionCode"  : 4,
    "writeFunctionCode" : 0,
    "pollingInterval"   : 60000,
    "emulateStatus"     : true,
    "factor"            : 0,
    "priority"          : 10
  }
}

Dus de spanning, stroomsterkte, actief vermogen, schijnbaar vermogen, reactief vermogen, arbeidsfactor, faseverschuiving, frequentie, import en export van actieve en reactieve energie en harmonische vervorming.

Ik poll niet alle adressen met dezelfde interval maar geeft prioriteit aan de metrics die ik het belangrijkst vind (zoals vermogen en stroomsterkte) zodat die voor wat betreft de hoofdaansluiting nagenoeg realtime binnenkomen. Ik heb hier zeven SDM630MCT-2L dual load 3-fase meters op een enkele rs485 bus.

[cotton_eye_joe]

Leuk topic, gaat op volgen

Ben al een tijdje bezig met uitzoeken welk systeem ik in huis wil toepassen. Heb in mijn vorige woning wat geëxperimenteerd met draadloze oplossingen van kaku en zwave (drama) maar dat draait mij niet stabiel genoeg. In het donker de verlichting niet aan kunnen krijgen wekt behoorlijk wat frustratie op...

Ik heb recent een een oude woning gekocht die van boven tot onder gerenoveerd moet worden en dus is er meteen de kans op alles bedraad aan te leggen. Heb nu een kleine test draaien die de verlichting in de woonkamer, hal en oprit aanstuurt. Momenteel wordt de eerste helft van de bovenverdieping (2 slaapkamers en badkamer) verbouwd waar straks het eerste deel van het systeem (verlichting en zoneregeling van de cv) moet gaan draaien.

Voorlopig draai ik nog op een raspi met codesys, dit werkt tot nu toe perfect. Heb wel twijfel of dit door de jaren heen blijft draaien, om die reden hier een bericht geplaatst om advies te vragen...

Aangesloten op de raspi zijn een beckhoff EK1100 via ethercat en een Ali-Express tcp modbus io module. Laatste module aangeschaft om mee te testen en heeft nooit een misse slag gehad. 73 euro voor 16DO / 8DI, geen geld Nadeel is wel dat deze modules niet uit te breiden zijn, als je meer io nodig hebt moet je een complete module bij plaatsen.

Ik zie dat veel mensen hier een wago gebruiken. Zelf heb ik geen ervaring met wago, zou iemand mij kunnen adviseren welk type ik zou moeten toepassen?

Wat ik nodig heb:

Programmeren in codesys 3.5
Ethercat
Modbus tcp
WebVisu


Alvast bedankt

[MichVw]

cotton_eye_joe schreef op woensdag 26 februari 2020 @ 12:38:
Leuk topic, gaat op volgen

Ben al een tijdje bezig met uitzoeken welk systeem ik in huis wil toepassen. Heb in mijn vorige woning wat geëxperimenteerd met draadloze oplossingen van kaku en zwave (drama) maar dat draait mij niet stabiel genoeg. In het donker de verlichting niet aan kunnen krijgen wekt behoorlijk wat frustratie op...

Ik heb recent een een oude woning gekocht die van boven tot onder gerenoveerd moet worden en dus is er meteen de kans op alles bedraad aan te leggen. Heb nu een kleine test draaien die de verlichting in de woonkamer, hal en oprit aanstuurt. Momenteel wordt de eerste helft van de bovenverdieping (2 slaapkamers en badkamer) verbouwd waar straks het eerste deel van het systeem (verlichting en zoneregeling van de cv) moet gaan draaien.

Voorlopig draai ik nog op een raspi met codesys, dit werkt tot nu toe perfect. Heb wel twijfel of dit door de jaren heen blijft draaien, om die reden hier een bericht geplaatst om advies te vragen...

Aangesloten op de raspi zijn een beckhoff EK1100 via ethercat en een Ali-Express tcp modbus io module. Laatste module aangeschaft om mee te testen en heeft nooit een misse slag gehad. 73 euro voor 16DO / 8DI, geen geld Nadeel is wel dat deze modules niet uit te breiden zijn, als je meer io nodig hebt moet je een complete module bij plaatsen.

Ik zie dat veel mensen hier een wago gebruiken. Zelf heb ik geen ervaring met wago, zou iemand mij kunnen adviseren welk type ik zou moeten toepassen?

Wat ik nodig heb:

Programmeren in codesys 3.5
Ethercat
Modbus tcp
WebVisu


Alvast bedankt

Hey!

Ik zou een PFC200 aanraden, als je wat zoekt op het internet ebay.de & ebay.com kan je er één vinden die sterk afgeprijst staat. Normale prijs is een kleine €400 maar onlangs ook één op de kop getikt voor ca. €220.

Mocht je interesse hebben, dit is een git repo met een Codesys 3.5 project gemaakt voor home automation purposes die meteen ook MQTT capabel is voor bv integratie met Domoticz, HomeAssistant etc..
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Er zijn al meerdere mensen hier die er gebruik van maken en er geen problemen mee ondervinden, geen nood dus om het warme water terug opnieuw uit te vinden!

[Ethirty]

Kan iemand mij in een paar korte woorden uitleggen wat nu het voordeel is van een full-blown (Wago) PLC boven een smart relay als een Siemens Logo! of Eaton Easy E4?

Wat doet een PLC meer of beter dan een smart relay?

[ Voor 4% gewijzigd door Ethirty op 26-02-2020 16:37 ]

[MewBie]

Ethirty schreef op woensdag 26 februari 2020 @ 16:34:
Kan iemand mij in een paar korte woorden uitleggen wat nu het voordeel is van een full-blown (Wago) PLC boven een smart relay als een Siemens Logo! of Eaton Easy E4?

Wat doet een PLC meer of beter dan een smart relay?

Voor thuisgebruik zal er niet veel voordeel zijn, buiten het feit dat als je voor industriele PLCs gaat je waarschijnlijk makkelijker hulp kan vinden voor een probleem in je codesys dan voor Logo! of iets anders.

Kijk je wat verder dan kom je uit op dingen als modulariteit, de hoeveelheid beschikbare types IO
en hoeveel IO een enkele PLC aan kan.
Maar ook in industriele omgevingen kom je wel eens een Logo! tegen. Laatst moest ik wat data in de documentatie van een leverancier opzoeken en zag dat er een Logo! gebruikt was, dat was wel een "Huh... oh ok..." momentje.

Veel mensen die voor thuis een volwaardige PLC kiezen zullen dat doen omdat ze al bekend zijn met codesys of omdat het voor hun makkelijker is om hulp te krijgen voor codesys.

[MichVw]

MewBie schreef op woensdag 26 februari 2020 @ 18:15:
[...]

Voor thuisgebruik zal er niet veel voordeel zijn, buiten het feit dat als je voor industriele PLCs gaat je waarschijnlijk makkelijker hulp kan vinden voor een probleem in je codesys dan voor Logo! of iets anders.

Kijk je wat verder dan kom je uit op dingen als modulariteit, de hoeveelheid beschikbare types IO
en hoeveel IO een enkele PLC aan kan.
Maar ook in industriele omgevingen kom je wel eens een Logo! tegen. Laatst moest ik wat data in de documentatie van een leverancier opzoeken en zag dat er een Logo! gebruikt was, dat was wel een "Huh... oh ok..." momentje.

Veel mensen die voor thuis een volwaardige PLC kiezen zullen dat doen omdat ze al bekend zijn met codesys of omdat het voor hun makkelijker is om hulp te krijgen voor codesys.

Ik ken de LOGO software niet maar in welke mate integreren die dingen met open protocollen naar andere software zoals bijvoorbeeld een home assistant, domoticz, openhab?
Met een PLC die Codesys 3.5 ondersteund heb je op dat vlak opties, geen idee van een logo. Idem voor netwerking met modbus rtu/tcp etc... allemaal mogelijk met een PLC, geen idee van een LOGO...

[sjoerd1980]

Afgelopen dagen zijn er op Ebay toch twee 750-652 klemmen (configureerbare seriële klem, die afhankelijk van firmware ook DMX kan draaien) verkocht voor onder de E 50. Voor dat bedrag vind ik het prima acceptabel.

Er zit altijd wel een foto van de zijkant bij met typenummer etc. Is uit een van de nummers af te leiden welke firmware je kan verwachten? Ik verwacht dat ik aan firmware 3 genoeg zal hebben (kan DMX sturen), maar 6 is natuurlijk helemaal veilig.

[Ethirty]

MichVw schreef op woensdag 26 februari 2020 @ 20:37:
[...]


Ik ken de LOGO software niet maar in welke mate integreren die dingen met open protocollen naar andere software zoals bijvoorbeeld een home assistant, domoticz, openhab?
Met een PLC die Codesys 3.5 ondersteund heb je op dat vlak opties, geen idee van een logo. Idem voor netwerking met modbus rtu/tcp etc... allemaal mogelijk met een PLC, geen idee van een LOGO...

Modbus TCP kan en via een Siemens S7 PLC library kan je het ding ook aan HomeAssistant hangen.

Programmeren is bijna kinderspel door gewoon blokjes aan elkaar te knopen. IO is misschien minder schaalbaar, maar zat voor de meeste huizen denk ik.

[MewBie]

MichVw schreef op woensdag 26 februari 2020 @ 20:37:
[...]


Ik ken de LOGO software niet maar in welke mate integreren die dingen met open protocollen naar andere software zoals bijvoorbeeld een home assistant, domoticz, openhab?
Met een PLC die Codesys 3.5 ondersteund heb je op dat vlak opties, geen idee van een logo. Idem voor netwerking met modbus rtu/tcp etc... allemaal mogelijk met een PLC, geen idee van een LOGO...

Zo te zien ondersteunen de Logo's modbus tcp als ze een ethernet port hebben.

[THM0]

sjoerd1980 schreef op woensdag 26 februari 2020 @ 21:11:
Afgelopen dagen zijn er op Ebay toch twee 750-652 klemmen (configureerbare seriële klem, die afhankelijk van firmware ook DMX kan draaien) verkocht voor onder de E 50. Voor dat bedrag vind ik het prima acceptabel.

Er zit altijd wel een foto van de zijkant bij met typenummer etc. Is uit een van de nummers af te leiden welke firmware je kan verwachten? Ik verwacht dat ik aan firmware 3 genoeg zal hebben (kan DMX sturen), maar 6 is natuurlijk helemaal veilig.

Ja dat kan je zien. Als je bijv de module die voor 45.01 verkocht is neemt, daar staat op:
15190601.
Dat betekent: geproduceerd in week 15 van 2019, firmware v6 en fw loader v1. Dat is dus een versie die 512 DMX kanalen kan sturen.

[cotton_eye_joe]

MichVw schreef op woensdag 26 februari 2020 @ 16:24:
[...]

Ik zou een PFC200 aanraden, als je wat zoekt op het internet ebay.de & ebay.com kan je er één vinden die sterk afgeprijst staat. Normale prijs is een kleine €400 maar onlangs ook één op de kop getikt voor ca. €220.

Ah kijk daar heb ik wat aan. Prijs valt mee en de prijs voor de codesys licensie is ook goed te doen en dan heb ik dezelfde functies die ik nu ook heb. Thx!

MichVw schreef op woensdag 26 februari 2020 @ 16:24:
[...]
Mocht je interesse hebben, dit is een git repo met een Codesys 3.5 project gemaakt voor home automation purposes die meteen ook MQTT capabel is voor bv integratie met Domoticz, HomeAssistant etc..
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Er zijn al meerdere mensen hier die er gebruik van maken en er geen problemen mee ondervinden, geen nood dus om het warme water terug opnieuw uit te vinden!

Ik ga hier zeker even naar kijken, bedankt

Domoticz heb ik nooit bestudeerd maar kan interessant zijn

HomeAssistant ben ik iets te paranoïde voor, ik vertrouw het gewoon niet... Het is al vaker voorgekomen dat ik thuis alleen maar ergens over praat en dat er vervolgens reclame over getoond wordt. Heb mijn google speakers daarom de deur uitgedaan

De bedoeling is ook om met het domotica systeem zoveel mogelijk offline te blijven en anders volledige controle te hebben over de data. Deels privacy maar ook omdat ik vrij afgelegen woon en geen stabiele internet verbinding heb, in ieder geval niet stabiel genoeg voor 'cruciale' taken zoals het schakelen van verlichting

[thomke]

cotton_eye_joe schreef op donderdag 27 februari 2020 @ 09:19:


HomeAssistant ben ik iets te paranoïde voor, ik vertrouw het gewoon niet... Het is al vaker voorgekomen dat ik thuis alleen maar ergens over praat en dat er vervolgens reclame over getoond wordt. Heb mijn google speakers daarom de deur uitgedaan

Ik vermoed dat je HomeAssistant en Google assistant door elkaar haalt...
HomeAssistant is open source home automation software (net zoals domoticz of openhab) en heeft niets te zien met de google assistant
Via de google assistant (dus de google speakers) kan je indien gewenst wel een verbinding maken met domotica software om deze via spraak aan te sturen.

Ook is het al bewezen dat een google assistent u niet afluistert en hierop zijn reclame zal baseren.
(ik kan hier niet direct een bron van weergeven)

Het kan door de sterkte van de google algoritmes zijn dat u het gevoel hebt dat u afgeluisterd wordt, maar dit zal niet zo zijn (toch niet via de google assistent..
(ik dacht wel eens gelezen te hebben dat er tv's met ingebouwde microfoon wel gesprekken afluisteren om gerichte reclame te geven.. maar ik kan mis zijn)

[thomke]

thomke schreef op donderdag 27 februari 2020 @ 12:21:
[...]


Ik vermoed dat je HomeAssistant en Google assistant door elkaar haalt...
HomeAssistant is open source home automation software (net zoals domoticz of openhab) en heeft niets te zien met de google assistant
Via de google assistant (dus de google speakers) kan je indien gewenst wel een verbinding maken met domotica software om deze via spraak aan te sturen.

Ook is het al bewezen dat een google assistent u niet afluistert en dus niet hierop zijn reclame zal baseren.
(ik kan hier niet direct een bron van weergeven)

Het kan door de sterkte van de google algoritmes zijn dat u het gevoel hebt dat u afgeluisterd wordt, maar dit zal niet zo zijn (toch niet via de google assistent..
(ik dacht wel eens gelezen te hebben dat er tv's met ingebouwde microfoon wel gesprekken afluisteren om gerichte reclame te geven.. maar ik kan mis zijn)

[cotton_eye_joe]

thomke schreef op donderdag 27 februari 2020 @ 12:21:
[...]


Ik vermoed dat je HomeAssistant en Google assistant door elkaar haalt...
HomeAssistant is open source home automation software (net zoals domoticz of openhab) en heeft niets te zien met de google assistant
Via de google assistant (dus de google speakers) kan je indien gewenst wel een verbinding maken met domotica software om deze via spraak aan te sturen.

Ah ok, mijn fout. Google home + Google assistant was voor mij homeAssistant. Weer wat geleerd

Wat zou het voordeel zijn om naast de logica in de plc een koppeling te maken met bijvoorbeeld HomeAssistant? Ben mijn onderzoek naar de 'kant en klare' software oplossingen al een tijdje geleden gestopt moet ik eerlijk bekennen. Ik kwam altijd uit op kan niet wat ik wil, instabiel, te dure hardware etc.

thomke schreef op donderdag 27 februari 2020 @ 12:21:
[...]

Ook is het al bewezen dat een google assistent u niet afluistert en hierop zijn reclame zal baseren.
(ik kan hier niet direct een bron van weergeven)

Het kan door de sterkte van de google algoritmes zijn dat u het gevoel hebt dat u afgeluisterd wordt, maar dit zal niet zo zijn (toch niet via de google assistent..

Kun je zeggen maar ik geloof er niks van

[bartvb]

Ik ben bezig met het verzamelen van hardware voor onze woning in aanbouw We gaan hoofdzakelijk KNX gebruiken, wellicht Loxone voor wat extra logica/visualisatie en Wago voornamelijk voor extra input/output en communicatie met b.v. RS-485, SMI en Dali.


Nu lijken de PFC200 serie maar ook de 750-889 aardige kanshebbers (tweede hands dan). Ik krijg alleen niet helder wat nu precies het voordeel van de 750-889 (een 750 PLC met KNX ondersteuning) is tov een andere 750-serie PLC? Iemand een idee?

Het prijsverschil tussen de PFC200 en 750-serie is ook weer niet enorm. Verstandig om gewoon voor de PFC200 te gaan? Kan die evenveel met KNX als die 750-889?

[Femme]

cotton_eye_joe schreef op donderdag 27 februari 2020 @ 13:04:
[...]

Ah ok, mijn fout. Google home + Google assistant was voor mij homeAssistant. Weer wat geleerd

Wat zou het voordeel zijn om naast de logica in de plc een koppeling te maken met bijvoorbeeld HomeAssistant? Ben mijn onderzoek naar de 'kant en klare' software oplossingen al een tijdje geleden gestopt moet ik eerlijk bekennen. Ik kwam altijd uit op kan niet wat ik wil, instabiel, te dure hardware etc.

Ik gebruik twee Wago plc's voor I/O (via Modbus en MQTT). Er draait alleen code op om MQTT berichtjes uit te serveren. De logica draait voornamelijk in zelfgeschreven modules en deels in scripts in IP-Symcon op een single board computer (momenteel een Odroid N2).

Plc's super super stabiel maar hebben ook wel veel nadelen voor gebruik in smart homes:

• De leercurve is stijl en er is weinig online informatie voorhanden vergeleken met gangbare programmeertalen zoals javascript, python en php.
• Ik vind de CoDeSys 2.3 ontwikkelomgeving voor mijn wat oudere plc's echt een draak om mee te werken. Je gaat 30 jaar terug in de tijd vergeleken met IDE's zoals PHPStorm/WebStorm. Hopelijk is CoDeSys 3.5 beter. Nog een nadeel: alleen beschikbaar voor Windows. Geen MacOS, geen Linux.
• Het inrichten van logica is mijn inziens vrij tijdrovend. Hoe ik het doe in IP-Symcon is dat ik modules bouw voor bijvoorbeeld functionaliteit zoals een lichtcontroller of thermostaat. Als die module er is eenmaal is kan ik met een paar kliks een instantie toevoegen voor een bepaalde ruimte en die configureren zonder code aan te moeten raken.
• De visualisatie is ruk. Geen fatsoenlijke webapp die je makkelijk kunt inrichten, geen mobiele apps.
• Data logging mag je ook lekker zelf bouwen. De hardware en software van een plc is er niet geschikt om er database op te draaien.
• Beperkte hardwareondersteuning vergeleken met oplossingen zoals Home Assistant of IP-Symcon. Met die laatsten kun je out of the box met heel veel verschillende protocollen communiceren en kun je tevens gebruikmaken van allerlei modules of plugins om specifieke diensten of apparaten te integreren in je systeem.

Ik heb ervoor gekozen om alles modulair in IP-Symcon op te zetten. Ik kan ontwikkelen in een taal (PHP) en design patterns die ik gewend ben. Beheer is makkelijker via een webbased management console en je kunt er makkelijk een app mee inrichten voor visualisatie en bediening. Het systeem is event driven wat mijn inziens beter past bij wat er in een woning gebeurt dan een cyclisch systeem zoals een plc. Je doet pas iets op het moment dat er iets aan de state van je huis verandert.

[Ethirty]

Mja, dan blijf ik voor veel gebruikers toch terugkomen bij de vraag: waarom moeilijk doen met een full-blown PLC?

Een paar blokjes slepen in de Siemens Logo software en je verlichting en HVAC zijn klaar. Of je tuinberegening. Siemens biedt kan en klare voorbeelden ter inspiratie.
Er zit een webservertje in, je kan koppelen met HomeAssistant en zo MQTT doen en je kan een heel scala aan HMI's van Siemens eraan hangen als je per se ook een touchscreen voor bediening wil.

Kijk, als PLC's of programmeren je vak/hobby is, dan is het wellicht te simpel. En ook veel IO is wel een beetje een ding. Maar @Oystein heeft volgens mij al laten zien dat je prima kan schalen.

[Kanze]

Ethirty schreef op donderdag 27 februari 2020 @ 15:40:
Mja, dan blijf ik voor veel gebruikers toch terugkomen bij de vraag: waarom moeilijk doen met een full-blown PLC?

Een paar blokjes slepen in de Siemens Logo software en je verlichting en HVAC zijn klaar. Of je tuinberegening. Siemens biedt kan en klare voorbeelden ter inspiratie.
Er zit een webservertje in, je kan koppelen met HomeAssistant en zo MQTT doen en je kan een heel scala aan HMI's van Siemens eraan hangen als je per se ook een touchscreen voor bediening wil.

Bovendien werken die producten onder de motorkap gewoon evenzeer met de onderdelen en principes die je in dit topic tegenkomt.

Kijk, als PLC's of programmeren je vak/hobby is, dan is het wellicht te simpel. En ook veel IO is wel een beetje een ding. Maar @Oystein heeft volgens mij al laten zien dat je prima kan schalen.

Je kan hoegenaamd alles via Loxone, NIKO, LOGO, KNX doen wat je in een huis nodig hebt. Maar als je een paar pagina's terugleest zie je dat mensen bijvoorbeeld volop bezig zijn met het ontwikkelen van een eigen inbouw-sensorkit op basis van microcontrollers die dan praten met de PLC via rs485. Dat kan perfect met off-the-shelf oplossingen, but where's the fun in that

@Femme haalt in zijn post wel wat punten aan die kloppen. Ik wil daar enkel de kanttekening bij maken dat die leercurve ook positief kan zijn. Zelf heb ik ondertussen bijzonder veel bijgeleerd en heeft dit project mij ertoe aangezet echt nieuwe gebieden van kennis in elektronica te ontdekken.

[ Voor 4% gewijzigd door Kanze op 27-02-2020 15:49 ]

[bartvb]

@Femme heeft idd een flink aantal punten die mij ook tegenhouden om de PLC in te zetten als meer dan een doorgeefluik. Vooral het programmeren van de PLC en de manier van denken daarachter staat echt ver af van hoe ik hobbymatig mijn woning in wil richten. Is te low-level voor mijn doeleinden.
Je leert er zeker een hoop van maar ik heb inmiddels al wel genoeg geleerd van dit hele bouwproces De extra energie stop ik dan liever in het verbeteren van iets als Node Red of HomeAssistant.

@Ethirty Heel suf maar een belangrijk punt bij mij zijn toch wel de looks Een Wago PLC ziet er toch wel een stuk toffer uit dan een Logo, no offence
Logo! was hier jaren terug waar ik alles in wilde bouwen, voor KNX een optie werd (budget) of Loxone (bestond nog niet). Misschien toch nog eens goed naar kijken. Voordeel van Wago is dat je prettiger kan aansluiten (steekverbindingen), het is overzichtelijker en wat professioneler en je kan 2e hands vrij goedkoop veel input/output kopen. Maar nog niet gekeken hoe dat laatste bij Siemens Logo zit. Nadeel van Siemens Logo is wel dat er (voor zover ik weet) geen ondersteuning voor SMI (aansturen van onze zonwering) beschikbaar is. Wago heeft dat wel en voor veel minder geld dan een KNX oplossing.

[ Voor 8% gewijzigd door bartvb op 27-02-2020 16:09 ]

[Ethirty]

Kanze schreef op donderdag 27 februari 2020 @ 15:47:
[...]

Je kan hoegenaamd alles via Loxone, NIKO, LOGO, KNX doen wat je in een huis nodig hebt. Maar als je een paar pagina's terugleest zie je dat mensen bijvoorbeeld volop bezig zijn met het ontwikkelen van een eigen inbouw-sensorkit op basis van microcontrollers die dan praten met de PLC via rs485. Dat kan perfect met off-the-shelf oplossingen, but where's the fun in that

@Femme haalt in zijn post wel wat punten aan die kloppen. Ik wil daar enkel de kanttekening bij maken dat die leercurve ook positief kan zijn. Zelf heb ik ondertussen bijzonder veel bijgeleerd en heeft dit project mij ertoe aangezet echt nieuwe gebieden van kennis in elektronica te ontdekken.

Oh, ik ben het helemaal met je eens hoor. Ik heb sowieso al een hoop geleerd over industriële automatisering. Heel wat anders dan servers en werkplekken.

Het gaat me ook meer om de algemene discussie als vervanging voor populaire wireless producten.Niet iedereen, inclusief mijzelf gaat een PLC redden.

bartvb schreef op donderdag 27 februari 2020 @ 15:59:

@Ethirty Heel suf maar een belangrijk punt bij mij zijn toch wel de looks Een Wago PLC ziet er toch wel een stuk toffer uit dan een Logo, no offence
Logo! was hier jaren terug waar ik alles in wilde bouwen, voor KNX een optie werd (budget) of Loxone (bestond nog niet). Misschien toch nog eens goed naar kijken. Voordeel van Wago is dat je prettiger kan aansluiten (steekverbindingen), het is overzichtelijker en wat professioneler en je kan 2e hands vrij goedkoop veel input/output kopen. Maar nog niet gekeken hoe dat laatste bij Siemens Logo zit.

Nog niet heel veel 2e hands IO modules gespot. En iets als een Easy E4 heeft veel meer IO mogelijkheden, maar is nog zo nieuw dat die sowieso nog slecht te vinden zijn.

Maar voor mijn doelen straks is een echte PLC toch iets te complex. En als ik dan dit soort voorbeelden zie dan ben ik al happy als ik het er straks zo bij heb staan. HomeAssistant vind ik ook niet het makkelijkst om onder de knie te krijgen heb ik gemerkt.

[MichVw]

Ik heb toen ik aan dit hele gebeuren ook gekeken naar LOGO maar heb toen (verleden tijd dus kan verandert zijn) geconcludeerd dat er niet genoeg vrijheid was. Ik vond geen mogelijkheid om events te gaan uitsturen vanuit de LOGO aan de hand van een open source protocol (belangrijk als je wilt gaan integreren). Ook naar hardware had ik de indruk dat er meer beperkingen waren. De Wago 750 reeks heeft nu eenmaal enorm veel verschillende IO modules.

Akkoord dat er een leercurve bij Codesys 3.5 komt kijken maar je hebt er ook de meeste vrijheid..
En die leercurve kan sterk ingeperkt worden als je hier gaat van gebruik maken: https://github.com/Michie...e/HomeAutomation.CoDeSys3 (ik weet het, ik maak veel reclame).

[UglyDinosaur]

Ik heb een vervelend probleem met mijn PFC200...

Na een tijdje stopt hij gewoon met werken. Alles uitgangen vallen uit en hij reageert niet meer. Enige dat helpt is de voeding er af halen en zo terug opstarten.

Aangezien mijn hele verlichting en verwarming er op draait zeer vervelend...

Iemand misschien een idee waar ik moet beginnen zoeken? Ik draai alles vanop de SD kaart omdat ik problemen kreeg met een vol geheugen in het verleden... Ik was al aan het denken dat dat misschien niet de meest gezonde situatie is...

[Ethirty]

Misschien een open deur, maar als het geheugen vol zat lijkt me dat je wat te veel vraagt van je PLC.

Heb je al een nieuwe SD kaart getest? Die dingen gaan wel een stuk als je ze actief gebruikt.

[UglyDinosaur]

Ethirty schreef op donderdag 27 februari 2020 @ 21:30:
Misschien een open deur, maar als het geheugen vol zat lijkt me dat je wat te veel vraagt van je PLC.

Heb je al een nieuwe SD kaart getest? Die dingen gaan wel een stuk als je ze actief gebruikt.

Ik had de indruk dat dat vooral was omdat de gemeten temperaturen gelogd werden. Dat heb ik (volgens mij) allemaal uitgezet.

Zou het kunnen dat ik simpelweg door verlichting en HVAC al op de limieten van de PLC zit?

De belasting van de PLC is zo te zien ook wel zeer hoog...

[ Voor 10% gewijzigd door UglyDinosaur op 27-02-2020 21:41 ]

[Ethirty]

Als je veel logt zou ik zeker eerst een nieuwe SD kaart testen, het loggen uitzetten en dan verder zoeken.

Je design zou de betrouwbaarheid van de basis aansturing voorop moeten hebben staan, de rest is extra.

[Kanze]

benbam schreef op donderdag 27 februari 2020 @ 21:10:
Ik heb een vervelend probleem met mijn PFC200...

Na een tijdje stopt hij gewoon met werken. Alles uitgangen vallen uit en hij reageert niet meer. Enige dat helpt is de voeding er af halen en zo terug opstarten.

Aangezien mijn hele verlichting en verwarming er op draait zeer vervelend...

Iemand misschien een idee waar ik moet beginnen zoeken? Ik draai alles vanop de SD kaart omdat ik problemen kreeg met een vol geheugen in het verleden... Ik was al aan het denken dat dat misschien niet de meest gezonde situatie is...

Blijft die 100% CPU usage constant zo? Met welke frequentie schrijf je data naar de SD kaart?

[UglyDinosaur]

Blijft die 100% CPU usage constant zo? Met welke frequentie schrijf je data naar de SD kaart?

Net nog eens gekeken en nu draait hij toch ook de hele tijd tegen de 90%.

Hoe vaak hij naar de sd kaart schrijft weet ik niet, maar aangezien ik het zo heb aangepast heb dat alles vanaf de SD kaart gaat ipv het interne geheugen kan dat best wel eens veel zijn.

Ik ga al eens proberen binnenkort om de cycle time van de taken wat te vergroten...

[cotton_eye_joe]

Femme schreef op donderdag 27 februari 2020 @ 14:28:
[...]


Ik gebruik twee Wago plc's voor I/O (via Modbus en MQTT). Er draait alleen code op om MQTT berichtjes uit te serveren. De logica draait voornamelijk in zelfgeschreven modules en deels in scripts in IP-Symcon op een single board computer (momenteel een Odroid N2).

Plc's super super stabiel maar hebben ook wel veel nadelen voor gebruik in smart homes:

• De leercurve is stijl en er is weinig online informatie voorhanden vergeleken met gangbare programmeertalen zoals javascript, python en php.
• Ik vind de CoDeSys 2.3 ontwikkelomgeving voor mijn wat oudere plc's echt een draak om mee te werken. Je gaat 30 jaar terug in de tijd vergeleken met IDE's zoals PHPStorm/WebStorm. Hopelijk is CoDeSys 3.5 beter. Nog een nadeel: alleen beschikbaar voor Windows. Geen MacOS, geen Linux.
• Het inrichten van logica is mijn inziens vrij tijdrovend. Hoe ik het doe in IP-Symcon is dat ik modules bouw voor bijvoorbeeld functionaliteit zoals een lichtcontroller of thermostaat. Als die module er is eenmaal is kan ik met een paar kliks een instantie toevoegen voor een bepaalde ruimte en die configureren zonder code aan te moeten raken.
• De visualisatie is ruk. Geen fatsoenlijke webapp die je makkelijk kunt inrichten, geen mobiele apps.
• Data logging mag je ook lekker zelf bouwen. De hardware en software van een plc is er niet geschikt om er database op te draaien.
• Beperkte hardwareondersteuning vergeleken met oplossingen zoals Home Assistant of IP-Symcon. Met die laatsten kun je out of the box met heel veel verschillende protocollen communiceren en kun je tevens gebruikmaken van allerlei modules of plugins om specifieke diensten of apparaten te integreren in je systeem.

Ik heb ervoor gekozen om alles modulair in IP-Symcon op te zetten. Ik kan ontwikkelen in een taal (PHP) en design patterns die ik gewend ben. Beheer is makkelijker via een webbased management console en je kunt er makkelijk een app mee inrichten voor visualisatie en bediening. Het systeem is event driven wat mijn inziens beter past bij wat er in een woning gebeurt dan een cyclisch systeem zoals een plc. Je doet pas iets op het moment dat er iets aan de state van je huis verandert.

Punt 1, 2 en 3 kunnen natuurlijk juist een voordeel zijn voor de mensen die al bekend zijn met het programmeren van plc's

De rest kan ik me enigszins in vinden. Als integratie met apparaten zoals smart-deurbellen en ikea rolgordijnen gewenst is zul je met een plc alleen een heleboel werk hebben of helemaal niet uit de voeten kunnen. Persoonlijk zou ik het systeem dan wel anders opbouwen. Van kerntaken zoals het schakelen van verlichting en het uitlezen van sensoren zou ik de logica in de plc bouwen. Nevenfuncties zoals geofencing of interacties met een calendar event zou ik dan bijvoorbeeld via home assistant laten lopen. In feite zou homeassistant dan juist als doorgeefluik naar de plc dienen. De stabiliteit van een plc gebruik je dan om altijd terug te kunnen vallen op basis functionaliteit. En waarom dan een heus plc als doorgeefluik? Zou je niet een tcp io module kunnen uitlezen met homeassistant, scheelt weer wat in de kosten..

Maar misschien draait een systeem als homeassistant wel stabiel genoeg, ik heb er zelf geen ervaring mee. Wat ik wel weet is dat ik regelmatig plc's van 25 jaar oud uit machines haal die nog steeds feilloos hun werk doen.

[Kanze]

In afwachting van enkele andere onderdelen heb ik deze ochtend wat geëxperimenteerd met het sturen van een Eltako ES12DX-UC telerupter (bi-stabiel) relais. In de testopstelling wordt het relais geschakeld via een schakelaar die een ingang op een 750-431 hoog zet waardoor een uitgang op een 750-530 ook hoog wordt gezet.

[UglyDinosaur]

benbam schreef op vrijdag 28 februari 2020 @ 06:32:
[...]


Net nog eens gekeken en nu draait hij toch ook de hele tijd tegen de 90%.

Hoe vaak hij naar de sd kaart schrijft weet ik niet, maar aangezien ik het zo heb aangepast heb dat alles vanaf de SD kaart gaat ipv het interne geheugen kan dat best wel eens veel zijn.

Ik ga al eens proberen binnenkort om de cycle time van de taken wat te vergroten...

Net de aanpassingen gedaan en geüpload naar de PLC. Blijkbaar zat er toch ook nog een taakje in het programma dat data logde. Dat taakje er uit gegooid en de cycle times van de grootste taken een pak langer gemaakt.

Nu draait de CPU tussen de 50 en 60%. Het heeft zijn effect dus niet gemist.

Wel ga ik nog eens in het oog houden wat het verloop is van het vrije geheugen van de PLC zelf. Eens kijken of dat niet geniepig volloopt waardoor de PLC blijft hangen...

[Roekeloos]

Ik heb lang zitten prutsen om een oplossing te vinden om pulsdrukkers goed uit te kunnen lezen. Ik gebruik nu een PiFace, maar ik wil overstappen van Raspberry Pi naar Odroid C2. Aanvankelijk was ik op zoek naar een oplossing die events genereert, zoals UDP of MQTT. Lang zitten prutsen met een Wago 750-881, maar ik kom er niet uit met dat oerwoud van software en licenties en uiteindelijk blijft het een dure oplossing.

Uiteindelijk ben ik op een Siemens Logo uitgekomen, welke ik middels S7Comm uitlees en aanstuur m.b.v. NodeRed. De PLC heeft eenvoudige logica met off-delays op de ingangen, zodat ook korte pulsen worden "gezien". Het blijft polling dus sub-optimaal, maar het werkt voor mij!

[sjoerd1980]

Kanze schreef op vrijdag 28 februari 2020 @ 12:17:
In afwachting van enkele andere onderdelen heb ik deze ochtend wat geëxperimenteerd met het sturen van een Eltako ES12DX-UC telerupter (bi-stabiel) relais. In de testopstelling wordt het relais geschakeld via een schakelaar die een ingang op een 750-431 hoog zet waardoor een uitgang op een 750-530 ook hoog wordt gezet.

Je stuurt het relais dus met een puls uit de PLC? Hoe weet de PLC de toestand van het relais dan?

Misschien heb je er iets handigs op gevonden en dan wil ik dat ook wel weten. Heb nu een aantal teleruptoren in gebruik en deze moeten naar mijn idee vervangen worden door relais.

Daarbij twijfel ik nog tussen de Eltako relais op basis van bistabiel relais of gewone ordinaire relais. Prijsverschil zit op iets van E 10. Nadeel van gewone relais is het statische verbruik van 1W. Dit is relatief hoog ten opzichte van de gestuurde lampen. Maar ja, E 10 is iets van 40kWh, dus relais moet meer dan 40k uur mee voordat het prijsverschil terugverdiend is...

[bartvb]

sjoerd1980 schreef op zaterdag 29 februari 2020 @ 16:25:
[...]Maar ja, E 10 is iets van 40kWh, dus relais moet meer dan 40k uur mee voordat het prijsverschil terugverdiend is...

Doe het dan voor de (klein)kinderen. Er is meer dan alleen terugverdientijd bij dit soort dingen.

Ik heb net een 750-889 (KNX Controller) met o.a. een 735-646 (Knx interface) gescoord op eBay. Ben benieuwd

[Ethirty]

bartvb schreef op zaterdag 29 februari 2020 @ 18:29:
[...]

Doe het dan voor de (klein)kinderen. Er is meer dan alleen terugverdientijd bij dit soort dingen.

Tja, maar dan moet je ook geen PLC gebruiken en gewoon 1 led-peertje per kamer ophangen. Het is een fijne balans tussen hobby, comfort, budget en milieu.

[Kanze]

Roekeloos schreef op zaterdag 29 februari 2020 @ 11:46:
Ik heb lang zitten prutsen om een oplossing te vinden om pulsdrukkers goed uit te kunnen lezen. Ik gebruik nu een PiFace, maar ik wil overstappen van Raspberry Pi naar Odroid C2. Aanvankelijk was ik op zoek naar een oplossing die events genereert, zoals UDP of MQTT. Lang zitten prutsen met een Wago 750-881, maar ik kom er niet uit met dat oerwoud van software en licenties en uiteindelijk blijft het een dure oplossing.

Uiteindelijk ben ik op een Siemens Logo uitgekomen, welke ik middels S7Comm uitlees en aanstuur m.b.v. NodeRed. De PLC heeft eenvoudige logica met off-delays op de ingangen, zodat ook korte pulsen worden "gezien". Het blijft polling dus sub-optimaal, maar het werkt voor mij!

Forumlid @MichVw beheert een project op github dat net specifiek doet wat jij nodig had. Het voorziet een MQTT interface waarmee domotica-software kan communiceren met de PLC. Het zal bij mij ook dienen als backbone voor de communicatie naar een latere hoge laag software genre OpenHAB.

sjoerd1980 schreef op zaterdag 29 februari 2020 @ 16:25:
[...]


Je stuurt het relais dus met een puls uit de PLC? Hoe weet de PLC de toestand van het relais dan?

Misschien heb je er iets handigs op gevonden en dan wil ik dat ook wel weten. Heb nu een aantal teleruptoren in gebruik en deze moeten naar mijn idee vervangen worden door relais.

Daarbij twijfel ik nog tussen de Eltako relais op basis van bistabiel relais of gewone ordinaire relais. Prijsverschil zit op iets van E 10. Nadeel van gewone relais is het statische verbruik van 1W. Dit is relatief hoog ten opzichte van de gestuurde lampen. Maar ja, E 10 is iets van 40kWh, dus relais moet meer dan 40k uur mee voordat het prijsverschil terugverdiend is...

Dat is inderdaad een kernprobleem bij het gebruik van teleruptoren in combinatie met een centraal sturingssysteem zoals een PLC. De eenvoudigste oplossing is om te werken met een impulsschakelaar/schakelrelais zoals de Eltako ESR12Z-4DX-UC en deze dan in schakelrelais-modus te plaatsen. De ES12DX-UC in het filmpje kan dat niet en in die opstelling is dus geen terugmelding. Wij kiezen voor deze weg omdat je die Eltako's eenvoudig kan omschakelen tot teleruptor. Stel dat heel de PLC eruit valt kan je in een noodgeval mits wat snelle aanpassingen aan de bekabeling de installatie in laat ons zeggen manuele modus plaatsen zodat het huis gewoon leefbaar blijft.

Indien je om een bepaalde reden absoluut met teleruptoren wil of moet werken bestaat de mogelijkheid om voor elke vermogenkring die moet worden geschakeld een twee-polige teleruptor te voorzien die gelijktijdig de vermogenkring en een terugmeldingskring schakelt. Maar dat jaagt de kosten natuurlijk de hoogte in.

[ Voor 4% gewijzigd door Kanze op 29-02-2020 19:51 ]

[Antonius]

benbam schreef op zaterdag 29 februari 2020 @ 11:14:
[...]


Net de aanpassingen gedaan en geüpload naar de PLC. Blijkbaar zat er toch ook nog een taakje in het programma dat data logde. Dat taakje er uit gegooid en de cycle times van de grootste taken een pak langer gemaakt.

Nu draait de CPU tussen de 50 en 60%. Het heeft zijn effect dus niet gemist.

Wel ga ik nog eens in het oog houden wat het verloop is van het vrije geheugen van de PLC zelf. Eens kijken of dat niet geniepig volloopt waardoor de PLC blijft hangen...

Dat zou ik wel interessant vinden om te horen. Normaliter doet PLC code niet aan dynamische geheugen allocatie. Dat komt de stabiliteit ten goede. Als jouw PLC wel langzaam minder vrij geheugen krijgt tot een reboot dan is er iets bijzonders aan de hand.


Michiel, begrijp ik het goed dat jij de modbus communicatie over RS485 tussen PLC en energiemeter inmiddels aan de praat hebt?

[bartvb]

bartvb schreef op donderdag 27 februari 2020 @ 14:00:
Nu lijken de PFC200 serie maar ook de 750-889 aardige kanshebbers (tweede hands dan). Ik krijg alleen niet helder wat nu precies het voordeel van de 750-889 (een 750 PLC met KNX ondersteuning) is tov een andere 750-serie PLC? Iemand een idee?

Inmiddels wat beter naar gekeken en uit de handleiding:

The KNX IP controller works on the hardware basis of the WAGO ETHERNET controller 750-880. Except for EtherNet/IP, the same protocols are used for the data transfer. In addition, the KNX IP protocol is implemented.

Daar had ik eerder moeten kijken

Iemand een idee wat de implicaties zijn van het ontbreken van EtherNet/IP? Wat kan ik daardoor niet doen?

[MichVw]

Antonius schreef op zondag 1 maart 2020 @ 11:37:
[...]


Dat zou ik wel interessant vinden om te horen. Normaliter doet PLC code niet aan dynamische geheugen allocatie. Dat komt de stabiliteit ten goede. Als jouw PLC wel langzaam minder vrij geheugen krijgt tot een reboot dan is er iets bijzonders aan de hand.


Michiel, begrijp ik het goed dat jij de modbus communicatie over RS485 tussen PLC en energiemeter inmiddels aan de praat hebt?

Ik heb eerlijk gezegd nog wat werk, heb wat info gekregen van Wago support hoe je best RS485 aanpakt met é!cockpit, ik stuur het je straks anders even door.

Eenmaal alles werkt documenteer ik het boeltje op de git repo ook natuurlijk.

[UglyDinosaur]

[...]

Michiel, begrijp ik het goed dat jij de modbus communicatie over RS485 tussen PLC en energiemeter inmiddels aan de praat hebt?

Bij mijn heb ik dat aan de praat gekregen in Codesys. Met welke software werk je?

[Kanze]

MichVw schreef op zondag 1 maart 2020 @ 14:06:
[...]


Ik heb eerlijk gezegd nog wat werk, heb wat info gekregen van Wago support hoe je best RS485 aanpakt met é!cockpit, ik stuur het je straks anders even door.

Eenmaal alles werkt documenteer ik het boeltje op de git repo ook natuurlijk.

Kan je die informatie hier publiceren? Ik ben zelf momenteel ook bezig met RS485. We kunnen de krachten bundelen!

[MichVw]

Kanze schreef op zondag 1 maart 2020 @ 15:08:
[...]


Kan je die informatie hier publiceren? Ik ben zelf momenteel ook bezig met RS485. We kunnen de krachten bundelen!

@benbam , ik werk met é!cockpit, in codesys 3S zou het geen probleem mogen zijn, mede door het voorbeeld dat je me voorzien hebt, nogmaals bedankt daarvoor!

@Kanze , alles wat ik gekregen heb van informatie kan je vinden in de documentatie van m'n RS485 branch:
https://github.com/Michie...odbusRTU_%C3%A9COCKPIT.md (kleine waarschuwing voor toekomstige lezers, deze link word ongeldig vanaf de RS485 implementatie af is)

Het enige wat er nog aan dient toegevoegd te worden (is meer een opmerking na wat doorvragen aan Wago support): Om meerdere devices te gaan uitlezen moet je een statemachine gaan bouwen die zelfde ModbusMaster FB herbruikt. Geen rocketscience, ik ben er gewoon nog niet aan geraakt

Idem voor het testen van deze implementatie, nog niet aan geraakt.. krijgt zeer zeker nog gevolg.

Met deze laatste info van Wago support merk ik nu ook dat hun implementatie ongeveer zelfde variables output als de CodeSys 3S implemenatie. Het zou dus geen probleem mogen zijn om een FB te bouwen per type device dat je gaat uitlezen die je kan gebruiken in beide ontwikkel omgevingen. Het enige verschil zal zijn dat in Codesys een device op manier X zal moeten toegevoegd worden en in é!COCKPIT op manier Y.

Alles in de link is nog een work in progress, jullie beginnen me bij te benen

[sjoerd1980]

Kanze schreef op zaterdag 29 februari 2020 @ 19:49:
De eenvoudigste oplossing is om te werken met een impulsschakelaar/schakelrelais zoals de Eltako ESR12Z-4DX-UC en deze dan in schakelrelais-modus te plaatsen.

In de basis heb ik geen behoefte om te werken met teleruptoren, maar ik zag dat jij deze aan de PLC had en vroeg me af of je er een handige truc voor had, dan zou ik mooi mijn teleruptoren kunnen hergebruiken

Maar de ESR12Z_4DX had ik eerder nog niet zo op het oog. Wat prijs betreft komt deze dan (per kanaal) weer in de buurt van een normaal 'dom' relais. Ben jij bekend met dit type? Er zijn namelijk twee dingen die ik niet zo begrijp;

- Deze pakt een standby vermogen van 0.4W bij 230V. Maar is dat 230V geschakelde spanning of 230V stuurspanning? Dat maakt nogal uit aangezien ik uiteraard met 24V stuur en er dan maar een standby verlies van 60mW is. Verlies op de stuuringangen is minimaal...

- Er staat duidelijk dat het relais na installatie eerst moet synchroniseren voordat er iets op de geschakelde contacten aangesloten wordt. Maar ik neem wel aan dat het overweg kan met spanninguitval?

[Kanze]

sjoerd1980 schreef op zondag 1 maart 2020 @ 20:31:
[...]


In de basis heb ik geen behoefte om te werken met teleruptoren, maar ik zag dat jij deze aan de PLC had en vroeg me af of je er een handige truc voor had, dan zou ik mooi mijn teleruptoren kunnen hergebruiken

Maar de ESR12Z_4DX had ik eerder nog niet zo op het oog. Wat prijs betreft komt deze dan (per kanaal) weer in de buurt van een normaal 'dom' relais. Ben jij bekend met dit type? Er zijn namelijk twee dingen die ik niet zo begrijp;

- Deze pakt een standby vermogen van 0.4W bij 230V. Maar is dat 230V geschakelde spanning of 230V stuurspanning? Dat maakt nogal uit aangezien ik uiteraard met 24V stuur en er dan maar een standby verlies van 60mW is. Verlies op de stuuringangen is minimaal...

- Er staat duidelijk dat het relais na installatie eerst moet synchroniseren voordat er iets op de geschakelde contacten aangesloten wordt. Maar ik neem wel aan dat het overweg kan met spanninguitval?

Mijn testunit zit al in de post dus ik zal die dingen voor je kunnen testen volgende week. Nu zou voor mij een verlies van 0.4W voor vier relaisuitgangen geen probleem zijn. In de technische fiche staat dat bij spanningsuitval de teleruptor definitief uitschakelt. Van die synchronisatie heb ik zelf bij mijn testopstelling niets gemerkt.

Het is mogelijk dat je andere modellen van die reeks teleruptoren kan voorzien van een terugmelding maar ik weet (nog) niet hoe. In de technische fiches wordt wel bij sommige modellen expliciet verboden om meer als één stuuringang tegelijkertijd van potentiaal te voorzien.

[ Voor 25% gewijzigd door Kanze op 01-03-2020 21:54 ]

[MichVw]

@Kanze , ik weet niet wat je bezigheden zijn maar ik wil me wel gerust toespitsen op het bouwen van een modbus rtu statemachine. Eventueel kan jij je dan meer toespitsen op het bouwen van de pcb/ATtiny sensor?

[Kanze]

MichVw schreef op zondag 1 maart 2020 @ 22:10:
@Kanze , ik weet niet wat je bezigheden zijn maar ik wil me wel gerust toespitsen op het bouwen van een modbus rtu statemachine. Eventueel kan jij je dan meer toespitsen op het bouwen van de pcb/ATtiny sensor?

Onze ruwbouw is ondertussen bijna klaar en binnenkort zullen de elektrische leidingen worden geslepen. Mijn aandacht wordt dus helaas aan alle kanten op de proef gesteld. Vermoedelijk zal het ontwerp van de sensorkit een tijdje in het prototyping stadium blijven zitten. Ik moet ook duidelijk nog een pak studeren want op het vlak van IC ontwerp is het voor mij echt nog al doende leren.

Zo weet ik ondertussen reeds dat we hoe dan ook zullen moeten gebruikmaken van een MAX485 chip of afgeleide. De UART interface op de grotere ATTiny's kan voor zover ik begrijp niet native RS485 aansturen. Of als het dat wel kan dan vind ik er praktisch geen informatie rond.

Vooruitzicht voor de komende twee weken

1. Testopstelling uitbreiden met een Eltako 4DX en testen hoe goed deze werken in schakelrelais modus
2. Mij verder door Introduction to Microcontrollers worstellen in afwachten van aankomst van het prototyping bordje met de 3216

Heb jij reeds succes gehad met een RS485 link op te stellen in é!Cockpit? Ik zie in je repo daar al wat van staan -- is dat reeds hardwarematig getest?

[MichVw]

Kanze schreef op maandag 2 maart 2020 @ 13:20:
[...]


Onze ruwbouw is ondertussen bijna klaar en binnenkort zullen de elektrische leidingen worden geslepen. Mijn aandacht wordt dus helaas aan alle kanten op de proef gesteld. Vermoedelijk zal het ontwerp van de sensorkit een tijdje in het prototyping stadium blijven zitten. Ik moet ook duidelijk nog een pak studeren want op het vlak van IC ontwerp is het voor mij echt nog al doende leren.

Zo weet ik ondertussen reeds dat we hoe dan ook zullen moeten gebruikmaken van een MAX485 chip of afgeleide. De UART interface op de grotere ATTiny's kan voor zover ik begrijp niet native RS485 aansturen. Of als het dat wel kan dan vind ik er praktisch geen informatie rond.

Vooruitzicht voor de komende twee weken

1. Testopstelling uitbreiden met een Eltako 4DX en testen hoe goed deze werken in schakelrelais modus
2. Mij verder door Introduction to Microcontrollers worstellen in afwachten van aankomst van het prototyping bordje met de 3216

Heb jij reeds succes gehad met een RS485 link op te stellen in é!Cockpit? Ik zie in je repo daar al wat van staan -- is dat reeds hardwarematig getest?

Ja, ik heb succesvolle communicatie met een Eastron energiemeter vanuit é!Cockpit. (ook maar nog sinds gisteren) dus daar hoef je je geen zorgen om te maken. Ik dien het hele boeltje wel nog verder uit te werken tot iets die makkelijk uitbreidbaar is naar meerdere devices.

normaal kan de 3216 wel native RS485 aan, ik zocht het op voor het aanschaffen van een dev kit:
http://ww1.microchip.com/...-data-sheet-40001997B.pdf
vanaf pagina 338

[Kanze]

MichVw schreef op maandag 2 maart 2020 @ 13:45:
[...]


Ja, ik heb succesvolle communicatie met een Eastron energiemeter vanuit é!Cockpit. (ook maar nog sinds gisteren) dus daar hoef je je geen zorgen om te maken. Ik dien het hele boeltje wel nog verder uit te werken tot iets die makkelijk uitbreidbaar is naar meerdere devices.

normaal kan de 3216 wel native RS485 aan, ik zocht het op voor het aanschaffen van een dev kit:
http://ww1.microchip.com/...-data-sheet-40001997B.pdf
vanaf pagina 338

Klopt wat je zegt. Ik was vergeten dat ik dat nog had nagekeken vooraleer mijn devkit te bestellen. Dat wordt dus benieuwd afwachten tot die aankomt.

[bartvb]

Gebruiken jullie eigenlijk iets als WSCAD of Eplan voor het indelen van b.v. de schakelkast(en)?

Ik moet hier de boel op niet al te lange termijn wat gaan concretiseren, ben even aan het kijken hoe ik de uitwerking een beetje overzichtelijk kan houden. Er komen in totaal drie schakelkasten (incl meterkast) voor vier verdiepingen met, zoals het er nu uit ziet, veel KNX, PLC voor extra connectiviteit en een vleugje Loxone voor configuratie/visualisatie (als ik niet op korte termijn iets beters tegen kom).

@arjan_1980 heb jij een update van je project?

[Antonius]

MichVw schreef op zondag 1 maart 2020 @ 18:49:
Het enige wat er nog aan dient toegevoegd te worden (is meer een opmerking na wat doorvragen aan Wago support): Om meerdere devices te gaan uitlezen moet je een statemachine gaan bouwen die zelfde ModbusMaster FB herbruikt. Geen rocketscience, ik ben er gewoon nog niet aan geraakt

Aha, ja daar had ik niet aan gedacht. Op een RS485 bus kan maar 1 master tegelijk aktief zijn. Als je over dezelfde RS485 verbinding vanuit je PLC met meerdere verschillende slaves wilt communiceren, dan moet je dat in goede banen leiden zodat er niet meerdere apparaten tegelijk over de RS485 bus gaan praten. De meeste modbus communicatie die ik tegenkom is over ethernet. Dan kun je "vanzelf" meerdere slaves aan.

[Kanze]

Antonius schreef op maandag 2 maart 2020 @ 16:59:
[...]


Aha, ja daar had ik niet aan gedacht. Op een RS485 bus kan maar 1 master tegelijk aktief zijn. Als je over dezelfde RS485 verbinding vanuit je PLC met meerdere verschillende slaves wilt communiceren, dan moet je dat in goede banen leiden zodat er niet meerdere apparaten tegelijk over de RS485 bus gaan praten. De meeste modbus communicatie die ik tegenkom is over ethernet. Dan kun je "vanzelf" meerdere slaves aan.

Op zich zorgt het master-slave protocol er voor dat meerdere slaves niet tegelijk de bus kunnen bezetten. Ik heb enkel naar MODBUS RTU gekeken. Als je zegt dat MODBUS over ethernet vanzelf meerdes slaves aankan wat bedoel je precies?

[Antonius]

Kanze schreef op maandag 2 maart 2020 @ 17:23:
[...]


Op zich zorgt het master-slave protocol er voor dat meerdere slaves niet tegelijk de bus kunnen bezetten. Ik heb enkel naar MODBUS RTU gekeken. Als je zegt dat MODBUS over ethernet vanzelf meerdes slaves aankan wat bedoel je precies?

Je hebt geen uitgeprogrammeerde state machine nodig om een voor een verschillende modbus tcp slaves af te handelen. Je kunt gewoon meerdere tcp modbus slaves definiëren die "tegelijkertijd" afgehandeld worden door de PLC. Het is feitelijk natuurlijk niet zo dat ze precies tegelijk bezig zijn, maar ethernet communicatie an sich zorgt er al voor dat er over hetzelfde kabeltje allerlei zaken tegelijk heen en weer kunnen lopen die elkaar niet bijten terwijl RS485 in dat opzicht simpeler en daarmee ook beperkter is. Op een RS485 bus kan maar 1 apparaat tegelijk zenden. De beschikbare bandbreedte is veel lager. Ethernet verkeer gaat sneller, collissions en packet loss wordt op een heel laag niveau "vanzelf" opgelost.

Ik kom geregeld situaties tegen waar een enkele PLC met 10 of meer slaves communiceert over modbus/tcp (industriële toepassingen). Over RS485 wordt dat lastiger en is sowieso de beschikbare bandbreedte laag waardoor de snelheid noodzakelijk lager wordt. Er past gewoon niet meer data per seconde over de seriële bus.

[Kanze]

Vandaag kwam de 3216 devkit aan. Stap één is dat ding aan de praat krijgen met mijn Uno!

[Giblet]

Ik ben helaas nog niet tegen een betaalbare wago 750-652 aangelopen, dus heb op basis hiervan een werkende ArtNet DMX Node gemaakt: https://github.com/mtongnz/ESP8266_ArtNetNode_v2

Na enig gepruts heb ik het nu ook voor elkaar gekregen om de PFC200 ArtNet uit te laten sturen vanuit codesys 3.5 (ik denk dat het ook moet werken vanuit e!Cockpit) op basis van de OSCAT NETWORK library.

Programma ziet er als volgt uit:

code:

PROGRAM DMX_SEND
VAR
    IP_CONTROL1 : oscat_network.IP_CONTROL2_V2;
    IP_C1       : oscat_network.IP_C;
    S_BUF1      : oscat_network.NETWORK_BUFFER_SHORT;
    R_BUF1      : oscat_network.NETWORK_BUFFER_SHORT;
    send        : BOOL;
    i           : INT;
    init        : BOOL;
END_VAR

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

IF init = FALSE THEN
    init := TRUE;
    S_BUF1.BUFFER [0]:= BYTE#16#41; (* Write DMX header character in the buffer *) 
    S_BUF1.BUFFER [1]:= BYTE#16#72;
    S_BUF1.BUFFER [2]:= BYTE#16#74;
    S_BUF1.BUFFER [3]:= BYTE#16#2D;
    S_BUF1.BUFFER [4]:= BYTE#16#4E;
    S_BUF1.BUFFER [5]:= BYTE#16#65;
    S_BUF1.BUFFER [6]:= BYTE#16#74;
    S_BUF1.BUFFER [7]:= BYTE#16#00;
    S_BUF1.BUFFER [8]:= BYTE#16#00;
    S_BUF1.BUFFER [9]:= BYTE#16#50;
    S_BUF1.BUFFER [10]:= BYTE#16#50;
    S_BUF1.BUFFER [11]:= BYTE#16#0E;
    S_BUF1.BUFFER [12]:= BYTE#16#00;
    S_BUF1.BUFFER [13]:= BYTE#16#00;
    S_BUF1.BUFFER [14]:= BYTE#16#00;
    S_BUF1.BUFFER [15]:= BYTE#16#00;
    S_BUF1.BUFFER [16]:= BYTE#16#02;
    S_BUF1.BUFFER [17]:= BYTE#16#00; (* the following DMX channels have already been written to the buffer *) 
END_IF;
send := FALSE;

FOR i:= 18 TO 118 DO (* check whether the DMX values ​​in the global variable have changed *)
    IF S_BUF1.BUFFER[i] <> OtherVariables.DMX.BUFFER[i-18] THEN
        S_BUF1.BUFFER[i]:= OtherVariables.DMX.BUFFER[i-18];
        send := TRUE;
    END_IF
END_FOR

IF send THEN
    IP_C1.C_MODE:= 3;
    IP_C1.C_ENABLE:= TRUE; (* Enable connection establishment *) 
    IP_C1.TIME_RESET:= TRUE;
    IP_C1.R_OBSERVE:= FALSE; (* Monitor data reception *)
    IP_C1.C_IP:= oscat_network.IP4_DECODE ('10.11.12.195 ');
    IP_C1.C_PORT:= WORD#6454;
    S_BUF1.SIZE := 118;
    send:= FALSE;
END_IF;

IP_CONTROL1 (TIME_OUT:= T#1S, IP_C:= IP_C1, S_BUF:= S_BUF1, R_BUF:= R_BUF1);

Dit programma draait elke cyclus (wellicht wat overkill).

Naast dit is er ook een Global variable list genaamd "OtherVariables" welke er als volgt uit ziet:

code:

VAR_GLOBAL
    DMX : oscat_network.NETWORK_BUFFER_SHORT;
END_VAR

Je kunt dan als volgt DMX Kanaal 1 de waarde 255 geven: OtherVariables.DMX.BUFFER[0] := 255

Werkt naar enorme tevredenheid hier! Ook dimmen gaat mooi soepel

[bartvb]

Enorme noob-vraag:
Is het met b.v. een Wago 750-501 module (2x DO) mogelijk om een PWM frequentie in te stellen? Of moet je zelf iets schrijven zodat de PLC om de paar milliseconde de output schakelt?

[Rob Z]

@bartvb Het zou moeten kunnen maar 'voelt niet goed'. Echte PWM kan een 750-511 bijvoorbeeld.

[bartvb]

Hmm, die simpele DO-modules hebben dus zelf geen intelligentie om een PWM trein in stand te houden? Jammer, vooral omdat die 750-511 niet heel ruim beschikbaar is en niet echt goedkoop is. Een simpele 750-501 heb je voor een paar euro.

In de technische specs staat dat die 750-501 maximaal 3kHz aan kan wat schakelen betreft, maar als ik het goed begrijp is dat niet haalbaar omdat de cycle time van de PLC daar niet kort genoeg voor is? Je kan maar 1x per cycle aan/uit schakelen lijkt me?

[Kanze]

sjoerd1980 schreef op zondag 1 maart 2020 @ 20:31:
[...]


In de basis heb ik geen behoefte om te werken met teleruptoren, maar ik zag dat jij deze aan de PLC had en vroeg me af of je er een handige truc voor had, dan zou ik mooi mijn teleruptoren kunnen hergebruiken

Maar de ESR12Z_4DX had ik eerder nog niet zo op het oog. Wat prijs betreft komt deze dan (per kanaal) weer in de buurt van een normaal 'dom' relais. Ben jij bekend met dit type? Er zijn namelijk twee dingen die ik niet zo begrijp;

- Deze pakt een standby vermogen van 0.4W bij 230V. Maar is dat 230V geschakelde spanning of 230V stuurspanning? Dat maakt nogal uit aangezien ik uiteraard met 24V stuur en er dan maar een standby verlies van 60mW is. Verlies op de stuuringangen is minimaal...

- Er staat duidelijk dat het relais na installatie eerst moet synchroniseren voordat er iets op de geschakelde contacten aangesloten wordt. Maar ik neem wel aan dat het overweg kan met spanninguitval?

Net een mailtje gekregen van eibmarkt dat m'n verzending vandaag pas werd verstuurd. Dat wordt dus wachten tot begin volgende week om die teleruptor te kunnen testen. Hoe verloopt de installatie bij jou verder?

bartvb schreef op vrijdag 6 maart 2020 @ 15:35:
Hmm, die simpele DO-modules hebben dus zelf geen intelligentie om een PWM trein in stand te houden? Jammer, vooral omdat die 750-511 niet heel ruim beschikbaar is en niet echt goedkoop is. Een simpele 750-501 heb je voor een paar euro.

In de technische specs staat dat die 750-501 maximaal 3kHz aan kan wat schakelen betreft, maar als ik het goed begrijp is dat niet haalbaar omdat de cycle time van de PLC daar niet kort genoeg voor is? Je kan maar 1x per cycle aan/uit schakelen lijkt me?

Ik vermoed dat die 3kHz eerder aangeeft wat de maximum snelheid is waarmee een uitgang op die klem elektrisch van potentiaal kan switching. De instructie daartoe komt van de PLC en die is gelimiteerd tot 2ms voor I/O switching.

De 750-501 draait op een interne 250 Hz klok. Vervolgens kan de PLC een in een register van de klem een waarde plaatsen die wordt vertaald naar een duty cycle van 0% naar 100%.

Afhankelijk van waarvoor je die PWM nodig hebt zou ik aanraden van te kijken naar een AVR chip die de PWM kan doen aan hogere snelheid. Wil je LED's dimmen dan is 250 Hz bijvoorbeeld te traag (je zal flikkers zien). Maar voor andere dingen kan het misschien wel dienen.

[bartvb]

@Kanze De 750-511 bedoel je met de 250Hz neem ik aan?

Maar bummer. Met 2ms cycle time kan een output maximaal 500x schakelen/seconde. Als je dat doet heb je een duty cycle van 50%. Wil je b.v. ook 2% kunnen doen dan is maximaal 10Hz haalbaar. Lijkt erop dat die Mean Well een PWM signaal tussen de 100Hz en 3kHz wil hebben.

Licht dan toch maar op een andere manier sturen dus, jammer! Best een flinke leercurve het PLC gebeuren, hardware zit anders in elkaar dan ik zou verwachten, software is op het moment nogal een puzzel, technische ontwikkeling ligt op hardware en softwaregebied 20 jaar achter. Maar aan de andere kant is dat ook weer de kracht. Het moet rock solid zijn, het hoeft niet het laatste hippe JS framework te kunnen draaien. Maar is even wennen dus

Ondertussen wel via eBay wat hardware bij elkaar gesprokkeld (750-889, voedingen en een hoop DI en DO). Nu uitzoeken hoe ik kan zorgen dat ik ook contact krijg met dat spul. Zat geen software bij.

[Kanze]

bartvb schreef op vrijdag 6 maart 2020 @ 22:05:
@Kanze De 750-511 bedoel je met de 250Hz neem ik aan?

Maar bummer. Met 2ms cycle time kan een output maximaal 500x schakelen/seconde. Als je dat doet heb je een duty cycle van 50%. Wil je b.v. ook 2% kunnen doen dan is maximaal 10Hz haalbaar. Lijkt erop dat die Mean Well een PWM signaal tussen de 100Hz en 3kHz wil hebben.

Licht dan toch maar op een andere manier sturen dus, jammer! Best een flinke leercurve het PLC gebeuren, hardware zit anders in elkaar dan ik zou verwachten, software is op het moment nogal een puzzel, technische ontwikkeling ligt op hardware en softwaregebied 20 jaar achter. Maar aan de andere kant is dat ook weer de kracht. Het moet rock solid zijn, het hoeft niet het laatste hippe JS framework te kunnen draaien. Maar is even wennen dus

Ondertussen wel via eBay wat hardware bij elkaar gesprokkeld (750-889, voedingen en een hoop DI en DO). Nu uitzoeken hoe ik kan zorgen dat ik ook contact krijg met dat spul. Zat geen software bij.

Er is ook nog een verschil tussen een PWM signaal en de output van een DO zoals de 750-501 aan en uit zetten.

Je kan die output drijven tot een switching snelheid van 2ms maar dat is niet hetzelfde als een PWM signaal van 500 Hz. De DO zal switchen aan 500Hz maar heeft geen controle over de duty cycle. Het is ofwel 0% ofwel 100%. Als je de PLC cycle time aanpast maar een hogere waarde genereer je een geheel nieuw PWM signaal aan een frequentie gelijk aan de cycle time. Maar ook dan heb je geen duty cycle controle. Bij een echt PWM signaal, zoals geproduceerd door die 750-511 aan 250Hz kan je binnen die frequentie wel de duty cycle aanpassen. De frequentie van het PWM signaal blijft echter altijd 250Hz.

zo begrijp ik dat. indien iemand anders hier meer kennis over heeft ben ik zeker benieuwd

edit; nog even melden dat je é!Cockpit gratis kan downloaden bij WAGO en dat de evaluatieversie op een eenvoudige manier kan worden teruggezet naar 30 gebruiksdagen. De PLC blijft gewoon doorwerken met het geïnstalleerde programma. software is dus de facto gratis te noemen.

[ Voor 6% gewijzigd door Kanze op 07-03-2020 06:54 ]

[sjoerd1980]

Kanze schreef op vrijdag 6 maart 2020 @ 20:47:
[...]


Net een mailtje gekregen van eibmarkt dat m'n verzending vandaag pas werd verstuurd. Dat wordt dus wachten tot begin volgende week om die teleruptor te kunnen testen. Hoe verloopt de installatie bij jou verder?

Bij mij loopt er op dat vlak even niets. Je weet hoe het gaat tijdens de bouw ;-). Maar ik heb een bestellijst klaar staan voor wat draad spul, wartels en voedingen. Ik wacht even rustig op jouw bevindingen van het vier voudige relais en dan kunnen er ook relais mee besteld worden.

[MichVw]

UglyDinosaur schreef op donderdag 27 februari 2020 @ 21:34:
[...]


Ik had de indruk dat dat vooral was omdat de gemeten temperaturen gelogd werden. Dat heb ik (volgens mij) allemaal uitgezet.

Zou het kunnen dat ik simpelweg door verlichting en HVAC al op de limieten van de PLC zit?

De belasting van de PLC is zo te zien ook wel zeer hoog...

[Afbeelding]

Hebje hier nog vooruitgang op geboekt?
Is dat een telnet connectie naar de plc? welk commando voer je precies uit om de belasting zo te zien te krijgen?
vrij interessant

[UglyDinosaur]

MichVw schreef op donderdag 12 maart 2020 @ 10:13:
[...]


Hebje hier nog vooruitgang op geboekt?
Is dat een telnet connectie naar de plc? welk commando voer je precies uit om de belasting zo te zien te krijgen?
vrij interessant

Eigenlijk heeft me dat nog veel kopzorgen opgeleverd... Er zaten tasks in die om de 5ms werden uitgevoerd. Ik heb die periode verlengd en toen viel de belasting heel sterk terug. Maar de keerzijde van de medaille was dat om de één of andere reden alle uitgangen een fractie van een seconde uitvielen als de verwarming aan of uit ging... Alle lichten dus even uit... Niet handig...

Verdere experimenten leverden me alleen maar een instabiele PLC op die na enkele uren uit viel... Niet bevorderlijk voor de WAF

Ondertussen staat bijna alles terug zoals het was met terug een belasting van bijna 100%... Ik ga het zo even laten draaien om de stabiliteit te testen en dan stapje per stapje aanpassingen doen...

Ik log in op de PLC via Putty en met het commando htop kan je dan de belasting zien

[MichVw]

UglyDinosaur schreef op donderdag 12 maart 2020 @ 10:40:
[...]


Eigenlijk heeft me dat nog veel kopzorgen opgeleverd... Er zaten tasks in die om de 5ms werden uitgevoerd. Ik heb die periode verlengd en toen viel de belasting heel sterk terug. Maar de keerzijde van de medaille was dat om de één of andere reden alle uitgangen een fractie van een seconde uitvielen als de verwarming aan of uit ging... Alle lichten dus even uit... Niet handig...

Verdere experimenten leverden me alleen maar een instabiele PLC op die na enkele uren uit viel... Niet bevorderlijk voor de WAF

Ondertussen staat bijna alles terug zoals het was met terug een belasting van bijna 100%... Ik ga het zo even laten draaien om de stabiliteit te testen en dan stapje per stapje aanpassingen doen...

Ik log in op de PLC via Putty en met het commando htop kan je dan de belasting zien

interessant! is er een manier om te zien met welke PLC task een lijn in 'htop' overeenkomt?

[UglyDinosaur]

MichVw schreef op donderdag 12 maart 2020 @ 12:06:
[...]


interessant! is er een manier om te zien met welke PLC task een lijn in 'htop' overeenkomt?

Geen idee

[Jantje2000]

Ik las dat je een PFC-200 zou moeten kunnen programmeren met standaard programmeertalen, maar zijn er SDK's beschikbaar? Want de input's en outputs zullen uiteindelijk toch bediend moeten kunnen worden lijkt me?

Ik zat even te Googlen, en ik vond daar dan ook wel een SDK voor bijvoorbeeld python, maar dat is niet officieel ofzo.
Bovendien ontbreekt er de documentatie.

[ Voor 27% gewijzigd door Jantje2000 op 12-03-2020 13:24 ]

[MewBie]

Jantje2000 schreef op donderdag 12 maart 2020 @ 13:22:
Ik las dat je een PFC-200 zou moeten kunnen programmeren met standaard programmeertalen, maar zijn er SDK's beschikbaar? Want de input's en outputs zullen uiteindelijk toch bediend moeten kunnen worden lijkt me?

Ik zat even te Googlen, en ik vond daar dan ook wel een SDK voor bijvoorbeeld python, maar dat is niet officieel ofzo.
Bovendien ontbreekt er de documentatie.

Op de Wago site kun je een Linux Toolchain downloaden in de Runtime Software sectie.

[Kanze]

sjoerd1980 schreef op zondag 8 maart 2020 @ 19:13:
[...]


Bij mij loopt er op dat vlak even niets. Je weet hoe het gaat tijdens de bouw ;-). Maar ik heb een bestellijst klaar staan voor wat draad spul, wartels en voedingen. Ik wacht even rustig op jouw bevindingen van het vier voudige relais en dan kunnen er ook relais mee besteld worden.

Ik heb nog eens tijd gevonden om die Eltako te testen. Beelden zeggen toch altijd meer dus hieronder het filmpje;

[MichVw]

Kanze schreef op zondag 15 maart 2020 @ 00:56:
[...]


Ik heb nog eens tijd gevonden om die Eltako te testen. Beelden zeggen toch altijd meer dus hieronder het filmpje;

[YouTube: WAGO 750-8202 + ELTAKO ESR12Z-4DX-UC]

Als ik het goed heb gebruik je de 'bistabel' modus om te kunnen schakelen als de PLC eruit ligt (die dingen gaan 25 jaar mee zonder probleem normaal maar redundantie is altijd goed veronderstel ik) maar heb je het het probleem dat je geen feedback hebt naar de PLC?

In 'relais' modus is het het voordeel dat er veel minder stand-by verlies is en waarschijnlijk ook dat het ding geen geluid maakt (kan handig zijn in sommige omgevingen veronderstel ik). Nadeel is dan weer de prijs?

Ik ondervind al een eindje dat ik dergelijk elektrisch materiaal goedkoopst terugvind op Eibabo:
https://www.eibabo.be/nl/...-eb15703758?fs=4292810202
(Eltako ESR12Z-4DX-UC voor €60)

dat zijn dan 4 relais voor €60, ze hebben ook wago relais voor €7/stuk
https://www.eibabo.be/nl/...10704843?fs=514347569&c=0

of zelf dit phoenix contact kan ook een optie zijn?
https://www.eibabo.be/nl/...15506574?fs=514347569&c=0

[smaertens]

Ik heb overal de ER12-200UC van Eltako gebruikt.

Ik heb hier ooit eens een post gezet met de verschillende mogelijkheden en de kostprijs per input;
Het voordeel van die ER12 is dat die bijna geen verbruik heeft als hij in een bepaalde stand staat.

Het leek mij gewoon veel te complex (en te duur) om elke output die je bekrachtigt ook nog eens terug in te lezen als input.

Met deze kan ik de voeding van de ledverlichtingen dubbel onderbreken. Als je enkel onderbreekt, heb je nog kans dat de ledverlichting lichtjes blijft branden etc.

[ Voor 18% gewijzigd door smaertens op 16-03-2020 10:25 ]

[Kanze]

MichVw schreef op maandag 16 maart 2020 @ 09:15:
[...]


Als ik het goed heb gebruik je de 'bistabel' modus om te kunnen schakelen als de PLC eruit ligt (die dingen gaan 25 jaar mee zonder probleem normaal maar redundantie is altijd goed veronderstel ik) maar heb je het het probleem dat je geen feedback hebt naar de PLC?

Klopt. Je kan in een noodgeval stuurkringen van bijvoorbeeld drukknoppen rechtstreeks aansluiten op een bistabiel-relais (teleruptor). Het lijkt me niet ondenkbaar dat in de beginfase het fixen van bugs de installatie tijdelijk offline haalt. Dan is het wel gemakkelijk dat het licht in de badkamer kan blijven aangaan.

In 'relais' modus is het het voordeel dat er veel minder stand-by verlies is en waarschijnlijk ook dat het ding geen geluid maakt (kan handig zijn in sommige omgevingen veronderstel ik). Nadeel is dan weer de prijs?

In principe moet het omgekeerd zijn. In normale relais-modus heb je een constante stroom van een PLC output naar de stuuringang van dat relais. Dat is ook meteen het feedbacksignaal. Zet je die output laag dan heb je garantie dat het relais ook uit staat.

Ik ondervind al een eindje dat ik dergelijk elektrisch materiaal goedkoopst terugvind op Eibabo:
https://www.eibabo.be/nl/...-eb15703758?fs=4292810202
(Eltako ESR12Z-4DX-UC voor €60)

dat zijn dan 4 relais voor €60, ze hebben ook wago relais voor €7/stuk
https://www.eibabo.be/nl/...10704843?fs=514347569&c=0

of zelf dit phoenix contact kan ook een optie zijn?
https://www.eibabo.be/nl/...15506574?fs=514347569&c=0

Het "probleem" met het gebruik van zuivere relais is dat er geen backup mogelijk is bij het uitvallen van je PLC systeem. Ik denk dan vooral aan uitval omwille van softwarefouten of gewoon downtime tijdens het programmeren. De hardware zal inderdaad wellicht nooit het probleem zijn.

Wij kopen meestal in bij eibmarkt of voltus. Het lijkt erop dat al die webwinkels uiteindelijk op dezelfde prijs uitkomen. Ze spelen dan wat met verzendkosten om de indruk te wekken dat het stuk bij hun toch iets goedkoper is.

smaertens schreef op maandag 16 maart 2020 @ 10:24:
Ik heb overal de ER12-200UC van Eltako gebruikt.

Ik heb hier ooit eens een post gezet met de verschillende mogelijkheden en de kostprijs per input;
Het voordeel van die ER12 is dat die bijna geen verbruik heeft als hij in een bepaalde stand staat.

Het leek mij gewoon veel te complex (en te duur) om elke output die je bekrachtigt ook nog eens terug in te lezen als input.

Met deze kan ik de voeding van de ledverlichtingen dubbel onderbreken. Als je enkel onderbreekt, heb je nog kans dat de ledverlichting lichtjes blijft branden etc.

Als ik het goed begrijp kan je met die opstelling geen algemene AAN/UIT functies maken. De PLC weet niet wat de stand van het bistabiel relais is (en ook of deze wel geschakeld heeft bij een impuls). Dat hoeft geen probleem te zijn indien die functionaliteit niet nodig is. Helaas heb ik dat wel nodig en moet ik dus voor een duurdere oplossing gaan.

[ Voor 3% gewijzigd door Kanze op 16-03-2020 10:36 ]

[Rob Z]

Hier ca. 30 Wago 788-304 relais en nog wat anderen aan de PLC hangen. Voor ca. 7 euro kunnen ze 16A schakelen en nemen dacht ik 19mA als houdstroom in een 24VDC spoel. En er zit een ledje op.

Voor het geval dat 'de PLC uitvalt' (wat iedereen zonder domotica heel eng vindt) heb ik een rijtje diodeklemmen gemonteerd die via een schakelaar alsnog 24VDC op de spoelen zet van de meest belangrijke lampen in de WC etc.

[bartvb]

Andere optie voor niet al te lompe loads is een 750-513 I/O module. Deze kan 230V (of lagere voltages) schakelen tot 5A:

https://www.wago.com/glob...el-relay-output/p/750-513

[bartvb]

Kanze schreef op zaterdag 7 maart 2020 @ 06:50:
[...]

Je kan die output drijven tot een switching snelheid van 2ms maar dat is niet hetzelfde als een PWM signaal van 500 Hz. De DO zal switchen aan 500Hz maar heeft geen controle over de duty cycle. Het is ofwel 0% ofwel 100%. Als je de PLC cycle time aanpast maar een hogere waarde genereer je een geheel nieuw PWM signaal aan een frequentie gelijk aan de cycle time. Maar ook dan heb je geen duty cycle controle.

Klopt, maar je hoeft natuurlijk niet bij iedere cycle de output om te zetten. Daardoor kwam ik ook op die 10Hz. Als je iedere cycle omschakelt dan haal je 500Hz met een cycletime van 2ms. Als je een duty cycle van 2% mogelijk wil maken zal je moeten zorgen dat er 49 'off' cycles tegenover iedere 'on' cycle staan. In totaal 50*2=100ms, dus 10Hz.

Inmiddels heb ik de PLC (met hulp van een medetweaker ) aan de praat. Super simpel programma in gegooid dat iedere cycle de output switched van een 750-515. Dat geeft dit beeld op de oscilloscoop:



166Hz dus = cycle time van 3ms (3ms 'on', 3ms 'off').

Ik heb er ook nog een 'freewheeling' programma van proberen te maken maar die komt ook niet verder dan 166Hz, waarschijnlijk omdat de output module 3ms nodig heeft voor de switch oid? Kanttekening bij het experiment is ook nog dat het voltage in die 3ms zakt naar 19,7V. Dus 'off' is nog niet echt uit.

Niet bruikbaar voor PWM iig tenzij het apparaat dat je aanstuurt bijzonder flexibel is.
Iig leuke exercitie. Weer terug naar m'n HTS mechatronica tijd

[ Voor 3% gewijzigd door bartvb op 17-03-2020 21:16 ]

[Kanze]

bartvb schreef op dinsdag 17 maart 2020 @ 21:14:
[...]


Klopt, maar je hoeft natuurlijk niet bij iedere cycle de output om te zetten. Daardoor kwam ik ook op die 10Hz. Als je iedere cycle omschakelt dan haal je 500Hz met een cycletime van 2ms. Als je een duty cycle van 2% mogelijk wil maken zal je moeten zorgen dat er 49 'off' cycles tegenover iedere 'on' cycle staan. In totaal 50*2=100ms, dus 10Hz.

Inmiddels heb ik de PLC (met hulp van een medetweaker ) aan de praat. Super simpel programma in gegooid dat iedere cycle de output switched van een 750-515. Dat geeft dit beeld op de oscilloscoop:

[Afbeelding]

166Hz dus = cycle time van 3ms (3ms 'on', 3ms 'off').

Ik heb er ook nog een 'freewheeling' programma van proberen te maken maar die komt ook niet verder dan 166Hz, waarschijnlijk omdat de output module 3ms nodig heeft voor de switch oid? Kanttekening bij het experiment is ook nog dat het voltage in die 3ms zakt naar 19,7V. Dus 'off' is nog niet echt uit.

Niet bruikbaar voor PWM iig tenzij het apparaat dat je aanstuurt bijzonder flexibel is.
Iig leuke exercitie. Weer terug naar m'n HTS mechatronica tijd

Ah zo begrijp ik wat je bedoelde. Je kan inderdaad op die manier een PWM signaal produceren. Interessant dat beeld met je oscilloscoop. Vermoedelijk zet de PLC op die uitgang het voltage net laag genoeg zodat het voor nul wordt aangenomen in een extern circuit. Helemaal naar nul volt zal waarschijnlijk te veel slijtage veroorzaken.

[smaertens]

Kanze schreef op woensdag 18 maart 2020 @ 14:10:
[...]


Ah zo begrijp ik wat je bedoelde. Je kan inderdaad op die manier een PWM signaal produceren. Interessant dat beeld met je oscilloscoop. Vermoedelijk zet de PLC op die uitgang het voltage net laag genoeg zodat het voor nul wordt aangenomen in een extern circuit. Helemaal naar nul volt zal waarschijnlijk te veel slijtage veroorzaken.

Heeft dat niet te maken of dat circuit belast wordt of niet?

[bartvb]

smaertens schreef op woensdag 18 maart 2020 @ 14:27:
[...]

Heeft dat niet te maken of dat circuit belast wordt of niet?

Dat idd. De PLC schakelt de output meteen uit, maar dat wil niet zeggen dat alles spanning/lading ook meteen weg is. Deze kan in mijn setup nergens heen.

Programma even aangepast zodat er meer tijd is om de spanning te laden wegvloeien:

[Kanze]

Nu ben ik wel jaloers op die oscilloscoop @bartvb

[bartvb]

Aangeschaft toen we nog geen kinderen hadden en toen ik nog enthousiaste hobby-plannen had. Hij is niet heel veel gebruikt

Maar bij dit soort dingen erg handig en best wel betaalbaar. Vast ook goed 2e hands te vinden. Overigens zijn er ook erg leuke USB-oscilloscopen. Groot deel van de kosten zit in de userinterface + processing. Dat kan je PC/laptop erg makkelijk en misschien nog wel beter. Je mist dan vooral de dedicated knopjes en het ziet er minder stoer uit in je home-lab

[sjoerd1980]

Kanze schreef op zondag 15 maart 2020 @ 00:56:
[...]


Ik heb nog eens tijd gevonden om die Eltako te testen. Beelden zeggen toch altijd meer dus hieronder het filmpje;

Top, het ding werkt ;-). Had je misschien ook gemeten wat het stroomverbruik is uit de 230V en uit de stuurspanning? Dat deel was me in datasheet niet zo duidelijk (loopt dat alleen als relais actief is of is er ook een ruststroom wanneer alle uitgangen uit zijn....).

[hindrikv]

Ik ben erg enthousiast geworden over domotica icm een plc.
Nu kan ik voor een leuke prijs tweedehands een 750-880 met meerdere modules krijgen.
Mijn idee is om deze te koppelen met hassio op een raspberry pi door middel van modbus.
Hassio voor de frontend en informatie van internet halen. De plc voor het "domme" werk, licht schakelaar aan - > lamp aan - > terugkoppelen naar hassio.

Nu vraag ik mij nog af hoe het programmeren van de plc werkt. Lukt dit met de gratis versie van codesys? Of heb ik hier dure software pakketen voor nodig?

[MichVw]

hindrikv schreef op maandag 23 maart 2020 @ 22:05:
Ik ben erg enthousiast geworden over domotica icm een plc.
Nu kan ik voor een leuke prijs tweedehands een 750-880 met meerdere modules krijgen.
Mijn idee is om deze te koppelen met hassio op een raspberry pi door middel van modbus.
Hassio voor de frontend en informatie van internet halen. De plc voor het "domme" werk, licht schakelaar aan - > lamp aan - > terugkoppelen naar hassio.

Nu vraag ik mij nog af hoe het programmeren van de plc werkt. Lukt dit met de gratis versie van codesys? Of heb ik hier dure software pakketen voor nodig?

Een 750-880 is enkel compatibel met Codeys V2 en niet Codesys 3.5, Codesys v2 is gratis maar veel beperkter dan dan codesys3.5. Ik heb in de tijd ook geprobeerd om met codesys v2 en modbus iets stabiel in gang te krijgen met HA maar ben toch tot de conclusie gekomen dat codesys v2 en modbus teveel beperkingen hadden.

Uiteindelijk aan de slag gegaan met een PFC200 en een MQTT library en daar zijn de mogelijkheden eindeloos. Een goed voorbeeld hiervan dat je eventueel zelf kan gebruiken:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Als je wat zoekt kan je een PFC200 ook op de kop tikken voor een prijsje (€200-€400). Zeker meer dan een 750-880 maar veel krachtiger en de meerprijs zal je veel tijd besparen maar programmatie toe om alles stabiel te krijgen.. MQTT is gewoon vele malen krachtiger dan Modbus

[Kanze]

sjoerd1980 schreef op maandag 23 maart 2020 @ 21:48:
[...]


Top, het ding werkt ;-). Had je misschien ook gemeten wat het stroomverbruik is uit de 230V en uit de stuurspanning? Dat deel was me in datasheet niet zo duidelijk (loopt dat alleen als relais actief is of is er ook een ruststroom wanneer alle uitgangen uit zijn....).

In mijn opstelling is de voedingsspanning eveneens 24VDC.

De digitale uitgang van de 750-530 trekt 0.115 mA wanneer die uitgang hoog wordt gezet. Het relais zelf trekt bij opstart even 5mA en daarna valt dat terug naar 1.3 mA. Bij het schakelen van 1 relais-kanaal liep dat op naar 1.6 mA.

Ik heb geen testen gedaan met 230V omdat dat niet van toepassing zal zijn in ons huis.

hindrikv schreef op maandag 23 maart 2020 @ 22:05:
Ik ben erg enthousiast geworden over domotica icm een plc.
Nu kan ik voor een leuke prijs tweedehands een 750-880 met meerdere modules krijgen.
Mijn idee is om deze te koppelen met hassio op een raspberry pi door middel van modbus.
Hassio voor de frontend en informatie van internet halen. De plc voor het "domme" werk, licht schakelaar aan - > lamp aan - > terugkoppelen naar hassio.

Nu vraag ik mij nog af hoe het programmeren van de plc werkt. Lukt dit met de gratis versie van codesys? Of heb ik hier dure software pakketen voor nodig?

Als je van nul wil beginnen zou ik meteen voor een controller uit de PFC200 serie gaan. Iets prijziger als een 750-880 maar werken met WAGO's éCockpit is wel zo prettig en bovendien de facto gratis. Je kan de volledig functionele trial versie van éCockpit eenvoudig terug op 30 dagen zetten en je software op de PLC blijft gewoon doordraaien.

[ Voor 39% gewijzigd door Kanze op 24-03-2020 13:24 ]

[hindrikv]

MichVw schreef op dinsdag 24 maart 2020 @ 11:23:
[...]


Een 750-880 is enkel compatibel met Codeys V2 en niet Codesys 3.5, Codesys v2 is gratis maar veel beperkter dan dan codesys3.5. Ik heb in de tijd ook geprobeerd om met codesys v2 en modbus iets stabiel in gang te krijgen met HA maar ben toch tot de conclusie gekomen dat codesys v2 en modbus teveel beperkingen hadden.

Uiteindelijk aan de slag gegaan met een PFC200 en een MQTT library en daar zijn de mogelijkheden eindeloos. Een goed voorbeeld hiervan dat je eventueel zelf kan gebruiken:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Als je wat zoekt kan je een PFC200 ook op de kop tikken voor een prijsje (€200-€400). Zeker meer dan een 750-880 maar veel krachtiger en de meerprijs zal je veel tijd besparen maar programmatie toe om alles stabiel te krijgen.. MQTT is gewoon vele malen krachtiger dan Modbus

Bedankt voor je reactie!

Ik wil de 750-880 vooral gebruiken om te praten via modbus. Wat voor soort beperkingen bedoel je als ik wel voor codesys 2 ga?

[tinus5]

Ik heb een 750-880 en gebruik Codesys 2 naar volle tevredenheid (ok de interface is echt out-dated). Bijna alle schakelacties en timer (inc een zelfgebouwde wake-up light in Codesys) draaien direct op de PLC.
Ik gebruik modbus eigenlijk alleen om te communiceren naar Openhab voor de bediening via telefoon, tablet. De enige rule die via Openhab draat is de verwarming vanm de ventilatie omdat de PLC geen eBus praat.

Ik zie dus geen beperkingen (maar je moet wel iets investeren in het leren van de PLC). Ik gebruik wel CFC waarmee ik visueel "programmeer".

[MichVw]

hindrikv schreef op dinsdag 24 maart 2020 @ 17:24:
[...]

Bedankt voor je reactie!

Ik wil de 750-880 vooral gebruiken om te praten via modbus. Wat voor soort beperkingen bedoel je als ik wel voor codesys 2 ga?

De beperkingen zitten hem in het feit dat modbus een polling protocol is. Je gaat om de zoveel tijd aan de PLC gaan vragen wat z'n status is en/of dat ie iets nieuws heeft.

Scenario: je hebt een drukknop en iedere keer als je erop druk wil je dat je software layer boven je PLC (HA, openhab, etc) hiervan op de hoogte is. Met modbus zou je dan een register hoog gaan zetten dat kan uitgelezen worden. Vraag is, wanneer ga je dat register terug laag gaan zetten? Hoe weet je met zekerheid dat het register is uitgelezen door HA/openhab? En zelfs als je dat opgelost krijgt, wie zegt dat je niet een drukknop push gemist hebt als je aan het wachten ben voor een modbus pol?

Neem er dan nog eens bij dat het best wel leuk is met een simpele drukknop meer te doen; bijvoorbeeld detecteren van enkele/dubbele en lange pushes en daar dan acties aan koppelen. Zoals bijvoorbeeld alle lichten aan/uit, aansturen rolluiken etc..

Oplossing is om eventdriven te gaan werken, Femme stuurt zo bijvoorbeeld ook z'n input events door via MQTT. Toegegeven; voor codesys 2 bestaat er ook een MQTT library maar hou er rekening mee dat die enkel een Qos 0 publish ondersteund.

Het scenario van de drukknop was maar één voorbeeld, een ander probleem is dat je met Modbus wel een register kan schrijven waarop de PLC dan iets moet doen (dat jij programmeert) maar dat je geen feedback hebt van of die actie al dan wel niet gelukt/uitgevoerd is.

Met Codesys 3.5 kan je een gratis MQTT lib gebruiken die Qos2 pub/sub ondersteund en dat word dat allemaal een stuk makkelijker. Als je later eventueel wilt veranderen van OpenHab naar HA zal dat een stuk makkelijker gaan omdat je met MQTT werkt en veel betere ondersteuning heeft bij al die software packeten.

Ook niet onbelangrijk; het programmeren van een PLC vraagt tijd, toegegeven: de leercurve is leuk maar los daarvan hoef je het warm water niet uit te vinden. Een groot deel, als het niet alles is van wat je wilt bereiken bestaat al in Codesys 3.5 en word actief door meerdere mensen gebruikt:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Onderschat het bestaan van een (al dan niet kleine) community niet rond je PLC programmatie. Problemen kunnen zo worden gedetecteerd/opgelost voor je er zelf last van ondervind en je kan genieten van de vindingrijkheid van andere mensen en daar dan zelf nog eens aan bijdragen.. Een win-win situatie voor iedereen?

[Kanze]

Helemaal eens met de analyse betreft de opzet van MQTT.

Wat betreft het programmeren van de PLC zelf is het inderdaad handig dat hier een kleine community aan het ontstaan is. Het oplossing van bugs in de software is bij PLC's niet zo snel gedaan. Geen honderden stackoverflow posts om je uit de nood te helpen. Heel veel kennis zit achter slot en grendel bij bedrijven helaas.

Voor wie de ontwikkeling van mijn sensorkit volgt nog even melden dat momenteel de ATTiny3216 chip ondertussen aangekomen is en de UPDI programmer ook reeds werkt. Momenteel werk ik samen met @MichVw om een RS485 LINK op te zetten tussen de chip en de PLC.

[UglyDinosaur]

Ik krijg het hier niet stabiel; vrees ik

Ik ga eens proberen de firmware van de PFC200 te updaten. Is er iemand die weet hoe je dit met Codesys Web Based Management kan doen? Alle how-to's die ik kan vinden zijn voor de WAGO interface...

[MichVw]

UglyDinosaur schreef op woensdag 25 maart 2020 @ 12:52:
Ik krijg het hier niet stabiel; vrees ik

Ik ga eens proberen de firmware van de PFC200 te updaten. Is er iemand die weet hoe je dit met Codesys Web Based Management kan doen? Alle how-to's die ik kan vinden zijn voor de WAGO interface...

Normaal kan je het doen vanuit Codesys, vanonder naar PFC200 en dan kan je zo updaten.

[Rob Z]

hindrikv schreef op dinsdag 24 maart 2020 @ 17:24:
[...]

Bedankt voor je reactie!

Ik wil de 750-880 vooral gebruiken om te praten via modbus. Wat voor soort beperkingen bedoel je als ik wel voor codesys 2 ga?

Hier een 750-881 PLC in gebruik die via Modbus TCP aan HA (home-assitant) hangt en aan een PV inverter en aan een Arduino voor lichtmeting, en daar komt nog temperatuur bij op den duur.
MQTT doet de PLC voor pushberichten naar Telegram via HA en voor het uit slaapstand halen van een tablet.
Daarnaast doet de PLC wat http aanroepen voor Sonos speakers en een Duco ventilator.

Het geheel werkt hier al bijna een jaar zonder problemen.

Wat erg prettig werkt is tussen een Wago PLC en HA is de mogelijkheid om via Modbus het procesbeeld van de PLC te benaderen.
Zie MichVw in "Domotica met plc's" en onderstaand voorbeeld; in de manual van de controller staat nog meer.

[UglyDinosaur]

MichVw schreef op woensdag 25 maart 2020 @ 17:03:
[...]


Normaal kan je het doen vanuit Codesys, vanonder naar PFC200 en dan kan je zo updaten.

Ik denk niet dat je hiermee de firmware kan updaten. Ik heb ondertussen via Wago de nieuwste firmware gekregen met instructies om via SD kaart te updaten. Nu merk ik wel net op de pagina van de CODESYS Control for PFC200 SL dat ze hier maar tot versie 12 van de firmware ondersteunen....

Is er iemand die weet of de laatste nieuwe FW 15 ook compatibel is? Voorlopig ga ik even wachten met te updaten...

[aaahaaap]

Goedenavond allen, volg dit topic al een tijdje en ben de zoveelste met wat vragen Hoop dat jullie me een beetje op weg kunnen helpen.

Ik ben van plan m'n domotica setup te updaten van de huidige draadloze (zigbee + MQTT) configuratie naar een bedrade setup waarbij de primaire logica (schakelaar a schakelt lampen x en y, etc) in de centrale controller zit en de controller acteert op MQTT berichten en zijn state naar MQTT publisht. Hierbij zal de "higher level" logica via iets als Home Assistant gedaan worden.
Hiervoor overweeg ik gebruik te maken van PLCs of van een programmeerbare controller (waarschijnlijk Arduino based, voornamelijk omdat ik verder eigenlijk geen andere opties ben tegengekomen) en ik vroeg me af wat jullie mening hierover is.

Kwa hardware gaat m'n voorkeur uit naar PLCs, met name vanwege de hoge mate van betrouwbaarheid en de kant en klare bouwblokken en integraties die geen grote tijdsinvestering aan de softwarekant nodig hebben. De modulariteit zie ik, ondanks m'n relatief bescheiden requirements kwa inputs en outputs, ook als een pluspunt.
Daarnaast biedt de opzet van @MichVw zo te zien een gode start voor de functionaliteit die ik zoek.

De softwarekant lijkt helaas een heel ander verhaal. Ten eerste zie ik voor nagenoeg alle PLC's alleen maar GUI programma's die ook nog eens alleen maar beschikbaar zijn voor Windows. De Siemens LOGO! controllers lijken hierop de uitzondering door hun JAVA gebaseerde software maar die ondersteunen voor zover ik heb kunnen vinden weer geen MQTT.

Kort door de bocht ben ik een "moderne" software development werkwijze gewend (dus sources in git, bouwen via CLI en automatisch deployen) en ditzelfde principe is ook een vereiste voor m'n home automation setup. Dit is iets dat erg ver af lijkt te staan van de software om PLCs mee te programmeren die ik tot nu toe heb gezien. Ik hoop dat ik hiermee niemand voor de schenen schop, maar het voelt allemaal een beetje als 10+ jaar geleden :x
Daarnaast draaien al m'n PCs op Linux en heb ik dus niks aan Windows only programma's. WINE is eventueel een optie maar de vraag is of dat goed werkt voor alle functionaliteit.
Op dit vlak lijkt een programmerbare controller (op basis van bijvoorbeeld Arduino) een stuk normaler/prettiger om mee te werken, je werkt aan je sources in je favoriete editor, commit ze, runt `make` of `platformio run` en je krijgt een gecompilde firmware voor op je controller.

Anyway, lang verhaal, om het conreet te maken, dit zijn de vragen die ik heb:
- Is het mogelijk op zo'n manier te werken met PLCs? Heeft iemand hier ervaring mee?
- Is er Linux compatible software om PLCs te programmeren?
- Zijn er CLI tools om de code voor de PLC te valideren en te uploaden naar de PLC?
- Heeft er iemand gekozen voor een microcontroller gebaseerd systeem ipv een PLC? Zo ja, hoe bevalt het? Of, als je daarna alsnog geswitcht bent naar een PLC, wat beviel er niet?

[thomke]

aaahaaap schreef op zaterdag 28 maart 2020 @ 21:53:
Goedenavond allen, volg dit topic al een tijdje en ben de zoveelste met wat vragen Hoop dat jullie me een beetje op weg kunnen helpen.

Ik ben van plan m'n domotica setup te updaten van de huidige draadloze (zigbee + MQTT) configuratie naar een bedrade setup waarbij de primaire logica (schakelaar a schakelt lampen x en y, etc) in de centrale controller zit en de controller acteert op MQTT berichten en zijn state naar MQTT publisht. Hierbij zal de "higher level" logica via iets als Home Assistant gedaan worden.
Hiervoor overweeg ik gebruik te maken van PLCs of van een programmeerbare controller (waarschijnlijk Arduino based, voornamelijk omdat ik verder eigenlijk geen andere opties ben tegengekomen) en ik vroeg me af wat jullie mening hierover is.

Kwa hardware gaat m'n voorkeur uit naar PLCs, met name vanwege de hoge mate van betrouwbaarheid en de kant en klare bouwblokken en integraties die geen grote tijdsinvestering aan de softwarekant nodig hebben. De modulariteit zie ik, ondanks m'n relatief bescheiden requirements kwa inputs en outputs, ook als een pluspunt.
Daarnaast biedt de opzet van @MichVw zo te zien een gode start voor de functionaliteit die ik zoek.

De softwarekant lijkt helaas een heel ander verhaal. Ten eerste zie ik voor nagenoeg alle PLC's alleen maar GUI programma's die ook nog eens alleen maar beschikbaar zijn voor Windows. De Siemens LOGO! controllers lijken hierop de uitzondering door hun JAVA gebaseerde software maar die ondersteunen voor zover ik heb kunnen vinden weer geen MQTT.

Kort door de bocht ben ik een "moderne" software development werkwijze gewend (dus sources in git, bouwen via CLI en automatisch deployen) en ditzelfde principe is ook een vereiste voor m'n home automation setup. Dit is iets dat erg ver af lijkt te staan van de software om PLCs meete programmeren die ik tot nu toe heb gezien. Ik hoop dat ik hiermee niemand voor de schenen schop, maar het voelt allemaal een beetje als 10+ jaar geleden :x
Daarnaast draaien al m'n PCs op Linux en heb ik dus niks aan Windows only programma's. WINE is eventueel een optie maar de vraag is of dat goed werkt voor alle functionaliteit.
Op dit vlak lijkt een programmerbare controller (op basis van bijvoorbeeld Arduino) een stuk normaler/prettiger om mee te werken, je werkt aan je sources in je favoriete editor, commit ze, runt `make` of `platformio run` en je krijgt een gecompilde firmware voor op je controller.

Anyway, lang verhaal, om het conreet te maken, dit zijn de vragen die ik heb:
- Is het mogelijk op zo'n manier te werken met PLCs? Heeft iemand hier ervaring mee?
- Is er Linux compatible software om PLCs te programmeren?
- Zijn er CLI tools om de code voor de PLC te valideren en te uploaden naar de PLC?
- Heeft er iemand gekozen voor een microcontroller gebaseerd systeem ipv een PLC? Zo ja, hoe bevalt het? Of, als je daarna alsnog geswitcht bent naar een PLC, wat beviel er niet?

PLC met de 'modernste' programeer interface zijn die van Beckhoff..
Beckhoff is gewoon in visual studio te programeren.. en Beckhoff plc's zijn eigenlijk 'Soft PLC's) wat wil zeggen dat je de ontwikkelomgeving ook perfect op de plc zelf kunt draaien (wat wel windows is) maar je hebt dan in principe geen aparte windows pc meer nodg...


Zelf heb ik een vraag voor de rest van dit forum..
Wat gebruiken jullie voor 'branddetectie'? welke rookmelders (of bij voorkeur rooksensoren) gebruiken jullie?
bij voorkeur een rooksensor die gewoon op een digitale ingang van de plc kan aangesloten worden..
(beetje als de losse AMN31112J PIR sensor , maar dan voor rookmelding zonder reeds vast te zitten aan een of andere grote lompe opbouw behuizing.. )

Bedankt!

[AUijtdehaag]

@aaahaaap Al eens naar node-red gekeken?
YouTube: Read Write Data on Siemens PLC using Node-RED (S7)
Kan zowel met een LOGO! als s7-1200

Node-red verbind zo een beetje alles met elkaar.
Ik gebruik het icm modbus, modbus tcp/ip, MBus, JSON, MQTT, domoticz, S7 logo!, Influxdb en Grafana.
(HA gebruik ik weer niet )

[ Voor 28% gewijzigd door AUijtdehaag op 29-03-2020 11:11 ]