Uruchamianie programu sender:
/opt/szarp/bin/sender --help Usage: sender [OPTION...] SZARP sender application daemon. --D<param>=val Set initial value of libpar variable <param> to val. -n, --no-daemon Do not fork and go into background, useful for debug. -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Config file szarp.cfg: These parameters are read from section 'sender' and are optional: log path to log file, default is /opt/szarp/log/sender.log log_level log level, from 0 to 10, default is from command line (-Ddebug=needed_log_level parameter) or 2. Report bugs to coders@praterm.com.pl.
W aktualnej wersji, aplikacja sender może pracować w trybie "debug" lub w trybie normalnym (bez debugowania). Uruchomienie w trybie "debug" może nastąpić w kilku przypadkach:
/opt/szarp/bin/sender
Przykładowa zawartość sekcji sender pliku szarp.cfg: :sender log_level=3 log=/opt/szarp/logs/senderek.logJeżeli uruchomiamy program bez podania żadnych parametrów w linii argumentów, ale w pliku konfiguracyjnym szarp.cfg w sekcji sender został zdefiniowany parametr log_level o wartości większej od 0, lub parametr log_level nie został zdefiniowany, przez co aplikacja sender przyjmuje jego domyślną wartość na 2. Dodatkowo, w pliku szarp.cfg w sekcji sender, można zdefiniować parametr log, który opisuje ścieżkę do pliku, do którego zapisywane będą wszystkie informacje diagnostyczne generowane przez program sender. Tak uruchomiona aplikacja będzie działać w tle (uruchomiona zostanie jako demon).
/opt/szarp/bin/sender -nPodobnie jak w poprzednim przypadku, wszelkie informacje o sposobie zapisywania informacji diagnostycznych zostaną pobrane z pliku szarp.cfg lub zostaną przyjęte wartości domyślne. Aplikacja uruchomiona z paramtrem -n (lub --no-deamon) nie będzie działać w tle.
/opt/szarp/bin/sender -n -Ddebug=5Jeżeli w pliku szarp.cfg nie ma informacji o wartości parametru log_level, wówczas możemy ją zdefiniować z linii argumentów z wykorzystaniem parametru debug i w ten sposób określić poziom diagnostyki.
Po uruchomieniu aplikacji sender w trybie diagnostycznym, ważna jest obserwacja w dwóch miejscach:
po uruchomieniu wszystkie paramtery typu send zostaną odczytane przez aplikację i zapisane do pliku konfiguracyjnego, przez co będzie możliwa kontrola ich poprawności np.:
NumberOfPars=20 BasePeriod=10 Par 000 src= 12 dst= 48, 4 retry=1 rtype=13107200 Probe skipped Par 001 src= 15 dst= 305, 5 retry=1 rtype=13107201 Minute skipped Par 002 src= 123 dst= 3890, 4 retry=1 rtype=13107202 Min10 SENT Par 003 src= 112 dst= 4146, 1 retry=1 rtype=13107203 Hour SENT Par 004 src= 112 dst= 4146, 2 retry=1 rtype=13107204 Hour SENT Par 005 src= 112 dst= 4146, 3 retry=1 rtype=13107205 Hour SENT Par 006 src= 112 dst= 4146, 4 retry=1 rtype=13107206 Hour SENT Par 007 src= 112 dst= 4146, 5 retry=1 rtype=13107207 Hour skipped Par 008 src= 112 dst= 4146, 6 retry=1 rtype=13107208 Hour skipped Par 009 src= 112 dst= 4146, 7 retry=1 rtype=13107209 Hour skipped Par 010 src= 112 dst= 4146, 8 retry=1 rtype=13107210 Hour skipped Par 011 src= 112 dst= 4146, 9 retry=1 rtype=13107211 Hour SENT Par 012 src= 112 dst= 4146, 0 retry=1 rtype=13107212 Hour SENT Par 013 src= 21 dst= 5681, 1 retry=1 rtype=13107213 Day SENT Par 014 src= 22 dst= 5681, 2 retry=1 rtype=13107214 Min10 skipped Par 015 src= 0 dst= 562, 0 retry=1 rtype=13107215 Const SENT Par 016 src= 0 dst= 562, 1 retry=1 rtype=13107216 Const SENT Par 017 src= 0 dst= 562, 2 retry=1 rtype=13107217 Const SENT Par 018 src= 0 dst= 562, 3 retry=1 rtype=13107218 Const SENT Par 019 src= 0 dst= 562, 4 retry=1 rtype=13107219 Const SENT
Gdzie: Par - numer kolejny pozycji na liście, od 0
src - adres w pamięci dzielonej lub 0, jeżeli wysyłana jest stała
dst - (numer linii - 1) * 256 + numer jednostki jako znak (np. '0')
, numer parametru wejściowego jednostki
retry - liczba powtórzeń
rtype - nieważne (jest to identyfikator nadawcy)
Probe, Minute ... Const - typ pamięci dzielonej lub stała
SENT, skipped - postępowanie w wypadku, gdy nastąpi brak danych (SZARP_NO_DATA) (wysyłać, nie wysyłać)
oraz podczas wysyłania komunikatu, co pozwoli nam zorientować się czy konfiguracja jest poprawna np.:
Message 00048 with param: 4 value: -32768 rtype: 13107200 bad value, skipped Message 00305 with param: 5 value: 0 rtype: 13107201 rejected Message 04146 with param: 1 value: -32768 rtype: 13107203 not confirmed Message 04146 with param: 5 value: -32768 rtype: 13107207 bad value, skipped Message 04146 with param: 8 value: -32768 rtype: 13107210 bad value, skipped Message 04146 with param: 9 value: -32768 rtype: 13107211 not confirmed Message 04146 with param: 0 value: -32768 rtype: 13107212 rejected Message 05681 with param: 1 value: 0 rtype: 13107213 not confirmed Message 05681 with param: 2 value: 0 rtype: 13107214 not confirmed Message 00562 with param: 0 value: -32768 rtype: 13107215 rejected Message 00562 with param: 4 value: 9999 rtype: 13107219 status OK
Message, param - to co dst powyżej
value - pobrana wartość
rtype - jak wyżej
Najważniejszy jest komunikat na końcu:
bad value, skipped - value jest równa SZARP_NO_DATA i nie należy wysyłać (ewentualnie adres w pamięci jest równy NO_PARAM), nic nie zostało wysłane do demona.
- not confirmed - demon nie potwierdził odbioru komunikatu.
- rejected - komunikat doszedł do demona, ale sterownik nie odpowiedział.
- status OK - sterownik odpowiedział raportem na polecenie wysłania parametrów.
Poprzedni | Spis treści | Następny |
Program sender | Początek rozdziału | Algorytm działania programu sender |