FPGA zamiast PLC

Dnia Tue, 23 Dec 2014 14:16:48 +0100, Piotr Dulik napisał(a):

Gdybyś znalazł, to producenci PLC na pewno by jes zastosowali. Skoro nie znalazłeś, to znaczy, że Twój pomysł jest, jak... Sam sobie dopisz.

A znasz jakąś inną rodzinę języków zorientowanych na miliony równoległych wątków? Tylko nie mów że logika drabinkowa :)

Co potrzebujesz liczyć w tym sterowniku że potrzebne jest przetwarzanie równoległe i nanosekundowe czasy reakcji? Podaj zastosowanie, to się dopasuje rozwiązanie. IMHO przemysł potrzebuje klepnąc przekaźnikiem co kilka minut a nie liczyć równolegle gigabajty kryptografii i sterować milionem silników na raz gdzie faktycznie FPGA mogło by się przydać.

W dniu 2014-12-23 o 14:16, Piotr Dulik pisze:

Oczywiście, że da się wpakować w FPGA algorytm sterowania. W ten sposób zrobisz automat na FPGA. Ale to nie oznacza, że będziesz miał sterownik PLC. Jak spełnisz warunek żeby był programowalny? Chyba nie przez to, że go możesz zaprogramować w VHDL? Jeśli zrobisz prosty, programowalny w c czy asm, kontroler na procesorze, to też nie oznacza, ze zrobiłeś sterownik PLC. Nawet jeśli zrobisz mu I/O na 24V. Kiedyś zrobiłem klientowi prosty automacik na GALu. To chyba nie oznacza, że zrobiłem PLC na GALu. Teoretycznie było by to dużo

Ale zaletą PLC jest to, że użytkownik może sobie w nim grzebać. Ja uważam za normalne, że klient domaga się kodu źródłowego.

Żeby nie wynajdywać koła na

Matlab z Simulinkiem wzbogacony o HDL Coder. Wyjdzie ci dość drogo.

"The list price for HDL Coder, now a unified product supporting both MATLAB and Simulink, begins at $10,000. MATLAB, along with the fixed-point toolbox and HDL Coder, costs approximately $20,000, according to Karnofsky. And the pricing for HDL Verifier, also now a unified product supporting both MATLAB and Simulink, begins at $3,500."

Może chce zrobić sterowanie manipulatorem na iluśtam osiach. Wtedy szybkie przetwarzanie jak najbardziej wskazane.

W dniu 2014-12-23 16:54, Mario pisze:

Nie miałem na myśli możliwości swobodnego programowania przez użytkownika, raczej nawiązanie do metody budowania układów sterowania tak, jak robiło się to >30 lat temu, czyli dedykowana logika na układach CMOS/logisterach/przekaźnikach itp. Tyle że mieszcząca się w jednej kostce a nie w kilku szafach.

Ciekawiło mnie głównie to, czemu tak się NIE ROBI. Twój link dużo wyjaśnia ;)

pozdrawiam

W dniu 2014-12-23 o 18:14, Piotr Dulik pisze:

No ale robi się takie układy sterowania. Niektórzy producenci maszyn czy np. suwnic lub żurawi robią własne sterowniki oparte na jakimś mikrokontrolerze. Ale zazwyczaj w automatyce stosuje się sterowniki dające się programować w językach zdefiniowanych w IEC-61131. Dlatego, bo tego oczekuje klient.

W dniu 2014-12-23 16:47, Sebastian Biały pisze:

To pytanie było akurat bardziej teoretyczne. Co do czasów reakcji, zdarza się że czas cyklu typowego PLC jest za długi i trzeba kombinować z dedykowanymi modułami szybkich I/O i różnymi sztuczkami programowymi. Ale fakt, takie aplikacje to wyjątki od reguły.

pozdrawiam

Raczej nie jest to robota dla amatora z powodów wielu, głównie kasy. Innymi słowy wykluczam takie zastosowanie.

Nawet wtedy zabawkowy AVR będzie miał wystarczająco "lepszy" czas reakcji. FPGA się nie nada. Głównie z powodu że:

a) drogi b) delikatny c) kłopotliwy w programowaniu d) śmieszne napięcia wymagające translacji poziomów doczegoś przemysłowego e) środowisko do tworzenia waży kilkanascie GB szitu na dysku i nikt nie wie dlaczego f) sensowne oprogramowanie do debugowania kosztuje majątek, darmowe są takie-sobie.

