Jak napisać oprogramowanie do obsługi liczników energii przez PLC?

Witam. Nie do końca byłem pewien w jakim dziale napisać (byłem rozdarty między automatyką z PLC a programowaniem ogólnym ). Mam niemały problem - przejrzałem chyba wszystkie możliwe posty na ten temat z forum, a że nie znalazłem satysfakcjonującej odpowiedzi, postanowiłem stworzyć nowy post. Otóż - w skrócie - mam za zadanie stworzenie oprogramowania do obsługi i wizualizacji (początkowo) liczników energii. Pierwszym etapem mojej nauki w tym temacie jest bezpośrednia obsługa liczników przez Modbus RTU - na ten temat znalazłem dużo. Drugim etapem rozwoju jest sczytywanie liczników energii poprzez podłączony sterownik PLC - i tu już zaczyna się problem. W zależności od producenta, liczniki mają albo wyjścia impulsowe, albo impulsowe i do Modbus'a (chyba że są jeszcze inne). Jak podłączyć jej do PLC? Ta kwestia w zasadzie przed chwilą przyszła mi do głowy, a ta ważniejsza - w czym napisać oprogramowanie do ich obsługi? Staram się ominąć wykorzystanie serwerów OPC głównie ze względu na cenę. Program ostatecznie ma iść do klienta, którego jedynym zadaniem byłoby uruchomienie programu a całą resztę (połączenie, parametry połączenia, odpytywanie) program wykonywałby sam. Ostatecznie całość wyglądałaby tak: liczniki energii podłączone do PLC, a PLC poprzez ethernet połączone z komputerem na którym znalazłoby się oprogramowanie. Planuję program napisać w środowisku Visual Studio, jednak nie jestem pewien czy to nie skok na głęboką wodę. Wiem że różni producenci PLC udostępniają własne oprogramowanie, jednak cena wg mnie jest wprost kosmiczna (6000 zł i więcej). Ma ktoś jakieś rady?

Jeśli komputer ma być podłączony cały czas i czytać dane z PLC (logować jakieś wykresy, generować raporty) to wybrałbym liczniki z Modbus i całkiem wyeliminował sterownik. Do komputera dołożyć kartę RS485 lub przy licznikach konwerter RS485/Ethernet (jeśli impulsowe muszą być, to można też dołożyć kartę I/O).

Druga opcja to ładnie zabudować komputerek z MicroATX. Będzie miał mały apetyt na prąd, a można postawić np. serwer www i udostępniać pomiary przez stronkę.

Witam,

