Sebastian Biały pisze:
> Paweł Sujkowski wrote:
>> Nie traktuj obrony drabinki jako osobisty atak na siebie i swoje
>> dokonania.
>
> 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.


Skoro podajesz, że automatyki jest około 10%, samoróbek z
mikrokontrolerami jakieś 0,5% a reszta to projekt informatyczny to sądzę
że i tak jest to zadanie na więcej niż jedną osobę. Jaki problem do
części automatycznej wydzielić automatyka, który zrobi tak jak trzeba
np. ladderem czy STL, FBD czy SFC (albo każdy moduł w innym języku
zależnie od potrzeb). A ty się zajmiesz częścią informatyczną
technologiami najbardziej do tego odpowiednimi.

>> 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.
>
> Część RT znając życie trzeba skrobac w uC. Ale pozerkam.

Zależy jakie czasy potrzebujesz.
>
>> 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.
>
> 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).

To jeszcze wyjaśnij czy to drabinka się nie nadaje czy PLC się nie
nadaje bo w końcu nie wiadomo na jaką sprzętową platformę piszesz. Jeśli
chodzi o PLC to możesz każdy moduł napisać w innym języku z listy
dostępnych na dany sterownik i na dane środowisko programistyczne.

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.


Być może źle dobrane enkodery - zbyt duża ilość impulsów na obrót.
Ponadto są gotowe sterowniki do silników krokowych nie trzeba tego robić
koniecznie na PLC. A mądry klient powinien zapłacić 500$ za gotowca
zamiast 50$ za samoróbkę. W każdej chwili może dokupić. A ktoś kto
zrobił samoróbkę za rok może być w Australii. Z reguły każdy dzień
przestoju kosztuje znacznie więcej niż koszt padniętej części.



--
Pozdrawiam
MD

do góry

Mario wrote:
> Skoro podajesz, że automatyki jest około 10%, samoróbek z
> mikrokontrolerami jakieś 0,5% a reszta to projekt informatyczny to sądzę
> że i tak jest to zadanie na więcej niż jedną osobę.

Nie. Jedna osoba jest w stanie zrobić wszystko, od PCB, przez firmware
na kilka uC a na aplikacji i bazie danych kończąc.

> Jaki problem do
> części automatycznej wydzielić automatyka, który zrobi tak jak trzeba

A co u mnie jest nie tak? Funkcjonalnie: działa od roku 24/dobe. 0
problemów. Robi co trzeba.

> np. ladderem czy STL, FBD czy SFC (albo każdy moduł w innym języku
> zależnie od potrzeb)

Masz zamiast jednego spójnego systemu pare kompletnie różnych technologii.

> To jeszcze wyjaśnij czy to drabinka się nie nadaje

Drabinka się nie nadaje.

> czy PLC się nie
> nadaje

Może niektóre PLC sie nadają do niektórych elementów. Ale obawiam się,
że ze względu na specyfikę szczególnie okolic RT enkoderów może być cieżko.

> bo w końcu nie wiadomo na jaką sprzętową platformę piszesz.

Ależ można sie domyslić. Jesli wspomniałem C++ i Jave to śmierdzi PC.
Jesli mi się uda, to większą część (szczególnie steerowanie) chcę
wynieść na specjalizowany uC (o czym ten watek _był_ jak jeszcze nie
pojawili się zwolennicy drabinek) bo pozwoli mi to na stworzenie
namiastki sterowania RT o znacznie wiekszej mocy obliczeniowej niz grupa
małych uC.

> JeśliEUR
> chodzi o PLC to możesz każdy moduł napisać w innym języku z listy
> dostępnych na dany sterownik i na dane środowisko programistyczne.

:D O nie. Bedę wtedy utrzymywał 10 roznych kawałków kodu w 8 różnych
językach na 5 różnych platformach. Faktycznie, kusząca perspektywa.

> Być może źle dobrane enkodery - zbyt duża ilość impulsów na obrót.

Jest 1200. I jest to granicznie najmniejsza wymagana ilość. Z chęcią
wstawie tam 2x-3x większe docelowo - niestety będe musiał wtedy część RT
prawdopodobnie wynieść do jakiejś logiki programowalnej.

> Ponadto są gotowe sterowniki do silników krokowych nie trzeba tego robić
> koniecznie na PLC.

I one współpracuja z enkoderami? Dokladnie tak jak chcę? To biorę od reki.

do góry

