FPGA w automatyce przemysłowej: uniwersalne płytki i środowiska programistyczne

Tue Dec 23, 2014 2:16 pm   

Taki pomysł z serii dziwnych - zamiast tradycyjnie budować sterowanie
urządzenia na jakimś PLC, pomyślałem żeby zastosować płytkę z FPGA, w
który wpakowałoby się algorytm sterujący. Teoretycznie było by to dużo
szybsze niż PLC (algorytm mógłby być nawet wykonywany równolegle zamiast
szeregowo), trudniejsze do skopiowania, użytkownik miałby mniejszą
możliwość grzebania tam gdzie nie powinien. Żeby nie wynajdywać koła na
nowo, "pogooglałem" trochę za takimi rozwiązaniami, i nic sensownego nie
znalazłem.
Czy są jakieś uniwersalne płytki z FPGA nadające się do zastosowania w
automatyce (I/O na 24V, obudowa przemysłowa itd.)? Czy są może jakieś
gotowe środowiska programistyczne do tego typu aplikacji, żeby nie
dłubać wszystkiego w VHDL?
A jeśli się jednak takiego rozwiązania nie stosuje, to z jakich powodów?

pozdrawiam

Tue Dec 23, 2014 4:16 pm   

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.

Tue Dec 23, 2014 4:47 pm   

On 2014-12-23 14:16, Piotr Dulik wrote:

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ć.

Tue Dec 23, 2014 4:54 pm   

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.

http://www.bdti.com/InsideDSP/2012/09/05/MathWorks
"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."



--
pozdrawiam
MD

Tue Dec 23, 2014 6:02 pm   

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

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

--
Irokez

Tue Dec 23, 2014 6:14 pm   

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

Tue Dec 23, 2014 6:37 pm   

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.


--
pozdrawiam
MD

Tue Dec 23, 2014 6:49 pm   

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

Tue Dec 23, 2014 6:53 pm   

On 2014-12-23 18:02, Irokez wrote:

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

Tue Dec 23, 2014 6:58 pm   

On 2014-12-23 18:49, Piotr Dulik wrote:

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.

Tue Dec 23, 2014 7:15 pm   

On 2014-12-23 14:16, Piotr Dulik wrote:

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

Tue Dec 23, 2014 8:35 pm   

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.

--
Pozdr.
Michał

Tue Dec 23, 2014 8:55 pm   

W dniu 2014-12-23 o 19:15, Marek Borowski pisze:


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.

--
pozdrawiam
MD

Tue Dec 23, 2014 9:04 pm   

W dniu 2014-12-23 o 19:15, Marek Borowski pisze:

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.


--
pozdrawiam
MD

Tue Dec 23, 2014 9:56 pm   

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.

--
pozdrawiam
MD