IMHO nie ma sensu. Potrzebujesz coś szybko - prawdopodobnie najtańszy uC załatwi probelm skuteczniej. A jak nie zalatwi - to doszywasz mały CPLD i już. Zazwyczaj problemy real-time da się zredukować do trywializmów i wyprowadzić poza uC. Reszta w uC.

Pewnie z takich powodow ze przemyslowej automatyce sterowniki rodem z lat 60-tych programowanie w jezyku drabinkowym to swietosc. Jako ze jakos to dziala nikt nie chce brac odpowiedzialnosci za potencjalne niedzialanie czegos nowoczesnego.

Pozdrawiam

Marek

W dniu 2014-12-23 14:16, Piotr Dulik pisze:

porządne szybkie PLC to w środku mają właśnie CPU+FPGA. Ale tanie to nie jest.

Nie wiem czy ty się zajmujesz programowaniem PLC, czy tylko tak sobie powtarzasz teksty zasłyszane dawno temu podczas studiów. Ja piszę programy w których są zawarte bloki w LD, SFC i ST (w S7 to jest SCL). Sam standard IEC-61131 powstał w 98 roku, więc trudno mówić, że zgodne z nim Widzę, że wielu automatyków też pisuje w czymś więcej niż ladder. Ale często nie ma takiej potrzeby. W sytuacji gdy trzeba zatrzymać ruch podajnika po pojawieniu się detalu w polu widzenia czujki, zdjąć przedmiot, uruchomić ponownie podajnik, ladder jest w pełni wystarczający. Czasy rzędu kilkudziesięciu milisekund także. Sterowniki mają czasy skanowania rzędu 1ms, a niektóre jeszcze mniej i w większości zastosowań nie jest to wykorzystywane. Żeby nie było że moje dobre samopoczucie wynika z braku wiedzy i o innych technologiach. Programuję też mikrokontrolery w urządzeniach własnej konstrukcji. Pisze też w VHDL (fuj) pod FPGA w których przetwarzanie sygnałów taktuję zegarem 20 ns. Ale to jest w urządzeniach pomiarowych. Gdyby jakiś klient koniecznie chciał sterowanie z takim taktowaniem to może bym się zainteresował. Ale nigdy mi się taki klient nie trafił. Nie twierdzę, że takich potrzeb w przemyśle w ogóle nie ma, ale moim zdaniem są marginalne.

ATSD początek PLC (z ladderem) to 1968 rok. Początek języka c to 1972, czyli cztery lata później. Czyli pisząc w c jest się w tym samym skansenie co ludki piszące w ladderze.

Nie wiem czy ty się zajmujesz programowaniem PLC, czy tylko tak sobie powtarzasz teksty zasłyszane dawno temu podczas studiów. Ja piszę programy w których są zawarte bloki w LD, SFC i ST (w S7 to jest SCL). Sam standard IEC-61131 powstał w 98 roku, więc trudno mówić, że zgodne z nim sterowniki są rodem z lat 60. Widzę, że wielu automatyków też pisuje w czymś więcej niż ladder. Ale często nie ma takiej potrzeby. W sytuacji gdy trzeba zatrzymać ruch podajnika po pojawieniu się detalu w polu widzenia czujki, zdjąć przedmiot, uruchomić ponownie podajnik, ladder jest w pełni wystarczający. Czasy rzędu kilkudziesięciu milisekund także. Sterowniki mają czasy skanowania rzędu 1ms, a niektóre jeszcze mniej i w większości zastosowań nie jest to wykorzystywane. Żeby nie było, że moje dobre samopoczucie "programisty" PLC wynika z braku wiedzy o innych technologiach. Programuję też mikrokontrolery (ARM) w urządzeniach własnej konstrukcji. Piszę też w VHDL (fuj) pod FPGA w których przetwarzanie sygnałów taktuję zegarem 20 ns. Ale to jest w urządzeniach pomiarowych. Gdyby jakiś klient koniecznie chciał sterowanie z takim taktowaniem to może bym się zainteresował. Ale nigdy mi się taki klient nie trafił. Nie twierdzę, że takich potrzeb w przemyśle w ogóle nie ma, ale moim zdaniem są marginalne. Więc nic dziwnego, że żadna poważna firma nie chce się brać za stworzenie softu umożliwiającego masom automatyków tworzenie systemów sterowania na FPGA. Synteza algorytmu dla FPGA jest dużo bardziej złożona niż kompilacja czy interpretacja kodu dla procesora. Koszt stworzenia takiego środowiska byłby znacznie większy, a zakres stosowania dość mały w skali całej automatyki przemysłowej. Przedsięwzięcie nieopłacalne ekonomicznie.