Sebastian Biały pisze:
> Mario wrote:
>>> przekaźnikami, ale poza tym znacznie więcej: łaczyc się z bazą danych,
>> Sterownik w maszynie nie jest najlepszym urządzeniem do tego.
>
> U mnie jest to komputer, prawie normalny pecet.
>
>>> czytać z 4 enkodery kwadraturowe,
>> czytają liczniki. W drabince obsługujesz tylko wartosći liczników.
>
> Ż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.

Zazwyczaj liczniki są do 20kHz ale niektóre PLC mają karty
specjalizowane do zdaje się 100k. Przychwytywanie wartości można zrobić
przez przerwanie.


>> Ladder to nie tylko styki i cewki ale też bloczki matematyczne.
>
> O tak, wiem. O ileż wygodniejsze niż napisanie nieczytelnego: pos = (
> (encoder_position + initial_offset) * number_of_gears ) / diameter;
>
>> 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.
>
> Mam na myśli zwyczajny komputer z monitorem dotykowym.
>
>> generowac raporty etc.
>> Masz to w panelu ale jak chcesz można to zrobić w ladderze na PLC i
>> wysłać portem szeregowym.
>
> Ż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.

>
>> No wiesz do sterowania większymi procesami to masz raczej DCSy a nie
>> PLC opragromawane w C++.
>
> Ale to nie jest "większy proces" tylko wymagający (w sensie RT i
> algorytmicznym). DCS ? Po co.
>
>>> To ciężko okreslić. U mnie to mieszanka C++,Javy,SQL i JavaScriptu.
>> Realizowane w sterowniku PLC?
>
> 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.
>
>> 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.
>
> No dokładnie. Czy aby o tym wlasnie nie mówię?

Ale to nie świadczy o jakimś pokemonstwie automatyków. Być może dałoby
się ten projekt zrealizować inaczej. Do obsługi silników krokowych
sterowniki silników krokowych. Reszta automatyki na PLC. Wizualizacja na
panelu graficznym. Komunikacja z serwerem bazodanowym i generacja
raportów poza maszyną. Np serwer OPC z małą aplikacją czytającą dane z
PLC i wrzucający do serwera SQL ialbo sięganie wprost po dane na panelu
graficznym (HTTP lub FTP) lub w module ethernetowym PLC. Poza tym także
PLC i panele mogą generować raporty przynajmniej w formie plików
excelowych. Pewnie wyszłoby kilka razy drożej ale istotne jest ile
kosztuje dzień przestoju maszyny gdybyś wyjechał na stałe za granicę i
ktoś by przyszedł posprzątać po Tobie. Ponadto jak realizujesz funkcje
bezpieczeństwa w tej maszynie i jak twoje sterowanie się ma do dyrektywy
maszynowej.


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

A gdzie ty widzisz przekonywanie Cię ze powinieneś zmienić. Do wielu
zadań w automatyce wystarcza w zupełności i nie są to wyłącznie zadania
kłapania przekaźnikami. To, że w przypadku realizowanego przez Ciebie
zadania nie dało (?) się tak zrobić nie jest powodem żeby postponować
standardowe technologie stosowane w automatyce - czyli PLC podstawowe
języki stosowane w nich jak ladder czy inne podobnego poziomu.

> I jakiej chwały?

Ze ty jesteś świetny a pozostali to pokemony :)

--
Pozdrawiam
MD

do góry

Sebastian Biały pisze:
> Mario wrote:
>> Skoro podajesz, że automatyki jest około 10%, samoróbek z
>> mikrokontrolerami jakieś 0,5% a reszta to projekt informatyczny to
>> sądzę że i tak jest to zadanie na więcej niż jedną osobę.
>
> Nie. Jedna osoba jest w stanie zrobić wszystko, od PCB, przez firmware
> na kilka uC a na aplikacji i bazie danych kończąc.
>
>> Jaki problem do części automatycznej wydzielić automatyka, który zrobi
>> tak jak trzeba
>
> A co u mnie jest nie tak? Funkcjonalnie: działa od roku 24/dobe. 0
> problemów. Robi co trzeba.

OK. Prze moment myślałem, że to jakiś duży projekt a nie jedna maszyna.

>
>> np. ladderem czy STL, FBD czy SFC (albo każdy moduł w innym języku
>> zależnie od potrzeb)
>
> Masz zamiast jednego spójnego systemu pare kompletnie różnych technologii.

Taak. C++, Java itp :)

