Użytkownik Mario napisał:
[..]
> Męczące dla kogoś przyzwyczajonego do C czy Pascala.
> Duża część poważnej przemysłowej automatyki jest na drabince, co by
> znaczyło, że ci co to robią uważają LD za wygodne narzędzie.

A od kiedy to "użytkownik" może wymuszać na producencie takie a nie inne
rozwiązanie? Gdyby była konkurencja z innym rozwiązaniem do tego
wystarczająco silna jakościowo i marketingowo by przebić się przez
obecny standard to może coś by się zmieniło.


--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

W dniu 2014-06-02 00:55, AlexY pisze:
> Użytkownik Mario napisał:
> [..]
>> Męczące dla kogoś przyzwyczajonego do C czy Pascala.
>> Duża część poważnej przemysłowej automatyki jest na drabince, co by
>> znaczyło, że ci co to robią uważają LD za wygodne narzędzie.
>
> A od kiedy to "użytkownik" może wymuszać na producencie takie a nie inne
> rozwiązanie?

Od zawsze. Użytkownikiem nie byli informatycy, ale ludzie którzy
wcześniej robili automatykę przy pomocy przekaźników i kłębka drutu.
Ladder został stworzony dla nich żeby im przypominał schematy sieci
przekaźników.

> Gdyby była konkurencja z innym rozwiązaniem do tego
> wystarczająco silna jakościowo i marketingowo by przebić się przez
> obecny standard to może coś by się zmieniło.

Obecnie jest standardem, że sterownik możesz programować w LD, ST, CFC,
SFC, FB. A czasami po prostu w C.
Chcesz wprowadzać jeszcze jakieś inne rozwiązania?


--
pozdrawiam
MD

do góry

W dniu 2014-06-02 00:47, Mario pisze:

> Możesz to ominąć stosując cewki -(S)- i -(R)-
> W dodatku nie rozumiem po co po kroku 4 wprowadzasz krok 5 będący przejściem na
kroku 1 - szukania
> pozycji krańcowej skoro w kroku 4 dojechał do pozycji krańcowej.

To była uproszczona ogólna koncepcja. Po kroku 4 jeszcze były
różne testy poprawności wykonania innych elementów procesu.

Natomiast numerowanie stanów nie było takie proste. Dla każdego
stanu przewidziany był oddzielny bit ("przekaźnik"), który
włączał się i wyłączał w odpowiednim momencie. Czyli jeśli
maszyna ma 100 stanów, to zamiast jednego licznika 7-bitowego
potrzeba 100 oddzielnych bitów - "przekaźników".

S oraz R też tam wielokrotnie używałem. Ale wciąż nie widzę
możliwości uproszczenia takiego programu i spowodowania, żeby był
bardziej czytelny. Nie pisałem wcześniej w LD, ale tu akurat
innej możliwości nie było. Miałem tylko darmowe narzędzia.
Może istnieją jakieś bardziej przyjazne dla programisty
konwertery "normalnych" programów do LD? Bo to wyglądało
jak np. pisanie mikroprogramów wykonujących instrukcje CPU...


P.

do góry

opisany powyżej przykład jest z "życia wzięty", jakieś 2 tygodnie temu.
Ofiarą jest scalak a'la CMOS Siemensa.

do góry

W dniu 2014-06-01 22:48, Tomasz Wójtowicz pisze:
> W dniu 2014-06-01 14:11, Pszemol pisze:
>> "Tomasz Wójtowicz" <s...@n...com> wrote in message
>> news:lmeq0k$lbe$1@node2.news.atman.pl...
>>>> Sprzedawca sie ucieszyl. Zamiast sprzedac za 300 sprzedal za 1200 :-)
>>>
>>> Kupiłem gdzie indziej. Jaki z tego zysk dla sprzedawcy-muzealnika?
>>
>> Chyba popełniasz tu błąd sądząc że jesteś jedynym kupcem na świecie.
>> Z punktu widzenia sprzedawcy nie było "sprzedam/niesprzedam".
>> Z jego punktu widzenia było "sprzedam teraz za 300/później za 450".
>
> Zgadzam się, o ile to później nastąpi. Iluż może być chętnych na
> 4-letnią płytę główną dwie generacje techniczne wstecz?


Na przykład ja.
Pecet z portami PCI obsadzonymi trzema kartami pomiarowymi za 20kPLN
sztuka, plus 4 porty COM, 2 LAN.
No i się padło płycie..
O ile COM/LAN na PCI-e się przesiadasz to już z tymi pomiarowymi nie
jest fajnie.
Dasz po 4 latach znowu 60kPLN na takie same karty w wersji PCIe tylko
dlatego, że posiadająca 3 porty PCI płyta główna jest 150zł droższa i 2
generacje do tyłu?

