Poszukiwanie płytki ARM9 z 16MB RAM na moduł do wbudowania w urządzenie

Sun Jan 10, 2010 12:20 am   

Szerokie horyzonty ....
W takim razie SZACUNEK.

AK

Sun Jan 10, 2010 2:29 am   

Sebastian Biały pisze:

Miałem z pięć lat temu do czynienia ze sterownikiem suwnicy zrobionym na
Tigerze. Po zapoznaniu się z Tigerem powiem że kijem bym go nie tknął i
dziwię się że ktoś zawodowo zajmujący się automatyką bawi się czymś takim.


Nie uważam drabinek za pokemonowe pisanie. Przynajmniej wygląda dość
podobnie u różnych producentów, Czego nie można powiedzieć o np STL.
Przy pracy z różnym sprzętem przekąłda się to na ilość błędów. Ponadto
łatwiej analizować w rybie online.




--
Pozdrawiam
MD

Sun Jan 10, 2010 9:10 am   

Mario wrote:

Dlatego powinieneś zapytać o okoliczności tej zabawy. A były one ad-hoc
na wczoraj. 2 dni na nauczenie się podstaw tego języka, odpalenie
tigera, zorientowanie się że to _niebywałe_ gówno i napisanie sporego
kodu. Ilość przekleństw jakie leciały w kierunku tego czegoś podczas
pisania wyrczerpała mój limit miesięczny.

Nie polecam. Nawet jako podstawkę pod kubek.


"Panie Krzysiu, a dalo by radę, żeby ilość elementów na lini zrzucic pod
koniec dniówki do naszej siciowej bazy danych razem z indetyfikatorem
pracownika który montował?"

"Nie".

"Aha".

Pi razy drzwi tak wyglądają dyskucje z drabinkowcami.

Doceniam to że ich metody są skuteczne. Ale one sa skuteczne dla
trywialnej logiki.


Masz na mysli _ten_ STL z C++?


Bez przesady, debugowanie w zwykłym programie jest po wielokroć
bardziej elastyczne wlacznie z mozliwością napisania sobie własnego
narzedzia do debugowania wewnątrz żywego kodu.

Sun Jan 10, 2010 5:25 pm   

Sebastian Biały pisze:

No cóż jeśli masz do czynienia z ludźmi którzy mogą tylko trywialną
logikę w drabince to współczuję. Ale to nie wina drabinki. W niej można
napisać większość kodu odpowiedzialnego np. za ruchy maszyny, a
specyficzne zadania umieścić w odrębnym bloku pisanym jak tam sobie
chcesz. Zaleta jest taka, że drabinkowy kod łatwiej później przerobić
przez innego automatyka. Zaleta o ile podchodzisz do tego inżynierko a
nie handlowo

Nie chodzi mi o szablony Miałem na myśli coś co u Schneidera nazywa
się Structured Text Language a u Siemensa Statement List Programming
Language. W Unity wygodnie mi się pisze w ST a jak mam zaraz potem coś
zrobić w STL w STEP7 to jestem chory. Jakieś to dziwaczne. To ja już
wolę w drabince.



Dla mnie jest wystarczająco komfortowo gdy widzę w którym wierszu
(networku) maszyna mi utknęła i jak są wysterowane styki drabinki. Nie
wiem co to u Ciebie zwykły program ale pewnie coś w C/C++. Ja do PLC
piszę w FBD/STL zakładając, że ktoś obcy będzie to rozwijał to po co mu
utrudniać. No i C nie jest standardowo w sofcie do programowania PLC.
Natomiast do własnych produktów na mikrokontrolerach piszę w C/C++ i
zakładam ze to ja będę ten kod rozwijał.

--
Pozdrawiam
MD

Sun Jan 10, 2010 7:23 pm   

On Sun, 10 Jan 2010 09:10:32 +0100, Sebastian Biały wrote:

