Drukuj

 

Aktualności:

Powrót do strony głównej: www.edom-plc.pl

[kempa007]

Czy ktos steruje wyjsciami Wago po czystym modbusie i jednoczesnie korzysta z wlacznikow  fizycznych? Mam problem ze zmienianiem stanow po skorzystaniu z wlacznika na scianie. Obecnie probuje to rozgrysc korzystajac z programu Modpoll.

[Simeone]

Czy ktos steruje wyjsciami Wago po czystym modbusie i jednoczesnie korzysta z wlacznikow  fizycznych? Mam problem ze zmienianiem stanow po skorzystaniu z wlacznika na scianie. Obecnie probuje to rozgrysc korzystajac z programu Modpoll.

Nie można jednemu wyjściu przypisać wartości w więcej niż jednym miejscu w programie, bo będzie się to gryźć.

Jeśli chcesz sterować wyjściem na dwa sposoby to musisz sygnały sterujące połączyć OR-em np.:

Kod: [Zaznacz]

Light1_LatchingRelay(xSwitch := xIN_Gabinet OR VIS_Light_Gabinet); (*xIN_Gabinet to wejście z wyłącznika a VIS_Light_Gabinet zmienna ustawiana z wizualizacji po Modbusie *)

xOut_Gabinet := Light_1.xActuator; (* Ustawienie wartości wyjścia fizycznego *)


[kempa007]

Tak tez robie. Ogolnie zmianiłem już Openhaba, aby zawsze puszczał mi "1" bez wzgledu czy komenda jest on, czy off.
I ogolnie działa mi to w tej chwili ręcznie, tzn. gdy zapodaje sygnal z OH i reczenie go zeruje programikiem modpoll.

Problem w tym, że w PLC coś nie chce banglać tak jak sobie to założyłem. Wrzucam kod (zmienna modbus_OUT to zmienna zapisywana przez OH, a Modbus_IN odczytywana). Może ktoś mnie oswieci, ogolnie program blokuje fakt,ze Impuls_swiatlo.IN= przyjmuje wartość TRUE na stałe) mimo iż xModbus jest FALSE. Moje pytanie, bo widziałem w poprzednich Twoich postach, że robisz jeszcze pewne opóźnienie zanim wyzerujesz zmienna modbusa - czy był ku temu jakis powod? Bo tutaj na forum zwykle zerowanie zmiennej z wizualizacji w wielu przypadkach najwyraźniej działa.

Kod: [Zaznacz]