--
Irokez

do góry

W dniu 2014-06-02 13:21, Piotrne pisze:
> W dniu 2014-06-02 00:47, Mario pisze:
>
>> Możesz to ominąć stosując cewki -(S)- i -(R)-
>> W dodatku nie rozumiem po co po kroku 4 wprowadzasz krok 5 będący przejściem na
kroku 1 - szukania
>> pozycji krańcowej skoro w kroku 4 dojechał do pozycji krańcowej.
>
> To była uproszczona ogólna koncepcja. Po kroku 4 jeszcze były
> różne testy poprawności wykonania innych elementów procesu.
>
> Natomiast numerowanie stanów nie było takie proste. Dla każdego
> stanu przewidziany był oddzielny bit ("przekaźnik"), który
> włączał się i wyłączał w odpowiednim momencie. Czyli jeśli
> maszyna ma 100 stanów, to zamiast jednego licznika 7-bitowego
> potrzeba 100 oddzielnych bitów - "przekaźników".

Rozumiem, że numerowanie nie było proste bo ktoś postanowił żeby nie
było proste. Ja tam numeruję stany w zmiennej int.


> S oraz R też tam wielokrotnie używałem. Ale wciąż nie widzę
> możliwości uproszczenia takiego programu i spowodowania, żeby był
> bardziej czytelny.

Jak się człowiek nie zna na LD to może nie wydaje się czytelny.
Oczywiście gdy silnik załączasz w danym kierunku przy kilku różnych
wartościach stanu i jeszcze przy spełnieniu jakichś innych warunków to
może być mało czytelne złożenie tego w jeden rozkaz sterujący silnikiem.
Ale możesz sobie zdefiniować kilka komórek typu MotorLeft1, MotorLeft2
itd. Sterujesz je jako cewki w kolejnych stanach gdy trzeba wysterować
silnik w lewo. A potem tylko załączasz wyjście fizycznie sterujące
silnikiem jako sumę logiczną wspomnianych komórek. Niby
trochępokombinowane ale z drugiej strony jak ci się załącza silnik to
widzisz z jakiego powodu.
Ja tam lubię LD w sterowaniu ruchem. Widzisz stan wejścia sterującego
ruchem, stan czujki np krańcowej, przeciążenia, błędu hamulca czy
falownika. Wszystko w jednej linii sterującej np danym kierunkiem.

Nie pisałem wcześniej w LD, ale tu akurat
> innej możliwości nie było. Miałem tylko darmowe narzędzia.
> Może istnieją jakieś bardziej przyjazne dla programisty
> konwertery "normalnych" programów do LD? Bo to wyglądało
> jak np. pisanie mikroprogramów wykonujących instrukcje CPU...

LD można konwertować do Instruction List. Ten to dopiero wygląda jak
asembler. Jeszcze w dodatku zapis sugeruje, że wrzucasz na stos w
odpowiedniej kolejności rozkazy typu LD, ADD, MUL, AND i zmienne.
Czujesz się jakbyś programował kalkulator programowalny HP z odwrotną
notacją polską.
Do programów sekwencyjnych jest specjalny język Sequential Flow Chart.
Przyznam, że kilka razy próbowałem, ale wygodniej mi się robi to w LD.
Kiedyś całe algorytmy robiłem w ST, ale okazało się, że jego odpowiednik
w STEP7 - SCL ma na tyle inną składnię, że czułem się niekomfortowo
gdy przechodziłem z projektu na Schneidera na Siemensa i z powrotem. Tak
wiec teraz robię część pomiarową i obliczenia w ST a zwykłe sterowanie w
LD.



--
pozdrawiam
MD

do góry

W dniu 2014-06-02 20:35, Mario pisze:

>> Natomiast numerowanie stanów nie było takie proste. Dla każdego
>> stanu przewidziany był oddzielny bit ("przekaźnik"), który
>> włączał się i wyłączał w odpowiednim momencie. Czyli jeśli
>> maszyna ma 100 stanów, to zamiast jednego licznika 7-bitowego
>> potrzeba 100 oddzielnych bitów - "przekaźników".
>
> Rozumiem, że numerowanie nie było proste bo ktoś postanowił
> żeby nie było proste. Ja tam numeruję stany w zmiennej int.