Jak bedziesz mial bardziej zaawansowane programy to rozmowa moze sie
skonczyc tak samo.
"nie"
"czemu nie ?"
"bo musialbym dodac do programu TCP/IP i pare innych protokolow, a do
hardwaru ethernet i jeszcze pare innych portow do czytnika, i pamiec,
a wiec zaprojektowac sterownik calkowicie od nowa".

Kazde urzadzenie ma swoje ograniczenia.

I paradoksalnie za rok odpowiedz moze byc: "Da sie, tylko musimy
wymienic sterowniki na nowy model. Ja potem szybko przeniose program,
bo drabinkowy to latwo, i tylko troche doprogramowac musze".


Przy wielowatkowym programie z koniecznoscia dzialania na zywym
obiekcie tez nie jest tak prosto :-)

J.

Sun Jan 10, 2010 7:53 pm   

Witam

Ja też chciałem stanąć w obronie języka drabinkowego. Przy aplikacjach
automatyzacji maszyn ma moim zdaniem niezaprzeczalne zalety w postaci
czytelności kodu i łatwości debugowania oraz sporej przenośności. To,
że aktualnie można odnieść wrażenie że "wiedza potaniała" i za
programowania w drabince biorą się ludzie o różnym stopniu
przygotowania nie powinno być argumentem przeciw programowaniu w
tymże, a przeciw zajmowaniu się takimi zadaniami przez przypadkowych
ludzi. Ogólne szukanie oszczędności powoduje że jest duża presja na
działy utrzymania ruchu, aby to one zajmowały się modernizacją maszyn.
I takie są efekty. NIeporozumieniem jest moim zdaniem także ładowanie
jakiś płytek z uC i programowanie tego w C/C++/Assemblerze do
aplikacji maszynowych. Czy bariera powiedzmy 5, 10 czy 15kPLN za
porządny sterownik jest dla potencjalnego inwestora nie do
przeskoczenia? Jeśli myślimy na krótką mętę, to potencjalnie przejęcie
części z różnicy pomiędzy przemysłowym rozwiązaniem a rozwiązaniem na
uC może się wydać atrakcyjne. Ale sterowania powinny być projektowane
w szerokiej perspepktywie czasowej. Zdarzało mi się ratować maszyny z
przed ~20 lat, na sterownikach firm o których nigdy nie słyszałem ale
z wydrukowanym oprogramowaniem w drabince. I po przepisaniu tego i
wsadzeniu do jakiegoś S7 czy jakiegokolwiek współczesnego sterownika
ruszało to omal z kopa. Czy program w C na jakiejś płytce to zapewni?
Ogólnym problemem jest świadomość osób które podejmują decyzje
finansowe dotyczące takich inwestycji. Dla nich nie liczą się
standardy, normy i zdrowy rozsądek. Ma być po prostu tanio. Muszę się
przyznać że sam czasem też stosuję uC do specyficznych funkcji. A to
przetłumaczenie jakiś protokołów, a to specyficzne uzależnienie
czasowe itp. Ale ładować logikę maszyny łącznie z funkcjami
bezpieczeństwa w wyłącznie swoje dzieło to już za dużo. Pozdrawiam.

Paweł

Sun Jan 10, 2010 8:12 pm   

Paweł Sujkowski pisze:

I tak i nie. Jak Ci się uda przekonać klienta, że trzeba wydać na
sterownik 15 tysięcy to nie jest będzie problemem przekonać go do
zapłacenia Ci np. 5kpln za programowanie. Jak dasz się namówić na
robienie tego na Atmelu to ciężko jest przekonać klienta, że taka płytka
w uniwersalnej obudowie jest warta 5kpln. A w tym jest wykonanie płytki,
zaprogramowanie, gwarancja na sprzęt. Narobisz się znacznie więcej i
jeszcze boisz się o takie pierdoły jak CE. Dlatego stanowczo odradzam
klientowi robienie sterowania maszyny na samoróbce.

Ale sterowania powinny być projektowane