>
>> To jeszcze wyjaśnij czy to drabinka się nie nadaje
>
> Drabinka się nie nadaje.
>
>> czy PLC się nie nadaje
>
> Może niektóre PLC sie nadają do niektórych elementów. Ale obawiam się,
> że ze względu na specyfikę szczególnie okolic RT enkoderów może być cieżko.
>
>> bo w końcu nie wiadomo na jaką sprzętową platformę piszesz.
>
> Ależ można sie domyslić. Jesli wspomniałem C++ i Jave to śmierdzi PC.
> Jesli mi się uda, to większą część (szczególnie steerowanie) chcę
> wynieść na specjalizowany uC (o czym ten watek _był_ jak jeszcze nie
> pojawili się zwolennicy drabinek) bo pozwoli mi to na stworzenie
> namiastki sterowania RT o znacznie wiekszej mocy obliczeniowej niz grupa
> małych uC.
>
>> JeśliEUR chodzi o PLC to możesz każdy moduł napisać w innym języku z
>> listy dostępnych na dany sterownik i na dane środowisko programistyczne.
>
> :D O nie. Bedę wtedy utrzymywał 10 roznych kawałków kodu w 8 różnych
> językach na 5 różnych platformach. Faktycznie, kusząca perspektywa.

Czasami wygodnie jest pisać różne moduły w różnych jezykach. Proste
sterowanie w ladderze a złożone obliczenia w języku bardziej symbolicznym :)


>> Być może źle dobrane enkodery - zbyt duża ilość impulsów na obrót.
>
> Jest 1200. I jest to granicznie najmniejsza wymagana ilość. Z chęcią
> wstawie tam 2x-3x większe docelowo - niestety będe musiał wtedy część RT
> prawdopodobnie wynieść do jakiejś logiki programowalnej.
>
>> Ponadto są gotowe sterowniki do silników krokowych nie trzeba tego
>> robić koniecznie na PLC.
>
> I one współpracuja z enkoderami? Dokladnie tak jak chcę? To biorę od reki.

Zdaje się, że Beckhoff dałby radę. Ale głowy nie dam. Jakbym miał
takie zamówienie to bym się zastanawiał jak je zrobić.

--
Pozdrawiam
MD

do góry

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

Ale to żadna Ameryka dla świata PLC. Ja tam zamiast krokowca wsadził bym
tu serwo. Wtedy we wspomnianym wcześniej B&R bierzesz Acoposa który to w
zasadzie ma wbudowane. Rodzaj enkodera dostosowujesz modułem (endaty,
incrementale etc). 2 wejścia trigerowe masz wbudowane. Możesz sobie
dodać moduł drugiego enkodera, jakieś wejścia/wyjścia. Z CPU łączysz
ethernet-powerlinkiem albo CAN-openem. Programujesz zgodnie z biblioteką
napędową PLC-open. Jak by się uprzeć na krokowce, to wprowadzili
ostatnio też jakieś Acoposy-micro co i krokowce obsługują i sprzężenie
zwrotne z enkoderem mają jak i wejścia trig. Przy takich sprzętach cykle
masz poniżej milisekundy i ograniczeniem dokładności jest dynamika
maszyny a nie czasy cyklu sterownika. To samo można zrobić w CPU bo i są
liczniki do enkoderów z dodatkowymi wejściami trigerowymi i moduły do
krokowców. Sądzę że tak jak pisał Mario i na Beckhoffie można coś
takiego zbudować i na Siemensie pewnie też (w tych ostatnio głębiej nie
siedzę, więc to tylko takie sobie gdybanie). Pozdrawiam.

Paweł

do góry

Mario wrote:
> Ale to nie świadczy o jakimś pokemonstwie automatyków.

Ale kto tak u diabła pisze. Zefiniujmy może co to jest pokemon. Pokoemon
to taki stworek który potrafi robić dobrze tylko jedną rzecz. Jedną.
Osoby o wąskiej specjalizacji typu "drabinki" nie są w stanie pociągnąc
tego projektu. Znakomicie poradzą sobie jak trzeba zrobić sterownik do
procesu na tasmie, tu sam bym wziął drabinki. Ale tu jest za dużo
różnych technologii.

> Być może dałoby
> się ten projekt zrealizować inaczej.
> [...]
> Poza tym także
> PLC i panele mogą generować raporty przynajmniej w formie plików
> excelowych.