To widocznie przeoczyłem możliwość aktywacji danej gałęzi
przy spełnieniu warunku nr_stanu == n. Oczywiście taki
warunek można poskładać z przekaźników i chcąc coś zrobić
w stanie nr 10 podać jako warunek:
(bit0 == wyłączony) ORAZ (bit1 == włączony) ORAZ
(bit2 == wyłączony) ORAZ (bit3 == włączony)
i podobnie ustawiać wartość nr_stanu w (prawie) każdej
gałęzi, ale to jest jeszcze mniej czytelne od używania
pojedynczych bitów. Operacje na liczbach też są uciążliwe
- trzeba użyć bloku z odpowiednim działaniem, podawać
argumenty z określonej lokalizacji, wskazywać lokalizację
wyniku, aktywować blok działania. Jeśli to jest coś
bardziej skomplikowanego niż A+B, to potrzeba kilku bloków
i robi się nieczytelne. Nawet nie próbowałem umieszczać
tego w jednej gałęzi, tylko wykonywało się "po kolei".

Kalkulatora HP z odwrotną notacją polską dawno temu używałem
i pisałem programiki! Był bardziej przyjazny niż LD.


> LD można konwertować do Instruction List.
> Ten to dopiero wygląda jak asembler.

To właściwie były równoważne zapisy programu - można
przełączać "widok" między LD a IL. Czasem czytelniejszy jest IL.
Tak mniej więcej wyglądał kod IL:

(* Network 8 *)
(*Repetitions: wartość domyślna 10*)
LD %Q0.7
OR %SM0.1
MOVE 10, %VW162
(* Network 9 *)
(*Czas rozpędzania/hamowania silnika w ms): wartość domyślna 20*)
LD %Q0.7
OR %SM0.1
MOVE 20, %VW104
(* Network 25 *)
(*Obliczenie liczby kroków*)
LD %SM0.0
MOVE %VD150, %VD140
MUL %VD136, %VD140
(* Network 26 *)
(*Obliczenie liczby kroków - c.d.*)
LD %SM0.0
DIV DI#10, %VD140
(* Network 33 *)
LD %SM0.0
AND %Q0.5
PHOME 1, %M8.0, %V220.3, %V220.3, %VW110, %VW174, %VW100, %VW102,
%VW104, %M16.0, %M0.2, %VB207

Adresy w pamięci trzeba było uzgadniać z innym urządzeniem
- panelem HMI, który komunikował się z PLC. Narzędzia do programowania
nie były zintegrowane, można było np. przygotować bazę zmiennych
z adresami i wymieniać ją między środowiskami.

Problemy były też z modułami obsługi silników krokowych, bo czasem
po prostu nie włączały się. Doczytałem, że w razie wystąpienia
"błędu" (chyba było to np. przedwczesne zatrzymanie innym blokiem,
nazywanym STOP) trzeba resetować flagę błędu w określonej komórce.
Niby logiczne, ale bez możliwości debugowania trudno czasem było
ustalić, co się dzieje.

Całkiem możliwe, że da się to zrobić lepiej. Doczytam przed ewentualnym
kolejnym programem w LD...


P.

do góry

W dniu 2014-06-03 01:41, Piotrne pisze:
> W dniu 2014-06-02 20:35, Mario pisze:
>
>>> Natomiast numerowanie stanów nie było takie proste. Dla każdego
>>> stanu przewidziany był oddzielny bit ("przekaźnik"), który
>>> włączał się i wyłączał w odpowiednim momencie. Czyli jeśli
>>> maszyna ma 100 stanów, to zamiast jednego licznika 7-bitowego
>>> potrzeba 100 oddzielnych bitów - "przekaźników".
>>
>> Rozumiem, że numerowanie nie było proste bo ktoś postanowił
>> żeby nie było proste. Ja tam numeruję stany w zmiennej int.
>
> To widocznie przeoczyłem możliwość aktywacji danej gałęzi
> przy spełnieniu warunku nr_stanu == n. Oczywiście taki
> warunek można poskładać z przekaźników i chcąc coś zrobić
> w stanie nr 10 podać jako warunek:
> (bit0 == wyłączony) ORAZ (bit1 == włączony) ORAZ
> (bit2 == wyłączony) ORAZ (bit3 == włączony)

Nie jest to dobre bo przechodząc do kolejnego stanu musisz kasować bit
poprzedniego (czy poprzednich). Łatwo o pomyłkę. A jak masz zmienną STEP
to przy warunku STEP=10 i np PozycjaKoncowa=True ustawiasz STEP na 11.
Bloczki =, >, >=, <, <= ADD, MUL czy MOVE masz praktycznie w każdej
implementacji Laddera.