Też raczej robię tylko pomiar na uC a z niego wyjście do PLC na RS485
lub przekaźnikami. Chociaż bywało, że zostałem"zmuszony" do sterowania
ruchem maszyny z Atmela Ale była to zamiana czyjejś umioerającej
prowizorki na moją.

--
Pozdrawiam
MD

Sun Jan 10, 2010 8:16 pm   

Mario wrote:

O widzisz. I w tym cały problem z drabinkami. Same w sobie są
bezużyteczne do poważniejszych zastosowań. Co najwyżej można klepać
przekaźnikami.


Jak bym slyszał starego wykładowcę fizyki (współcześnie): "Piszcie w
fortranie, inni będa sie mogli łatwo połapać" ;)


Podchodze do tego w jedyny możliwy sposób. Maszyna musi: kłapać
przekaźnikami, ale poza tym znacznie więcej: łaczyc się z bazą danych,
czytac barkody, komunikowac się z paronastoma silnikami krokowymi,
czytać z 4 enkodery kwadraturowe, wykonywac analizę widmową pewnego
sygnalu i na tej podstawie sterować całością, prezentować wyniki na
monitorze dotykowym, generowac raporty etc. Po prostu projekt przerasta
logikę drabinkowa nawet uzbrojona w dodatki o parę rzedow wielkości.


Masz na mysli to BASICo podobne coś ? Obrzydliwe, smierdzi tutaj ta samą
koncepcja co TigerBasic. Z reszta to znakomicie potwierdza teze: logika
drabinkowa jest tak prymitywna, ze trzeba ja łatac byle czym co
przypomina jakis jezyk imperatywny. Pechowo istnieje ogólne pojecie, że
basic jest najlepszy. Efekty widać: setki dialektów basicowych zgodne
tylko same z soba z coraz to bardziej chora składnią "bo nam się taki
akurat parser zrobił".


Żebym ja miał _tak prymitywne_ problemy jak to gdzie maszyna utkneła ;)


To ciężko okreslić. U mnie to mieszanka C++,Javy,SQL i JavaScriptu.


Ktos obcy nie da rady. Kod sterujący ma grubo ponad 10 tysięcy linijek
skomplikowanego kodu obiektowego. Nie, nie da się prośćiej.


Mikrokontolery (w parunastu sztukach) to jakies 0.5% kodu całości.

Zmierzam do tego, że projektu który zrobiłem (i rozwijam) automatyk z
workiem sterowników PLC nie da rady zrobić nawet w małym fragmencie.
Automatyki jest mniej niz 10%, reszta to informatyka. I prawda jest taka
że tego nikt kijem uzbrojonym w drabinki nie ruszył od dawna. Nie dałby
rady i wiekszośc sobie z tego doskonale zdawała sprawę.

Sun Jan 10, 2010 8:20 pm   

J.F. wrote:

I dlatego dopytywalem w tym watku o sterownik z dużym zapasem ficzerów.
Wtedy taka argumentacja nie ma sensu.


Kwestia tego czy się jest programista czy programatorem.

Sun Jan 10, 2010 8:29 pm   

Paweł Sujkowski wrote:

Innymi słowy w swojej logice drabinkowej spokojnie wykonujesz zapytania
SQLowe wciskając do bazy danych wartośc 3-ciej harmonicznej kształtu pradu?

Wiesz, na wyraźnie zaznaczylem, że tego projektu nie dotknął żaden
automatyk jak zobaczył co należy zrobić i jak. Niektórzy bardziej
światli proponowali LabView, ale szacowana wartość sprzetu
pomiarowo-sterującego + licencja + wynagrodzenie przerosła by wartość
urządzenia kilkukrotnie, a i tak trzeba by częśc RT pisać na
mikrokontolerach.


Sa sytuacje które wymagają samorobek choćby z tego powodu że nie ma
gotowych rozwiązań, albo są w cenie przekraczającej zdrowy rozsądek.


