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