pytajacy
Guest
Mon Oct 15, 2012 9:25 pm
Witam,
czy ktoś z szanownych grupowiczów ma z tym doczynienia:
http://cpdev.kia.prz.edu.pl/
Zaciekawiło mnie że można to zastosować do AVR-ów i ARM-ów.
Ale czy jest to sensowne i przyszłościowe rozwiązanie?
Co o tym sądzicie?
pytajacy
Adam Dybkowski
Guest
Mon Oct 15, 2012 9:25 pm
W dniu 2012-10-15 21:25 pytajacy napisał(a):
Quote:
czy ktoś z szanownych grupowiczów ma z tym doczynienia:
http://cpdev.kia.prz.edu.pl/
Zaciekawiło mnie że można to zastosować do AVR-ów i ARM-ów.
Ale czy jest to sensowne i przyszłościowe rozwiązanie?
Co o tym sądzicie?
A jaki to ma sens tak w ogóle?
Quote:
1. Języki programowania
tekst strukturalny ST (Structured Text),
lista instrukcji IL (Instruction List),
schemat blokowy FBD (Function Block Diagram),
język drabinkowy LD (Ladder Diagram),
język SFC (Sequential Function Chart).
Jeżeli chcesz programować AVRy to język C wystarczy w zupełności na
najbliższe kilkanaście/dziesiąt lat. Jeżeli duże AVRy i ARMy to C++ i
już. Java na ARMach też daje radę ale jest ok. 2x wolniejsza niż C.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Paweł Sujkowski
Guest
Mon Oct 15, 2012 10:28 pm
Witam
Quote:
Ale czy jest to sensowne i przyszłościowe rozwiązanie?
Co o tym sądzicie?
Moim zdaniem poznanie programowania w językach IEC otwiera drogę
praktycznie do programowania wszystkich PLC. Różnią się oczywiście
szczegółami implementacji ale ogólna idea jest spójna. Nie znam tego
środowiska, ale o ile trzyma się tych standardów to otwiera drogę do
taniego eksperymentowania z własną implementacją PLC w uP czy jako
SoftPLC (tu zapewne można zacząć eksperymenty bez inwestycji w sprzęt).
Adam Dybkowski pisze:
Quote:
A jaki to ma sens tak w ogóle?
W mojej opinii sens wynika z praktyki stosowania. Jeśli projektujesz
swój zamknięty system to oczywiście lepiej podążać wskazaną przez ciebie
ścieżką. Sens programowania w językach IEC ujawnia się w przemyśle.
Obsługa kodu przez różnych ludzi, field-upgrade, modyfikacja ad-hoc,
diagnostyka no i powszechność w stosowaniu w szeroko pojętym przemyśle.
Czasem prosty problem łatwiej jest ogarnąć "wzrokowo" w programie
zapisanym jako IL podczas bezpośredniego podglądu niż z debuggera
odczytywać jakąś zmienną w hex czy bin i gimnastykować umysł który to
bit się zmienia w nie tą stroną co trzeba. No ale oczywiście co komu
wygodniej.
Pozdrawiam.
Paweł Sujkowski
Mario
Guest
Mon Oct 15, 2012 11:17 pm
W dniu 2012-10-16 00:28, Paweł Sujkowski pisze:
Quote:
Witam
Ale czy jest to sensowne i przyszłościowe rozwiązanie?
Co o tym sądzicie?
Moim zdaniem poznanie programowania w językach IEC otwiera drogę
praktycznie do programowania wszystkich PLC. Różnią się oczywiście
szczegółami implementacji ale ogólna idea jest spójna. Nie znam tego
środowiska, ale o ile trzyma się tych standardów to otwiera drogę do
taniego eksperymentowania z własną implementacją PLC w uP czy jako
SoftPLC (tu zapewne można zacząć eksperymenty bez inwestycji w sprzęt).
Adam Dybkowski pisze:
A jaki to ma sens tak w ogóle?
W mojej opinii sens wynika z praktyki stosowania. Jeśli projektujesz
swój zamknięty system to oczywiście lepiej podążać wskazaną przez ciebie
ścieżką. Sens programowania w językach IEC ujawnia się w przemyśle.
Obsługa kodu przez różnych ludzi, field-upgrade, modyfikacja ad-hoc,
diagnostyka no i powszechność w stosowaniu w szeroko pojętym przemyśle.
Czasem prosty problem łatwiej jest ogarnąć "wzrokowo" w programie
zapisanym jako IL podczas bezpośredniego podglądu niż z debuggera
odczytywać jakąś zmienną w hex czy bin i gimnastykować umysł który to
bit się zmienia w nie tą stroną co trzeba. No ale oczywiście co komu
wygodniej.
Jeśli ktoś się chce pobawić w naukę programowania PLC to jest sporo
różnych symulatorów. Próba oprogramowania AVRa w którymś z języków IEC
nie da moim zdaniem zbyt dużego doświadczenia przydatnego do
programowania PLC. A co do debugowania to też nie wiadomo jak to jest
realizowane z poziomu CPDev. Może projekt ciekawy (chociaż wygląda na
raczej edukacyjny) i można by go wypróbować. Jednak zniechęca mnie to,
że muszę się najpierw zarejestrować zanim dowiem się czy w ogóle mają
jakieś wersje trial czy lite i jaka jest ich polityka licencyjna.
--
pozdrawiam
MD
pytajacy
Guest
Tue Oct 16, 2012 8:26 am
W sumie to jest grupa elektroników a nie automatyków, w związku z tym
mamy lekkie skrzywienie zawodowe w kierunku nie widzenia problemu w
używaniu C na mikrokontrolery.Z mojego doświadczenia wynika że 90%
automatyków ma ogromny problem z napisaniem programu w czymś innym
niż język zgodny z IEC.
Znalazłem też coś takiego:
http://cq.cx/ladder.pl
ale niezbyt mi się podoba to rozwiązanie.
W sumie to najlepiej gdyby się wypowiedział jakiś automatyk,
i określił czy sterownik wyposażony w możliwość programowania
w języku zgodnym z IEC, podnosi jego walory użytkowe?
pytajacy
JDX
Guest
Tue Oct 16, 2012 10:11 am
On 2012-10-15 22:53, Adam Dybkowski wrote:
[.....]
Quote:
Java na ARMach też daje radę ale jest ok. 2x wolniejsza niż C.
Ale to chyba do programowania aplikacyjnego a nie systemowego. Ponieważ
pomijając nawet kwestie wydajnościowe to jakoś nie potrafię sobie
wyobrazić jak oprogramować w Jawie ISR czy scheduler. Zresztą zdaje się,
że nawet do Androida jest udostępniane jakieś "native" API właśnie po
to, aby można było sobie grzebnąć niskopoziomowo w sprzęcie.