No widzisz i tu jest caly czas problem. Dostaje klocki, które polepione
sa gumą do żucia i trzeba napisać dużo tej gumy żeby z tego cokolwiek
wyszło. Pewnego dnia, po zakończeniu prac okazać się może że caly system
sterowania pracuje na tak wielu różnych technologiach, że nie trafi się
nikt inny potarfiacy to ogarnąć, a glue-logic bedzie na tyle skupiał sie
na kompatybilnosci protokołów że istotna logiki się zatraci.

Każdy taki projekt bedzie ciężki do poprawienia przez osobę z ulicy.
Uważanie, że ktoś wpadnie i zrobi poprawkę w module liczącym FFT i
zadającym wychylenie tak po prostu ad-hoc jest bzdurą. Nie da rady. To
nie jest 10 malych niezależnych elementów które można zrozumieć tak po
prostu, tylko jeden duży i wynika to z istoty działania.

Ale w moim przypadku osoba która zerknie w algorytm sterowania logika
(napisany w javascripcie, bez względu jak to moze dziwnie brzmieć) nawet
bez specjalnej wiedzy z automatyki ma szanse na poprawki i do grubego
kalibru. Choć wątpie, zeby się ktoś taki trafił.

> Ponadto jak realizujesz funkcje
> bezpieczeństwa w tej maszynie i jak twoje sterowanie się ma do dyrektywy
> maszynowej.

Masz na myśli rynek europejski? Nie interesuje mnie. Mówie serio.

> A gdzie ty widzisz przekonywanie Cię ze powinieneś zmienić.

"Trzeba było wziąść PLC, bo ja zrobiłem takie coś kiedyś na 100 wyjśc i
dzialało"

> zadania nie dało (?) się tak zrobić nie jest powodem żeby postponować
> standardowe technologie stosowane w automatyce - czyli PLC podstawowe
> języki stosowane w nich jak ladder czy inne podobnego poziomu.

Widzisz, wystarczy zanegować przydatność przydatność drabinek w jednym
projekcie i już okazuje się że neguje ich istnienie w całokształcie i
kretyn jestem.

> Ze ty jesteś świetny a pozostali to pokemony :)

Nie rozumiesz intencji słowa pokemon ani kontekstu użycia. Nikt tu nie
pisze o pozostalych. Mam na myśli że projektu nie ruszyli kijem
automatycy o waskich horyzontach nakierowanych tylko na drabinki
wzbogacone jakimis prymitywnymi językami. Dostawali w łeb haslami typu
baza danych, enkoder ze sprzężeniem, ekran dotykowy i to kończyło dyskusje.

do góry

Witam

>> Ponadto jak realizujesz funkcje bezpieczeństwa w tej maszynie i jak
>> twoje sterowanie się ma do dyrektywy maszynowej.
>
> Masz na myśli rynek europejski? Nie interesuje mnie. Mówie serio.
>

Tyle że chcąc nie chcąc działasz na rynku europejskim i jeśli
sprzedajesz u nas w kraju to i ciebie obowiązują postanowienia dyrektywy
maszynowej.


> "Trzeba było wziąść PLC, bo ja zrobiłem takie coś kiedyś na 100 wyjśc i
> dzialało"
>

Jednak potraktowałeś to widać osobiście i odgryzasz się tanią
złośliwością. Zasklepiłeś swoje myślenie o rozwiązaniu problemu w
jedynym słusznym twoim zdaniem rozwiązaniu i krytykujesz inne podejścia
tylko na podstawie wąskich doświadczeń z jakimiś automatykami,
nazywanymi przez ciebie "pokemonami". Jeśli jesteś przekonany, że nie
obowiązują cię postanowienia dyrektywy maszynowej i skuteczne i
_zgodne_z_normami_ rozwiązanie funkcji bezpieczeństwa, to lepiej odpuść
sobie temat sterowania maszyn. Dla swojego i innych dobra. Pozdrawiam.

Paweł

do góry

Paweł Sujkowski wrote:
>> Masz na myśli rynek europejski? Nie interesuje mnie. Mówie serio.
> Tyle że chcąc nie chcąc działasz na rynku europejskim

A skąd ci u diabła do głowy przyszło, ze działam na rynku europejskim ?

do góry

Witam

> A skąd ci u diabła do głowy przyszło, ze działam na rynku europejskim ?

OK. Możesz swoje rozwiązania sprzedawać na wschód, bliski wschód, USA
czy gdzie indziej. Na części rynków nie wymaga się w praktyce
implementacji jakichkolwiek dyrektyw czy norm. Domyślnie założyłem że
jeśli nie jest to rynek europejski, to jest to rynek krajowy. Życzę
powodzenia.

Paweł

do góry