Jesli zdołałeś wydrukować kod drabinkowy i go ponownie przepisać bez
błedow to zaryzykuje stwierdzenie, że bylo to cos przerażająco
trywialnego. Nie o taki projekcie tu rozmawiam. Gdybym potrzebował
kłapać paroma przekaźnikami i czytać pare sensorów to bym sie nie bawił
w jakieś pierdoły z wlasnymi uC.


Niektórzy złośliwcy twierdzą, że jeśli programista nie był idiotą to tak.


No widzisz. Nie wszystk da się zrobic drabinkami.

Sun Jan 10, 2010 9:29 pm   

Witam


Nie traktuj obrony drabinki jako osobisty atak na siebie i swoje
dokonania. Są fragmenty softu które lepiej będzie pasowało
zaimplementować w drabince a inne w czymś innym. Ale nie znaczy to, że
zaraz należy brać się za budowanie wszystkiego od podstaw. Od kilku lat
stosuję między innymi sterowniki B&R. Można je programować we wszystkich
językach IEC, oraz w ichnym basicu a także C/C++. Jak się bliżej
przyjrzeć narzędziu, to pod spodem leży gcc. Ze strony sprzętowej, to
aktualnie i386 od 100MHz do GHz. Przy możliwościach i niezawodności
typowego PLC możesz mieć do dyspozycji też PC-ta. Do tego wszystkie
sieci przemysłowe, certyfikacje standardy itp.


Moi zdaniem kwestia ceny. Pułap zdrowego rozsądku jest mocno zaniżany
przez klientów, którzy chcieli by cuda za pół darmo.To moim zdaniem jest
problem.


Zapewniam cię że nie było to zadanie dla logo czy s7-200. Może maszyna
nie łaczyłą się z SQL-ową bazą ale dobra setka wejść i podobna ilość
wyjść tam była. Pozdrawiam.

Paweł

Sun Jan 10, 2010 9:44 pm   

Paweł Sujkowski wrote:

Odwrotnie. To drabinkowcy traktują implementacje czegokolwiek większego
nie-w-drabinkach jako atak na swoje środowisko. Gdyby tylko mógł napisać
to co pisze w drabinkach, to bym to zrobił. Nie moge. Mając do wyboru
hermetyczną implementację hardware/software (jak np. wspominany Tiger)
albo otwarte środowisko programistyczne wybór wydaje sie dość jasny.


Część RT znając życie trzeba skrobac w uC. Ale pozerkam.


Jaki był poziom logiki sterowania tych setek wyjśc? To algorytm zapisany
za pomocą seri if'ów drabinkowych? Czy liczyleś moze transformatę
fouriera? Ja nie podaje ile mam przekaźników do sterowania cz sensorów
bo to nieistotne. Bardziej istotne co robił. Jesli tylko podejmowal
proste decyzje to akurat mógł miec i milion wyjść.