Koniecznie po drodze musi się znaleźć PLC? Jeżeli nie, to polecam rozwiązanie:
licznik energii <> program lumel ciepło albo lumel proces. W takim rozwiązaniu liczniki musiały by być z obsługą modbus'a. Takie rozwiązanie zostało zastosowane na jednym z zakładów przemysłowych, gdzie klient chciał mieć podgląd monitorów sieci.
Jeżeli takie liczniki (z modbus'em) by odpadały, to można wyjście impulsowe z licznika podłączyć pod wejście cyfrowe sterownika PLC (upewniając się uprzednio, czy moduł wejściowy PLC będzie w stanie obsłużyć sygnały z liczników, chodzi mi o częstotliwość np.). W programie PLC zrobić obsługę tych sygnałów, a wartości wysyłać po modbusie do komputera z oprogramowaniem.
Podejrzewam, że opcja licznik <> komputer wyjdzie taniej
Poniżej link do programów:
http://www.lumel.com.pl/pl/obszary_dzialalnosci/monitoring/

Też myślę, że wykorzystanie sterownika jest zbędne, jednak cały system z licznikami i oprogramowaniem ma funkcjonować w dużym budynku, gdzie długość przewodów na RS485 raczej na pewno przewyższyła by teoretyczne 1200 m.

edit.
Nie doczytałem jednego zdania - konwerter RS485/ethernet - o tym w zasadzie nie pomyślałem.

Do czego ma służyć ten system ?
Czy chodzi o sporadyczne odczytanie licznika celem wystawienia faktury za zużytą energię ?
Czy może trzeba analizować chwilowy pobór prądu i np. rysować wykres jego dobowego zużycia ?

W zasadzie to oba. W ogóle system ma służyć zwiększeniu wydajności budynku (BMS), a w szczególe - rysowanie wykresów m.in. dobowego zużycia, jak i generowanie faktur.

Oprogramowanie SIMEXa wygląda ciekawie, niestety producent nie ma w ofercie typowych liczników energii, a to oprogramowanie współpracuje jedynie z urządzeniami SIMEXa, stąd typowy licznik na RS485 mógłby być niekompatybilny. Klientowi niestety zależy na tym, abym stworzył oprogramowanie, które później mógłby "rozdawać" za darmo każdej osobie która zakupi liczniki energii/temperatury itp.

Bardzo dziwne według mnie podejście do tematu. Nie znasz się kompletnie na tym co masz zrobić dla klienta i chcesz się za to brać? Ci wszyscy, którzy będą potem korzystać z tego oprogramowania/rozwiązania mają być testerami?

Piszesz, że chciałbyś wykorzystać Visual Studio do stworzenia oprogramowania a jednocześnie obawiasz się czy to nie jest skok na głęboką wodę. No to więc wiesz co chcesz i czy to możesz zrobić czy nie wiesz?

Masz napisać oprogramowanie czy stworzyć cały system odczytu/rejestracji/prezentacji danych z liczników (piszesz też coś o wystawianiu faktur) ... to różne bajki.

No być może podejście mam złe. Odbywam staż w pewnej firmie która chciałaby żebym nad czymś takim pracował w czasie tegoż stażu. Za dużo szczegółów sam niestety nie otrzymuję, osoby odpowiedzialne to mieszają nieco, bo chcą aby był jeden program który obejmował wszystko (np liczniki różnych firm, ale każda ma inny protokół komunikacji). Ale coś od wszystkiego jest do niczego . Także w zasadzie mogę określić to wszystko jako oprogramowanie do gotowego systemu (w sensie: liczniki są na miejscu, zostaną połączone skrętką itp itp, a następnie wszystko by szło do centralnego komputera).

Odnośnie środowiska Visual Studio, to napisałem w ten sposób, bo być może są inne, prostsze rozwiązania.

Witam.

Uprzedzam na poczatku ze nie mam zbyt wielkiego pojecia o sterownikach PLC. Ale zakladam ze sterowniki takie maja wejscia cyfrowe. A wiec przy zastosowaniu licznika energii elektrycznej czy wody czy innego licznika, ktory posiada impulsator impuls moze wywolac przerwanie w sterowniku PLC. Teraz tak jesli na przyklad licznik energii generuje ci impuls co 1Wh w latwy sposob mozesz wyliczyc zuzycie energii mierzac sterownikiem PLC czas momiedzy jednym a drugim impulsem. Czyli jesli pomiedzy pierwszym i drugim impulsem minie czas rowny 1 minucie otrzymasz pobor energii rony 3600/60 = 60W. Sterownik zapisuje do pamieci te dane a ty przesylasz je do PC i generujesz z nich wykres.
Co ty na to ??
Uwazam jednak ze stosowanie sterownika PLC do czegos takiego to jak strzelanie z armaty do much
Pozdrawiam

Tak myślałem, że znaleźli "jelenia", któremu na głowę chcą wrzucić wszystko . Visual Studio to dobry pomysł - no ale czy aplikacja desktopowa czy webowa? Jeśli liczniki to jaki typ, protokół co siedzi w rejestrach jako dane i jak to interpretować.

Pierwsze to powinieneś zgromadzić oczekiwania i wymagania i jeśli to ma "ruszyć" Twoimi siłami to powinieneś ograniczyć się w swoich zapędach.

Powinieneś opracować sobie rozwiązanie testowe, które miałoby np. n liczniókw danego typu (magistrala 485) z protokołem MODBUS. Z liczników czytać będziesz np. moc czynną, bierną i pozorną i zapisywać to (do plików, do bazy) co określony czas. W oparciu o to będziesz mógł zrobić prezentację danych.

Jeśli będziesz mieć różne typy liczników to zaczynają się komplikacje - program musi być konfigurowalny (uwzględniający rodzaj licznika i wszystko co z tym związane).

Może w strukturze sprzętowej wystąpić coś co będzie koncentratorem danych (urządzenie, które będzie odpytywać podliczniki i trzymać ich dane w swojej pamięci) co też program (jeśli będzie rozbudowany musi uwzględniać). Oczekiwań można mieć ogrom - postaraj się to urealnić.

Dodano po 4 [minuty]:

Jeszcze jedno - tam gdzie licznik udostępnia dane powinno korzystać się z danych a nie samodzielnie liczyć zużycie na podstawie impulsów. Liczenie z impulsów prędzej czy później spowoduje rozjechanie się oryginalnego licznika i naszego licznika.

Nie wszystkie liczniki mają interfejs komunikacyjny, przykładowo liczniki gazu i wody zasilane z baterii zazwyczaj mają tylko wyjście impulsowe. Tak jak napisał gervee, do zliczania impulsów z używa się dedykowanych modułów, dla gazu po drodze jest jeszcze bariera Ex.

Sterownik PLC jak najbardziej ma sens, ponieważ daje dużą pewność działania przy kosztach znacznie mniejszych niż porządny serwer.

Zobacz system Saia S-Monitoring. W wersji prosto z półki, bez modyfikacji, działa to tak: sterownik (np. taki) ma funkcje w firmware, które wyszukują liczniki od Saia, odpytują je, zapisują dane w plikach na karcie uSD i udostępniają przez wbudowany serwer WWW.

Do tego jest aplikacja w sterowniku, która obsługuje pomocnicze funkcje typu wysyłanie maili czy obsługę przekroczenia mocy. Można do niej dopisać własny kod odczytujący liczniki od innych producentów i wrzucający je do systemu jak natywne.

Jako dodatek jest przygotowana wizualizacja (uruchamiana jako aplet Java w przeglądarce WWW na PC lub w aplikacji na Android/iOS), która umie pokazać aktualne/dobowe/tygodniowe/miesięczne zużycie i pozwala na konfigurowanie całości.

Te podstawowe funkcje są w cenie urządzeń. W wersji minimum, możesz odpytywać sterownik przez protokół HTTP, jak każdy inny serwer www.

Ja w swoich wdrożeniach dokładam do aplikacji PLC odczyt innych potrzebnych liczników (np. przez Modbus, liczniki energii przez IEC62056, za zgodą dostawcy, lub liczniki ciepła przez MBus czy co tam potrzeba), oraz próbkowanie liczników co 15 min, buforowanie w RAM sterownika (z podtrzymaniem bateryjnym) i zapis do serwera SQL na komputerze. Jak się ktoś uprze, to sterownik wyśle dane w chmurę.

Mając dane w bazie SQL, można w miarę łatwo zrobić dowolne okienka dla użytkowników, raporty, faktury, rozliczanie taryf, przekroczeń mocy biernej czy cokolwiek innego, jako serwis webowy, aplikację, pełny wybór.

Na liczniku zaczepiłem taki gadżet:

Przyklejony jest taśmą dwustronnie klejącą do płyty z pleksi. Około 10 cm za nią znajduje się licznik. Nie mogłem przyczepić czujnika bezpośrednio do licznika, ponieważ odkręcenie płyty wymaga naruszenia plomb założonych przez ZE.
Czujnik zlicza mignięcia diody LED w liczniku i przesyła je co około 1 sek. przez Bluetooth do małego odbiornika BT-LAN zasilanego przez PoE. Dalej w sieci LAN dane są rozsyłane multlicastowo. Można je więc wykorzystywać w rozproszonych systemach automatyki domowej.
Gadżet zapisuje pomiary również w wewnętrznej pamięci. W każdej chwili można je odczytać np. przy pomocy typowego smartfona. Pozwala to rysować tego typu wykresy: