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

do góry

W dniu 2012-10-15 21:25 pytajacy napisał(a):

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

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

do góry

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.

Pozdrawiam.

Paweł Sujkowski

do góry

W dniu 2012-10-16 00:28, Paweł Sujkowski pisze:
> 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

do góry

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

do góry

On 2012-10-15 22:53, Adam Dybkowski wrote:
[.....]
> 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.

do góry