Stoje na stanowisku ze logika drabinkowa jest zdecydowanie zbyt
prymitywna do mojego zastosowania. W dodatku prawie wszyscy to
potwierdzają (włącznie z Tobą) że istnieją do trudniejszych zagadnień
lepsze narzedzia. No więc wlasnie o tym mówie. Do mojego zastosowania
logika drabinkowa się nie nadaje (a zostało to odebrane "ze nie nadaje
sie do wszystkiego" - nigdy tak nie twierdziłem). Swoją droga nie
nadawały się też sterowniki programowalne w językach wyższego poziomu
(ze względu na to że czesto hasło "RT" to zwykła ściema). Znalezienie
dekodera sygnału kwadraturowego z funkcja łapania wartości i sterującego
nadążnym silnikiem krokowym rozbijalo się o problem typu "nie wyrobi się
na tej predkosci" i zostalo tylko rekodzieło. Fakt, nieprofesjonalne,
ale za to dzialające za $50 lepiej niż niedziałający gotowiec za $500.

Mon Jan 11, 2010 12:09 am   

Sebastian Biały pisze:

Sterownik w maszynie nie jest najlepszym urządzeniem do tego.


Nie ma problemu nawet w drabince.

komunikowac się z paronastoma silnikami krokowymi,

Także


czytają liczniki. W drabince obsługujesz tylko wartosći liczników.
Ladder to nie tylko styki i cewki ale też bloczki matematyczne.


No to już gorzej - zwłaszcza że pasmo częstotliwości chwytane przez
wejścia analogowe w PLC jest żałosne.

i na tej podstawie sterować całością, prezentować wyniki na

To robi miniSCADA w panelu który łyka dane z PLC. Zakładam że pisząc o
monitorze dotykowym miałeś na myśli panel graficzny.

generowac raporty etc.

Masz to w panelu ale jak chcesz można to zrobić w ladderze na PLC i
wysłać portem szeregowym.


No wiesz do sterowania większymi procesami to masz raczej DCSy a nie PLC
opragromawane w C++.


Realizowane w sterowniku PLC?


Pisałeś że:
c) półzawodowo robie bardzo nietypowe rzeczy z automatyki przemyslowej
(głównie to czego inni pokemoni od logiki drabinkowej kijem nie dotkną,
bo "panie, nie da rady")

Jeśli projekt, który realizujesz jest w głównej mierze informatyczny
realizowany na komputerach technologiami informatycznymi to wydaje się
oczywiste, że automatyk z workiem sterowników sobie z nim nie poradzi.
Nie poradzi sobie też ze zrobieniem systemu informatycznego do banku i
żaden w tym powód do chwały dla fachowca który będzie to realizował
technologiami odpowiednimi do zadania.

--
Pozdrawiam
MD

Mon Jan 11, 2010 12:42 am   

Mario wrote:

U mnie jest to komputer, prawie normalny pecet.


Że by to było takie proste... liczniki nie dość, ze musza być szybkie,
to musza oferować dodatkowo dwa niezależne zatrzaski 24 bitowe z
prezycją zatrzaśnięcia nie gorsza niż 1 impuls i w dodatku robiąc
mechanizm nadążny do silnika krokowego. Prędkośc impulsow kwadraturowych
około 10kHz. Zajmuje się tym u mnie wydzielony uC, bo zadanie czysto RT.


O tak, wiem. O ileż wygodniejsze niż napisanie nieczytelnego: pos = (
(encoder_position + initial_offset) * number_of_gears ) / diameter;


Mam na myśli zwyczajny komputer z monitorem dotykowym.


Że co ? Raporty to ja mam na mysli pliki pdf, albo wrzucanie tego online
do www w celu analizy statsytycznej procesu. To jest dla mnie "raport",
nie wyjaśnilem tego precyzyjnie.


Ale to nie jest "większy proces" tylko wymagający (w sensie RT i
algorytmicznym). DCS ? Po co.


Nie. Sterownikiem jest PC. Część RT delegowana jest do kontrolerów. Dane
sa zbierane i analizowane przez normalny komputer z rozsadną moca
obliczeniową i możliwością debugowania. Komputer wykonuje również
elementy sterowania nie wymagające RT.


No dokładnie. Czy aby o tym wlasnie nie mówię?


Czekaj. Chcesz teraz powiedziec że PLC i drabinki sa nieodpowiednie dla
tego zadania? To po co to ciagłe przekonywanie mnie ze powinienem
zamienić jasny i wygodny jezyk programowania na masę poziomych kresek
wsadzonych w urzadznie xN razy drozsze i nie spelniające żadnych
docelowych zadań tego systemu?

I jakiej chwały?

Mon Jan 11, 2010 12:45 am   

Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:hia7no$6lc$1@achot.icm.edu.pl...


http://emea.kontron.com/products/computeronmodules/xboard/
http://emea.kontron.com/products/computeronmodules/e2brain/

@