> i podobnie ustawiać wartość nr_stanu w (prawie) każdej
> gałęzi, ale to jest jeszcze mniej czytelne od używania
> pojedynczych bitów. Operacje na liczbach też są uciążliwe
> - trzeba użyć bloku z odpowiednim działaniem, podawać
> argumenty z określonej lokalizacji, wskazywać lokalizację
> wyniku, aktywować blok działania. Jeśli to jest coś
> bardziej skomplikowanego niż A+B, to potrzeba kilku bloków
> i robi się nieczytelne. Nawet nie próbowałem umieszczać
> tego w jednej gałęzi, tylko wykonywało się "po kolei".

Można umieszczać w jednym rungu tylko zazwyczaj nie da się do wyjścia z
wynikiem operacji podpinać wejścia następnego bloczka matematycznego.
Trzeba używać zmiennych pomocniczych co jest dość upierdliwe.

> Kalkulatora HP z odwrotną notacją polską dawno temu używałem
> i pisałem programiki! Był bardziej przyjazny niż LD.
>
>
>> LD można konwertować do Instruction List.
>> Ten to dopiero wygląda jak asembler.
>
> To właściwie były równoważne zapisy programu - można
> przełączać "widok" między LD a IL. Czasem czytelniejszy jest IL.
> Tak mniej więcej wyglądał kod IL:
>
> (* Network 8 *)
> (*Repetitions: wartość domyślna 10*)
> LD %Q0.7
> OR %SM0.1
> MOVE 10, %VW162
> (* Network 9 *)
> (*Czas rozpędzania/hamowania silnika w ms): wartość domyślna 20*)
> LD %Q0.7
> OR %SM0.1
> MOVE 20, %VW104
> (* Network 25 *)
> (*Obliczenie liczby kroków*)
> LD %SM0.0
> MOVE %VD150, %VD140
> MUL %VD136, %VD140
> (* Network 26 *)
> (*Obliczenie liczby kroków - c.d.*)
> LD %SM0.0
> DIV DI#10, %VD140
> (* Network 33 *)
> LD %SM0.0
> AND %Q0.5
> PHOME 1, %M8.0, %V220.3, %V220.3, %VW110, %VW174, %VW100, %VW102,
> %VW104, %M16.0, %M0.2, %VB207


Dla m,nie czytelniejszy rysunek w ladderze. A szczególnie gdy monitoruję
z laptopa realizację programu w PLC.

> Adresy w pamięci trzeba było uzgadniać z innym urządzeniem
> - panelem HMI, który komunikował się z PLC. Narzędzia do programowania
> nie były zintegrowane, można było np. przygotować bazę zmiennych
> z adresami i wymieniać ją między środowiskami.


Teraz są zintegrowane. Ale to też nie musi być zaletą. W Schneiderze
możesz używać wspólnych nazw w PLC (np M258) i HMI (Magelis).
W protokole komunikacyjnym też są wysyłane nazwy zmiennych a nie
odpowiadające im adresy. W efekcie przy panującej modzie na nadawanie
długich nazw, transmisja jest zajęta głównie przesyłaniem nazw a nie
wartości :) Przy dużej ilości zmiennych to może być problem.



--
pozdrawiam
MD

do góry

W dniu 2014-06-02 19:49, Irokez pisze:
> W dniu 2014-06-01 22:48, Tomasz Wójtowicz pisze:
>> W dniu 2014-06-01 14:11, Pszemol pisze:
>>> "Tomasz Wójtowicz" <s...@n...com> wrote in message
>>> news:lmeq0k$lbe$1@node2.news.atman.pl...
>>>>> Sprzedawca sie ucieszyl. Zamiast sprzedac za 300 sprzedal za 1200 :-)
>>>>
>>>> Kupiłem gdzie indziej. Jaki z tego zysk dla sprzedawcy-muzealnika?
>>>
>>> Chyba popełniasz tu błąd sądząc że jesteś jedynym kupcem na świecie.
>>> Z punktu widzenia sprzedawcy nie było "sprzedam/niesprzedam".
>>> Z jego punktu widzenia było "sprzedam teraz za 300/później za 450".
>>
>> Zgadzam się, o ile to później nastąpi. Iluż może być chętnych na
>> 4-letnią płytę główną dwie generacje techniczne wstecz?
>
>
> Na przykład ja.
> Pecet z portami PCI obsadzonymi trzema kartami pomiarowymi za 20kPLN
> sztuka, plus 4 porty COM, 2 LAN.
> No i się padło płycie..
> O ile COM/LAN na PCI-e się przesiadasz to już z tymi pomiarowymi nie
> jest fajnie.
> Dasz po 4 latach znowu 60kPLN na takie same karty w wersji PCIe tylko
> dlatego, że posiadająca 3 porty PCI płyta główna jest 150zł droższa i 2
> generacje do tyłu?
>

To trochę inny problem. Tak naprawdę to coś warte są te karty. Płyta i
procesor to tylko "obudowa".

do góry