Impuls_swiatlo(IN:=xModbus_OUT, PT:=T#200MS);

Oswietlenie_Gabinet(xSwitch_1 :=xIN_oswietlenie_Gabinet_1 OR Impuls_swiatlo.Q);
xOUT_oswietlenie_Gabinet_1 := Oswietlenie_Gabinet.xLight_1;

Modbus_OUT:=0;
Modbus_IN: xOUT_oswietlenie_Gabinet_1



[kempa007]

Tak w ogole to ten blok TP to pozostałość po tym jak walczyłem ze zmiennym sygnałem z OpenHaba. Teraz w teorii powinno wystarczyć sterowanie bezpośrednio zmienną modbus i jej zerownie.

Kod: [Zaznacz]

Oswietlenie_Gabinet(xSwitch_1 :=xIN_oswietlenie_Gabinet_1 OR Modbus_OUT);
xOUT_oswietlenie_Gabinet_1 := Oswietlenie_Gabinet.xLight_1;

Modbus_OUT:=0;
Modbus_IN: xOUT_oswietlenie_Gabinet_1
Niestety też mi to nie chce ruszyć...

[Simeone]

Kod: [Zaznacz]

Oswietlenie_Gabinet(xSwitch_1 :=xIN_oswietlenie_Gabinet_1 OR Modbus_OUT);
xOUT_oswietlenie_Gabinet_1 := Oswietlenie_Gabinet.xLight_1;

Napisz jeszcze co to za zmienną parametryzujesz w pierwszej linii.
Jeśli to bloczek Fb_LatchingRelay z biblioteki Building_common.lib to u mnie ma inne nazwy wejść i wyjść:

[kempa007]

Tak wiem. To moj wlasny blok funkcyjny w ktorym na raz obsluguje trzy bloki fblatching bo w pokojach mam glownie po trzy punkty oswietlenia i sobie wymyslilem, ze dluzsze przytrzymanie pierwszego wszystko zapsla a drugiego wszystko wylacza i chcialem uproscic nieco kod w glownym programie.

Tak czy inaczej testowalem to tez na czystym fb_latching i nawet nie zapalalo swiatla. Jutro jeszcze raz sie temu przyjrze.

[kempa007]

No to w załączniku pokazuję czysty przykład FB_Latching. Problem jest coś ze zmienną xModbus_OUT (do której zapisuję zmianę stanu przez modbusa).

Mimo iż zmienna jest FALSE, xButton przyjmuje wartość TRUE na stałe, gdy tylko prześle po modbusie wartość 1 (nie wiem czy po wyzerowaniu zmiennej xModbus_OUT, nie powinno się to zmienić także na FLASE- tak chciałbym, aby to działało). Gdy przez modbusa przesle 0 i jeszcze raz 1 to załączanie światła działa, ale obecnie chcę, aby każde podanie 1 na modbusa powodowało zmianę stanu a zmienna xModbus_OUT ma się zerować automatycznie.

Może tutaj chodzi o mapowanie zmiennej w rejestrze modbus? Jak to ugryźć?

[Simeone]

Załączam nagranie jak to działa u mnie na standardowym bloku FB_Latching_Relay z biblioteki Building_common.lib

LINK

Wszystko co potrzeba to jeden FB (Light_1), jedno wyjście fizyczne (xOut_...) oraz jedna zmienna sterująca (VIS_Light...) ustawiana przez Node-Reda po modbusie na 1 i zmieniana w każdym cyklu na 0

Spróbuj to zaimplementować w ten sposób daj znać jaki wynik

[kempa007]

No to to co jest w moim zalaczniku jest takie samo, tylko dochodzi or z wlacznika na scianie.
 Zmienna xModbus_OUT to tak jakby Twoja visualizacja. Ja do niej zapisuje pierwszy coil modbusa 32768. Tylko teraz to wyglada tak jakby mapowanie zmiennej modbusa i zmiennej plc sie rozjezdzalo... jutro chyba do wago zadzwonie.

U mnie zapodanie 1 przez modbusa wlacza swiatlo, ale pozniej juz nic nie moge zrobic do czaau przeslania recznie zrra po modbusie do coil 32768. Mimo, ze zmienna xModbus_OUT zeruje i w plc ma ona wartosc false. Ogolnie zastanawia mnie czemu wejscie xButton jest stale TRUE mimo, ze xModbus_OUT i wejscie reperezentujace wlacznik na scianie sa FALSE.

[kempa007]

Załączam nagranie jak to działa u mnie na standardowym bloku FB_Latching_Relay...

A Ciebie pewnie dziwia inne nazwy wejsc i wyjsc. Ja korzystsm z eruntime na eCockpicie  a Ty z Codesysa. Po aktualizacji bibliteki pojawily sie nowe oznaczenia, ale to ten sam blok.

[kempa007]

No i kolejny dzień mija mi na testach i próbach, ale bezskutecznie. Dzisiaj trochę protestowałem i faktycznie jest tak, że mimo iż PLC zeruje zmienną xModbus_OUT, to w rejestrze modbusa przyjmuje ona cały czas wartość 1. Wynika z tego, że mapowanie w eCockpit jest chyba tylko w jedną stronę. Gdy zmieniam rejestr modbusa aktualizowana jest zmienna w PLC, ale gdy zmienię zmienną w PLC, to nie jest ona aktualizowana w modbusie.

Podjąłem więc próbę adresowania zmiennych poprzez %MX0.0, ale gdy stworzyłem sobie przykładową zmienną:

Kod: [Zaznacz]

var
test AT %MX0.0 : bool;
end var

test:=1;

odpytanie modbusa po adresie 12288 daje wynik 0. Mój sterownik to PFC 200. Czy ktoś wie jak po modbusie odczytać z niego zmienną adresowaną w powyższy sposób?

[Simeone]

Jeszcze taka myśl mi się nasunęła - zdaje mi się, że zmienne adresowane %MX... powinno się deklarować w sekcji zmiennych globalnych.

Spróbuj dodać nową listę zmiennych i w niej umieścić te wszystkie deklaracje

[kempa007]

Dodałem, ale dalej bez efektu. Dzięki za cierpliwość i próbę pomocy. To musi zacząć działać. Dzisiaj wyleciało mi z głowy, ale jutro przedzwonię do Wago.

[kempa007]

Dzwoniłem do Wago i naprowadzili mnie na pewien trop Powiedzieli żebym nie korzystał z konfiguratora a biblioteki modbusa, bo w sterowniku PFC 200 zmienił się sposób komunikowania po modbusie i dostepu do zmiennych specjalnych. Tutaj jest filmik (przewijam do sedna sprawy od 50 sekundy):

https://youtu.be/XZiqyO1s6YM?t=50

i wygląda na to, że to jest to co muszę wdrożyć. Nie jestem żadnym programistą więc przydałaby mi się pomoc w ogarnięciu tego. Ten przykład ma dodatkową zaletę tego, że po awarii zasilania wszystkie zmienne z modbusa utrzymują swój stan. Ogólnie nie wiem czy jest mi to jakoś szczególnie potrzebne, ale akurat wdrożenie tego nie wygląda na trudne.

Bardziej zastanawiają mnie te tablice coils, word itp. Czy ktoś może pomoc mi wskazać jak prawidłowo w ten sposób zaadresować dwie zmienne bitowe (coils adresowane przykładowo %MX0.0 i %MX0.1) i wykorzystać je w programie?




 

[kempa007]

Działa!!! Drugi kontakt z Wago rozwiązał problem. Dla wszystkich potomnych. W sterowniku Wago PFC 200, wyłączono bezpośrednie pisanie do zmiennych MX... A eCockpit ma własny serwer Modbus. Tak więc jak będziecie instalowali powyższą blibliotekę nie wystarczy usunąć tylko urządzenia generic modbus master/slave, ale trzeba wyłączyć w panelu WBM serwer Modbusa, ewentulanie serwer uruchamiany z poziomu programu odpalić na innym porcie! Masakra tydzień z tym walczyłem.

Wrzucam kod:

Kod: [Zaznacz]

VAR
    ModbusTcp: FbMbSimpleServerTcp    :=(  xOpen           := TRUE,
                                                wPort           := 502,

                                                utKeepAlive     := (xEnable      := TRUE, //  Switch keep-alive mechanism on
                                                                    tMaxIdleTime := T#5S, //  Maximum time of inactivity
                                                                    tInterval    := T#2S, //  Interval between two successive KA-Packets
                                                                    udiProbes    := 5     //  Number of KA retry before giving up
                                                                    ),

                                                bUnitId         := 1
                                              );

    //--- Data Areas ---------------------------------------------------------------------
    // You may use your own bounds for this arrays.
    // NOTE: The bounds are the addresses for modbus access too.
    //------------------------------------------------------------------------------------
    myDiscreteInputs    :   ARRAY[0..20] OF BOOL;       // Modbus bit address 0 .. 20
    myCoils                  :   ARRAY[0..20] OF BOOL;       // Modbus bit address 0 .. 20
    myInputRegisters    :   ARRAY[100..200] OF WORD;    // Modbus word address 100 .. 200
    myHoldingRegisters :   ARRAY[0..20] OF WORD;       // Modbus word address   0 .. 20
    //------------------------------------------------------------------------------------
xModbus : bool;
END_VAR

//--- Call the server ---------------------------------------------
mySimpleTcpServer(  axDiscreteInputs    := myDiscreteInputs,
                    axCoils             := myCoils,
                    awInputRegisters    := myInputRegisters,
                    awHoldingRegisters  := myHoldingRegisters
                );
//-----------------------------------------------------------------

xModbus:=myCoils[0];

I wszystko pięknie działa tak jak za pośrednictwem zmiennych MX. W moim przypadku myCoils[0] ma adres 0. Jedyny "problem" jest taki, że jeden bit pamięci zajmuje w sterowniku cały bajt, bo zmienne są trzymane w tablicy. Pewnie można by było to jakoś obchodzić, ale dla tych kilkudziesięciu nawet zmiennych chyba nie warto sobie tym głowy zawracać. No i bonusowo łatwo można wdrożyć "pamiętanie" stanu zmiennych po restarcie sterownika- nie wiem jeszcze czy mi się to przyda, czy nie, ale opcja jest.