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

do góry

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

> "pogooglałem" trochę za takimi rozwiązaniami, i nic sensownego nie
> znalazłem.

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.

do góry

On 2014-12-23 14:16, Piotr Dulik wrote:
> Czy są może jakieś
> gotowe środowiska programistyczne do tego typu aplikacji, żeby nie
> dłubać wszystkiego w VHDL?

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

> A jeśli się jednak takiego rozwiązania nie stosuje, to z jakich powodów?

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

do góry

W dniu 2014-12-23 o 14:16, Piotr Dulik pisze:
> 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.

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

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
> 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?

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

do góry

W dniu 2014-12-23 o 16:47, Sebastian Biały pisze:
> On 2014-12-23 14:16, Piotr Dulik wrote:
>> Czy są może jakieś
>> gotowe środowiska programistyczne do tego typu aplikacji, żeby nie
>> dłubać wszystkiego w VHDL?
>
> A znasz jakąś inną rodzinę języków zorientowanych na miliony
> równoległych wątków? Tylko nie mów że logika drabinkowa :)
>
>> A jeśli się jednak takiego rozwiązania nie stosuje, to z jakich powodów?
>
> 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ć.
>

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

--
Irokez

do góry

W dniu 2014-12-23 16:54, Mario 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?

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.

>
> Matlab z Simulinkiem wzbogacony o HDL Coder. Wyjdzie ci dość drogo.
>
> http://www.bdti.com/InsideDSP/2012/09/05/MathWorks

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

pozdrawiam

do góry

W dniu 2014-12-23 o 18:14, Piotr Dulik pisze:
> W dniu 2014-12-23 16:54, Mario 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?
>
> 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.


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

do góry

W dniu 2014-12-23 16:47, Sebastian Biały pisze:
>
> Co potrzebujesz liczyć w tym sterowniku że potrzebne jest przetwarzanie
> równoległe i nanosekundowe czasy reakcji? Podaj zastosowanie, to się
> dopasuje rozwiązanie.

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

do góry

On 2014-12-23 18:02, Irokez wrote:
> Może chce zrobić sterowanie manipulatorem na iluśtam osiach. Wtedy
> szybkie przetwarzanie jak najbardziej wskazane.

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

do góry

On 2014-12-23 18:49, Piotr Dulik wrote:
>> Co potrzebujesz liczyć w tym sterowniku że potrzebne jest przetwarzanie
>> równoległe i nanosekundowe czasy reakcji? Podaj zastosowanie, to się
>> dopasuje rozwiązanie.
> 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.

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.

do góry