ATSD początek PLC (z ladderem) to 1968 rok. Początek języka c to 1972, czyli cztery lata później. Czyli pisząc w c jest się w tym samym skansenie co ludki piszące w ladderze.

W dniu 2014-12-23 o 20:35, Michał Baszyński pisze:

Nie znam się na budowie i oprogramowaniu wewnętrznym PLC, ale podejrzewam, że to nie jest przypadek postulowany przez Piotra. Wyobraźnia podpowiada mi, że w takich sterownikach FPGA zajmuje się protokołami komunikacyjnymi, czy bardzo szybkimi licznikami. FPGA pewnie realizuje algorytm wprogramowany jej na etapie produkcji. Od strony procka widziany jest jako jakieś peryferia o jednoznacznie zdefiniowanych właściwościach. Nie sądzę żeby automatyk tworzył kod który jest potem syntezowany i wrzucany do FPGA.

W dniu wtorek, 23 grudnia 2014 14:16:46 UTC+1 użytkownik Piotr Dulik napisał:

Pierońsko trudno w sposób jednoznaczny odpowiedzieć i cokolwiek Ci doradzić. Po kolei:

1) I/O na 24V - takich gotowców na FPGA nie zauważyłem, co nie znaczy że takowe nie istnieją. Jeżeli takowych gotowców nie ma na na rynku, to wklejasz na wyjazd bufor 7407 (open collector) i jedziesz na nim o ile mnie pamięć nie myli nawet do +30V. 2) Na FPGA, dejmy na to na Spartanach możesz grzać zegarami okrutnymi. 200+ MHz. Ino po co? Jeżeli istotnie Twój projekt tego wymaga, no to musisz jakoś to rozbybłać. 3) Nie ma się co bać VHDL'a. Nie taki dziabeł straszny jak go malujom !! W sieci jest od wała i trochę tutoriali VHDL'a , darmowy WebPack od Xilinx'a tyż mo w pizdu i nazod przykładów jak co zrobić. 4) Warto poznać ten język opisu HW, bo naprawdę jest mocny i upraszcza życie. A że jest to "strong typed language", to bardzo dobrze. Nie da się zrobić w nim burdelu. 5) A jak problemy dalej będą, to konkretnie pytaj tutaj.

W dniu 2014-12-24 o 02:22, snipped-for-privacy@gmail.com pisze:

Dla automatyki przemysłowej to lepiej byłoby dać optoizolatory na wejściu a na wyjściu przekaźnik lub optoizolator i tranzystor.

W dniu 2014-12-24 o 11:54, Mario pisze:

I tak są zbudowane fabryczne moduły I/O. Przecież nie ma extra procesorów czy układów komunikacyjnych pracujących na 24V. Porządne moduły mają optoizolowane wejścia oraz wyjścia z zabezpieczeniem termicznym i prądowym (dedykowane scalaki, nie pamiętam teraz przykładowego symbolu)

Może nie zamiast a w środku, ale za to osobno programowany. B&R chwali się modułami I/O z wbudowanym FPGA o czasach reakcji rzędu 1,0 μs. Nazwali to Reaction technology. Z mojego punktu widzenia zaletą jest sposób programowania. Programuje się za pomocą bloków funkcyjnych przygotowanych przez producenta w standardowym narzędziu dla ich sterowników ze składnią zgodną z IEC 61131. Są tam funkcje logiczne, arytmetyczne, czasowe, obsługa enkoderów etc. Dodatkowo na życzenie odbiorcy są gotowi dodać specyficzne bloki funkcyjne. No i działa to poza głównym cyklem PLC z możliwością wymiany danych i synchronizacji z zasobami obsługiwanymi w głównym cyklu. FPGA jako takie od dawna się stosowało w środku PLC i napędów, ale sądzę że powoli zacznie się jak w powyższym przykładzie możliwość samodzielnego klejenia logiki zaszytej w środku.

Paweł

W dniu 2014-12-23 21:56, Mario pisze:

nie jestem do końca zorientowany w temacie, bo się tym nie zajmuję, ale ZTCW to w zależności od tego, co sterownik ma robić (i jak szybko) to albo pisze się wsad w IEC-o zgodnym środowisku (jak szybkość niekrytyczna), Simulinku z odpowiednim modułem do danego sterownika (jak ma być szybciej) lub właśnie w VHDL-u z odpowiednim frameworkiem (jak krytyczne czasowo).