1

ISO

9001

ISO

9001

C

E

R

T

Y

F

I

K

A

T

STEROWNIKPROGRAMOWALNYTypu SP1

INSTRUKCJA OBS£UGIPROTOKO£U LinkSP

2

SPIS TRE�CI

1. WSTÊP ............................................................................................................. 3

2. MODEL PROGRAMOWY ................................................................................. 32.1. Modu³y .............................................................................................................. 32.2. Rejestry ............................................................................................................. 32.3. Teksty ................................................................................................................ 52.4. Opisy pól ........................................................................................................... 52.5. Maski ................................................................................................................. 52.6. Adresowanie ..................................................................................................... 52.7. Zasoby wolnostoj¹ce ........................................................................................ 62.8. Komendy ........................................................................................................... 6

3. OPIS PROTOKO£U .......................................................................................... 63.1. Poziom liniowy .................................................................................................. 63.2. Telegram ........................................................................................................... 63.3. Zapytania .......................................................................................................... 73.4. Odpowiedzi ....................................................................................................... 73.5. Definicje elementarne ....................................................................................... 83.6. Zestawienie telegramów ................................................................................... 9

4. ZA£¥CZNIK - PRZYK£ADOWY ALGORYTM WYZNACZANIA SUMY KONTROLNEJ .......11

3

1. WSTÊP

Protokó³ komunikacyjny LinkSP jest jedynym protoko³em u¿ywanym przez program narzêdziowyCADSP. Protokó³ ten umo¿liwia dostêp do wszystkich zasobów sterownika, oraz jego zaprogra-mowanie, skonfigurowanie, a tak¿e aktualizacjê firmware�u. Protokó³ LinkSP równie dobrze mo¿ebyæ u¿ywany przez system nadzorczy.LinkSP jest prostym adresowanym protoko³em typu Master-Slave (nadrzêdny-podrzêdny). Ste-rownik realizuje rolê wêz³a typu Slave (podrzêdny). Oznacza to miêdzy innymi, ¿e:l sterownik ma swój adres,l sterownik nigdy nie wysy³a komunikatu z w³asnej inicjatywy,l sterownik ma obowi¹zek odpowiedzieæ na zaadresowany do niego komunikat w nieprzekra-

czalnym czasie zwanym time-outem.

2. MODEL PROGRAMOWY

Dostêpne komunikacyjnie zasoby sterownika s¹ zgrupowane w modu³ach.

2.1. Modu³y

Wszystkie modu³y mo¿na podzieliæ na dwie grupy:l reprezentuj¹ce funkcje steruj¹ce, dowolnie rozmieszczane i ³¹czone przez projektanta struk-

tury sterowania na arkuszach projektu,l le¿¹ce w �ci�le okre�lonych miejscach specjalnego arkusza numer 0 (zero).

Modu³y arkusza zerowego (zwane predefiniowanymi) reprezentuj¹ istotne zasoby sterownika,np. ABM (aktualne stany alarmów), BTS (liczniki czasów pracy), PRK (identyfikatory firmware�u isprzêtu), DAP (identyfikatory struktury sterowania) itd. Z komunikacyjnego punktu widzenia mo-du³y predefiniowane s¹ zawsze widoczne.Modu³y wyposa¿one s¹ w:l rejestry,l teksty,l opisy pól,l maski.

Liczba i znaczenie wymienionych wy¿ej zasobów zale¿y od typu modu³u. Numeracja poszcze-gólnych zasobów konkretnego typu zaczyna siê od 1 np. rejestr 17, tekst 3, itd. Numeracja niemusi byæ ci¹g³a; lista zasobów mo¿e zawieraæ przerwy. Tak wiêc para: typ zasobu i jego numerporz¹dkowy jednoznacznie okre�laj¹ zasób wewn¹trz modu³u np. rejestr 27 (je�li istnieje) jesttylko jeden, co nie wyklucza istnienia w tym samym module tekstu o numerze 27.

2.2. Rejestry

Rejestry s¹ czterobajtowymi jednostkami przechowuj¹cymi dane wewn¹trz sterownika. Pierw-szych 16 rejestrów ma ustalone znaczenie.

2.2.1. Rejestry 1...8 czyli wej�cia modu³u

Rejestry 1...8 reprezentuj¹ wej�cia modu³u. W postaci graficznej u¿ywanej przez program CADSPopisuj¹ sygna³y widoczne po lewej stronie modu³u, czyli wej�cia. Warto zauwa¿yæ, ¿e mog¹ onebyæ binarne lub rzeczywiste. Próba dostêpu do nieistniej¹cego wej�cia jest nielegalna. Wej�cianumerowane s¹ pozycyjnie, tzn. modu³, zgodnie ze swoj¹ reprezentacj¹ graficzn¹, mo¿e mieænp. wej�cia reprezentowane przez rejestry 1, 2 i 8.

4

Odczyt wej�æ jest zawsze mo¿liwy. Je�li wej�cie jest niepo³¹czone, to ma ustalon¹ warto�æ ini-cjaln¹. Zapis nowej warto�ci do takiego rejestru wymusza now¹ warto�æ wej�cia modu³u, como¿e mieæ ró¿ne konsekwencje dla struktury sterowania.Je�li wej�cie jest po³¹czone, to zapis nowej warto�ci jest mo¿liwy, ale nieefektywny w d³u¿szymczasie, poniewa¿ zostaje nadpisany przez zaktualizowan¹ bie¿¹c¹ warto�æ wynikaj¹c¹ z po³¹-czenia tu¿ przed przyst¹pieniem modu³u do obliczeñ. Tym nie mniej istnieje statystyczna mo¿li-wo�æ trafienia z zapisem tu¿ przed momentem obliczeñ, co wymusi jednorazowe przyjêcie nad-pisanej warto�ci jako argumentu. Mo¿e to byæ bardzo niebezpieczne i nie powinno byæ nigdyczynione. Nie ma metody wymuszania warto�ci po³¹czonych wej�æ modu³u.

2.2.2. Rejestry 9...16 czyli wyj�cia modu³u

Rejestry 9...16 reprezentuj¹ wyj�cia modu³u. W postaci graficznej u¿ywanej przez program CADSPopisuj¹ sygna³y widoczne po prawej stronie modu³u, czyli wyj�cia. Mog¹ one byæ binarne lubrzeczywiste. Próba dostêpu do nieistniej¹cego wyj�cia jest nielegalna. Wyj�cia tak jak i wej�cianumerowane s¹ pozycyjnie, tzn. modu³, zgodnie z reprezentacj¹ graficzn¹, mo¿e mieæ np. wyj-�cia reprezentowane przez rejestry 9,10 i 13.Odczyt wyj�æ jest zawsze mo¿liwy i dostarcza aktualnych warto�ci zmiennych wyj�ciowych mo-du³u. Zapis nowych warto�ci jest chwilowy, poniewa¿ zostan¹ one wkrótce nadpisane przez aktu-alne, wyznaczone algorytmem modu³u warto�ci, aczkolwiek w miêdzyczasie mog¹ one byæ u¿ytedo obliczeñ przez po³¹czone modu³y, co mo¿e spowodowaæ skutki trudne do przewidzenia. Niema metody wymuszania warto�ci wyj�æ modu³u.

2.2.3. Rejestry 17...255 czyli zmienne modu³u

Rejestry 17...255 reprezentuj¹ parametry i zmienne wewnêtrzne. Ich zbiór, formaty i znaczeniejest zale¿ne od typu modu³u. Ich odczyt jest zawsze mo¿liwy. Zwykle czê�æ z nich reprezentujeparametry algorytmu modu³u, a reszta zmienne algorytmu (nie wszystkie zmienne modu³u s¹widoczne!).Ustawianie, czyli zapis nowych warto�ci powinno byæ czynione rozwa¿nie, aby zapobiec uderze-niom na wyj�ciach modu³u. Inne ograniczenia opisano w nastêpnym punkcie.

2.2.4. Zapis i odczyt rejestrów

Jak podano powy¿ej odczyt rejestrów jest zawsze mo¿liwy. S³u¿y temu telegram Read Register.Zapisowi rejestrów s³u¿y telegram Write Register. Zapis mo¿e byæ uwarunkowany kontekstowo,co opisano w trzech wcze�niejszych punktach. Oprócz nich istniej¹ równie¿ inne istotne ograni-czenia.Niektórych rejestrów nie mo¿na aktualizowaæ w ogóle. Mo¿e to wynikaæ wprost ze znaczeniarejestru, (np. rejestr przechowuj¹cy numer wersji firmware�u, czy te¿ rejestr prezentuj¹cy aktual-ny stan alarmów sterownika) lub te¿ z w³a�ciwo�ci algorytmu wykorzystuj¹cego dany rejestr. Jestto ka¿dorazowo zaznaczone w opisie modu³u zawieraj¹cego rejestr (patrz �Katalog modu³ów�).Istniej¹ te¿ rejestry, których dopuszczalny zakres warto�ci jest ograniczony. W celu ochrony reje-stru przed nadaniem mu nielegalnej warto�ci istniej¹ dwie metody: zapis jest ignorowany (wrejestrze pozostaje stara warto�æ) np. przy próbie nadania parametrowi algorytmu, który jestdzielnikiem, warto�ci równej zero, lub te¿ rejestr przyjmuje skrajn¹ dozwolon¹ warto�æ najbli¿sz¹tej, któr¹ próbowano nadaæ.Istotne jest przy tym, ¿e w ten sposób chronione s¹ rejestry tylko przed nadaniem warto�ci nisz-cz¹cych (np. dzielnik=0) a nie warto�ci ma³o sensownych. Z jednej strony stwarza to potencjalneniebezpieczeñstwo niepoprawnego dzia³ania sterownika, z drugiej jednak strony pozostawia ocenieprojektanta systemu nadzorczego sensowno�æ warto�ci ustawianej zmiennej.

5

2.2.5. Formaty zmiennych

Je�li rejestr reprezentuje zmienn¹ numeryczn¹, to mo¿e on mieæ jeden z dwóch formatów:l LT - 4 bajtowy ca³kowity (long integer) stosowany przez wiêkszo�æ kompilatorów dla proceso-

rów MOTOROLI. Gdyby pierwszy bajt zamieniæ miejscem z czwartym, a drugi z trzecim, tootrzymuje siê postaæ u¿ywan¹ przez kompilatory jêzyka Pascal (Delphi) dla maszyn IBM PCdla liczb typu Longint..

l RNT - 4 bajtowy zmiennoprzecinkowy, stosowany jak wy¿ej. Gdy dokonaæ zamiany kolejno�cibajtów jak opisano wy¿ej otrzymuje siê zapis u¿ywany przez kompilatory jêzyka Pascal (Del-phi) dla maszyn IBM PC dla liczb typu Single.

Modu³y mog¹ przechowywaæ w rejestrach nie tylko zmienne numeryczne. Za ka¿dym razemwarto sprawdziæ w opisie modu³u jaki jest format zmiennej której warto�æ ma byæ modyfikowanakomunikacyjnie. Zapis warto�ci w nieodpowiednim formacie mo¿e spowodowaæ trudne do prze-widzenia skutki.

2.3. Teksty

Teksty s¹ u¿ywane g³ównie do przechowywania napisów (alarmów i ¿¹dañ obs³ugi). Odczyt tek-stów jest zawsze mo¿liwy. S³u¿y do tego telegram Read Text. Zapis tekstów jest mo¿liwy jedyniew fazie konfiguracji i s³u¿y temu telegram Write Text.Warto tu przypomnieæ, ¿e wiêkszo�æ tekstów u¿ywanych w sterowniku przechowywana jest ra-zem z przynale¿nymi im o�miobajtowymi paletami. Postaæ ka¿dego konkretnego tekstu mo¿nazweryfikowaæ w opisie modu³u.

2.4. Opisy pól

Parametry pól przechowuj¹ szczegó³owe dane o polach widocznych na ekranie LCD podczasdialogu. Ka¿dy modu³ dialogowy posiada opisy pól, które prezentuje siê na ekranie. Ich odczytjest zawsze mo¿liwy. S³u¿y temu telegram Read Field Description.Opisy pól s¹ wype³niane podczas konfiguracji sterownika i tylko w tym kontek�cie jest to mo¿liwe.S³u¿y temu telegram Write Field Description.

2.5. Maski

Maski (inaczej formatki, szablony) s³u¿¹ do przechowywania napisów sk³adaj¹cych siê na sta³¹zawarto�æ ekranu. Ka¿dy modu³ dialogowy zawiera definicje masek ekranów, które wy�wietla.Modu³ LOK przechowuje wszystkie maski dialogu wbudowanego.Do odczytu linii masek s³u¿y telegram Read Mask Line (linie masek odczytuje siê pojedynczo).Odczyt jest zawsze mo¿liwy.Do zapisu linii masek s³u¿y telegram Write Mask Line (zapis linii masek równie¿ dokonuje siê polinii). Zapis mo¿liwy jest jedynie podczas konfiguracji sterownika - realizowanej przez programCADSP.Warto przypomnieæ, ¿e maski, podobnie jak teksty, zwi¹zane s¹ z paletami. U³o¿enie masek i ichpalet w pamiêci ka¿dego z modu³ów dialogowych zawiera opis modu³u dialogowego.

2.6. Adresowanie

LinkSP umo¿liwia zapis i odczyt ka¿dego elementu zasobów. Poniewa¿ dostêpowi do zasobówkonkretnego typu s³u¿y dedykowany telegram wiêc jednoznacznym identyfikatorem zasobuw obrêbie modu³u jest jego numer porz¹dkowy. Na pe³ny adres zasobu w sterowniku musi zatem

6

sk³adaæ siê równie¿ jednoznaczny adres modu³u. Komunikaty s³u¿¹ce dostêpowaniu zasobów(Read & Write Register/ Text / Field / Mask) rzeczywi�cie zawieraj¹ taki adres utworzony z koor-dynat po³o¿enia modu³u.

2.7. Zasoby wolnostoj¹ce

Sterownik posiada dwa zasoby, które nie s¹ umieszczone w ¿adnym z modu³ów. S¹ to:l zegar z kalendarzem,l identyfikator urz¹dzenia i identyfikator wersji firmware�u.

Dostêpowi do tych zasobów s³u¿¹ specjalne, dedykowane telegramy:l Read/Write Clock & Calendarl Read Device IdentifierKomunikat Read Device Identifier jest uniwersalny dla wszystkich urz¹dzeñ rodziny SPx, coumo¿liwia ich ³atw¹ i jednoznaczn¹ identyfikacjê (patrz punkt �3.6. Zestawienie Telegramów�).

2.8. Komendy

Sterownik reaguje równie¿ na kilka bezargumentowych komend bezpo�rednich, u¿ywanych wy-³¹cznie do jego konfigurowania (np. Start Configuration).

3. OPIS PROTOKO£U

LinkSP jest asynchronicznym, adresowanym protoko³em typu Master-Slave. Komunikacja miê-dzy urz¹dzeniem nadrzêdnym (Master) i podrzêdnym (Slave) polega na wymianie telegramów.Aktywno�æ transmisyjna inicjowana jest przez stacjê typu Master poprzez wys³anie (zawsze)adresowanego telegramu do stacji typu Slave. Po nadaniu telegramu-zapytania Master ma obo-wi¹zek czekaæ na telegram-odpowied� przez 200 milisekund. W tym czasie nie mo¿e nadawaæczegokolwiek. Odbiorca ma obowi¹zek odpowiedzieæ na zapytanie telegramem o strukturze od-powiedniej do zapytania. Odpowiedzi nie s¹ adresowane. Slave nie mo¿e wysy³aæ odpowiedzi poprzeznaczonym do tego czasie.

3.1. Poziom liniowy

Liniowe parametry transmisji s¹ nastêpuj¹ce:l 8 bitów danych,l 1 bit stopu,l brak parzysto�ci,l prêdko�æ konfigurowalna - domy�lnie 19200 bitów na sekundê,l elektrycznego medium liniowego nie ustala siê przyjmuj¹c, ¿e nie ma przeszkód w wykorzy-

staniu standardów RS232, RS485, modemów itp.

3.2. Telegram

Przep³yw danych miêdzy nadawc¹ i odbiorc¹ odbywa siê za pomoc¹ telegramów. Telegram maustalon¹ strukturê:

Telegram otwiera bajt o ustalonej warto�ci=55[hex].

55[hex] LICZNIK DANE CRC

7

ADRES KOD PARAMETRY (opcjonalnie)

LICZNIK jest bajtem okre�laj¹cym d³ugo�æ nastêpuj¹cego po nim pola danych. Poniewa¿ poledanych wystêpuje zawsze, warto�æ pola licznik mo¿e zawieraæ siê w przedziale [1...255].

DANE nios¹ w³a�ciw¹ tre�æ informacyjn¹ telegramu. Struktura pola danych opisana jest dalej.CRC to dwubajtowa suma kontrolna wg normy CCITT dla wielomianu wyra¿onego formu³¹:

X16 + X12 + X5 + 1

Za³¹cznik zawiera przyk³adowy algorytm naliczania sumy kontrolnej wg powy¿szego wielomianu.

3.3. Zapytania

Zapytania wysy³ane s¹ jedynie przez stacjê typu Master. Pole danych telegramu-zapytania manastêpuj¹c¹ postaæ:

ADRES jest jednobajtowym adresem odbiorcy - stacji typu Slave.

KOD jest jednobajtowym kodem polecenia (komend¹).

PARAMETRY (opcjonalne) o zmiennej d³ugo�ci uszczegó³owiaj¹ komendê. Pe³na lista kodówkomend wraz z opisem parametrów podana jest dalej.

3.4. Odpowiedzi

Zapytana stacja typu Slave ma obowi¹zek odpowiedzieæ w nieprzekraczalnym terminie 200 mili-sekund. Stacja zapytana, to taka, która odebra³a telegram-pytanie zaadresowany do niej, o po-prawnej strukturze i sumie kontrolnej. Je�li którykolwiek z wymienionych wy¿ej warunków nie jestspe³niony to stacja milczy. Je�li stacja odpowiada, to czyni to telegramem o strukturze opisanejw punkcie �3.2. Telegram�.Zawarto�æ pola danych zale¿y od zapytania. W�ród nich mo¿na wyró¿niæ trzy odpowiedzi typo-we:l potwierdzenie przyjêcia komendy, która nie wymaga odes³ania danych,l odrzucenie telegramu,l odes³anie ¿¹danych danych.

3.4.1. Odpowied� typu ACK

Potwierdzenie przyjêcia komendy jest typow¹ odpowiedzi¹ na zapis danych, lub komendê bez-po�redni¹. Odsy³ane pole danych ma d³ugo�æ jednego bajtu i niesie kod 6 (ACK). Kompletnytelegram-odpowied� typu ACK wygl¹da nastêpuj¹co:

Warto zwróciæ uwagê, ¿e pole danych tego komunikatu ma d³ugo�æ równ¹ 1.

3.4.2. Odpowied� typu NAK

Komunikat odrzucenia zapytania lub komendy odsy³any jest w nastêpuj¹cych przypadkach:l niezrozumia³y kod zapytania,l niepoprawne parametry towarzysz¹ce kodowi komendy,

55[hex] 1 ACK (6hex) CRC

8

l niemo¿no�æ zrealizowania komendy (np. z powodów kontekstowych przyk³adem mo¿e byæpróba zapisu tekstu alarmu w kontek�cie innym ni¿ programowanie sterownika).

Innymi s³owy Master otrzymuj¹c odpowied� typu NAK przyjmuje, ¿e telegram zosta³ poprawnieodebrany przez zaadresowanego odbiorcê, natomiast polecenie w nim zawarte jest niezrozumia-³e lub nie mo¿e byæ zrealizowane. Kompletny telegram-odpowied� typu NAK wygl¹da nastêpuj¹-co:

D³ugo�æ pola danych tego telegramu podobnie jak telegramu typu ACK wynosi 1.

3.4.3. Odpowied� nios¹ca dane

Telegram nios¹cy dane ma typow¹ postaæ opisana w punkcie �3.2. Telegram�. Zawarto�æ poladanych zale¿y od zapytania. Szczegó³y opisane s¹ w kolejnych punktach.

3.5. Definicje elementarne

Poni¿sze definicje opisuj¹ elementarne czê�ci sk³adowe s³u¿¹ce opisowi tre�ci telegramu,(a �ci�lej jego pola danych).Na szczególn¹ uwagê zas³uguje <addressRTFM> , który jest adresem modu³u wewn¹trz sterow-nika i wystêpuje we wszystkich telegramach modyfikuj¹cych zasoby modu³ów.<ack> 0x06 bajt=6dec<nak> 0x15 bajt=21dec<r-count>:= <1-byte> liczba rejestrów {1...64}<chart>:= <1-byte> numer arkusza {0...50}<row>:= <4-bits> numer wiersza {1...12}<col>:= <4-bits> numer kolumny {1...15}<colbyte>:= <1-byte> numer kolumny {1...15}<item-addr>:= <1-byte> numer zasobu wewn¹trz modu³u {1...}<mod-pos>:= <chart><col><row> adres modu³u funkcjonalnego w sterowniku<addressRTFM>:= <mod-pos><item-addr> adres zasobu wewn¹trz sterownika<mod-type>:= <1-byte> typ modu³u funkcjonalnego<text-len>:= <1-byte> d³ugo�æ napisu<string>:= {<1-byte>}+ ci¹g znaków napisu<dev-label>:= <5-chars> tekstowy identyfikator urz¹dzenia: �SP-1�<firmware-ver>:= <3-chars> tekstowy numer wersji firmware�u; np.: �1.0�<dev-type>:= <1-byte> kod typu urz¹dzenia: 14: SP-1 z firmware�m. 15: bez<week-year>:= <1-byte><day-week>:= <1-byte><year>:= <1-byte><month>:= <1-byte><day>:= <1-byte><hour>:= <1-byte><minute>:= <1-byte><second>:= <1-byte><c&c-value>:= <week-year><day-week><year><month><day><hour><minute> <second>

55[hex] 1 NAK (15hex) CRC

9

<fType>:= <byte><fInitial>:= <4-bytes><fMin>:= <4-bytes><fMax>:= <4-bytes><fXpos>:= <byte>{1...40}<fYpos>:= <byte>{1...8}<fLen>:= <byte>{1...8}<fDec>:= <byte>if fDec>0 then fDec<=fLen-3<field_definition>:= <00><00<00><fType><fIni t ia l><fMin><fMax><fXpos><fYpos>

<fLen><fDec>

3.6. Zestawienie telegramów

Poni¿ej zestawiono zawarto�æ pola danych telegramu zapytania (q) oraz zawarto�æ pola danychoczekiwanego telegramu odpowiedzi (a).Kody komend w pierwszej kolumnie podano dziesiêtnie. Kody komend wewn¹trz pola danychpodano w notacji szesnastkowej.

Read Clock & Calendar �RCC�04 q ::= 0x04

a ::= <c&c-value>

Write Clock &Calendar �WCC�12 q ::= 0x0C <c&c-value>

a ::= <ack>|<nak>

Read Device Identifier �RDI�32 q ::= 0x20

a ::= <device-label> <firmware-ver> <dev-type>

Run �RUN�40 q ::= 0x28

a ::= <ack>|<nak>

Stop �STP�60 q ::= 0x3C

a ::= <ack>|<nak>

Read Register �RR�06 q ::= 0x06 <r-count> <addressRTFM>

a ::= <nak>|{<4-bytes>}+

Write Register �WR�14 q ::= 0x0E <r-count> <addressRTFM> {<4-bytes>}+

a ::= <ack>|<nak>

10

Write Configuration �WC�130 q ::= 0x82 <mod-pos> <mod-type> 8*< addressRTFM >

a ::= <ack>|<nak>

Read Configuration �RC�131 q ::= 0x83 <mod-pos>

a ::= <nak>|<mod-type> 8*< addressRTFM >

Read Text �RT�143 q ::= 0x8F < addressRTFM >

a ::= <nak>|<text-len> <string>

Write Text �WT�153 q ::= 0x99<addressRTFM> <text-len> <string>

a ::= <ack>|<nak>

Start Configuration �CST�160 q ::= 0xA0 <devtype>

a ::= <ack>|<nak>

End Configuration �CEN�161 q ::= 0xA1

a ::= <ack>|<nak>

Abort configuration �CAB�162 q ::= 0xA2

a ::= <ack>|<nak>

Write Field Description �WFD�184 q ::=0xB8<addressRTFM><field_description>

a ::= <ack>|<nak>

Read Field Description �RFD�185 q ::=0xB9<addressRTFM>

a ::=<nak>|<field_description>

Read Column Idx �RCI�186 q ::=0xBA<chart><colbyte>

a ::=<nak>|12*<colbyte>

Read Mask Line �RML�188 q ::= 0xBC<addressRTFM>

a ::= <nak>|<text-len> <string>

Write Mask Line �WML�189 q ::= 0xBD<addressRTFM> <text-len> <string>

a ::= <ack>|<nak>

11

4. ZA£¥CZNIK - PRZYK£ADOWY ALGORYTM WYZNACZANIA SUMYKONTROLNEJ

varcrc_table: array[0..255] of word; { tablica pomocnicza w wyznaczaniu CRC }procedure crc_init;{Inicjalizacja tablicy pomocniczej powinna byæ wykonana raz, na pocz¹tku pracy programu.}vari, crc : word;j : byte;Begin for i:=0 to 255 do begin crc:=i Shl 8; for j:=0 to 7 do begin if (crc And $8000)<>0 then crc:= (crc Shl 1) Xor $1021 else crc:= crc Shl 1; end; crc_table[i]:=crc; end;End;function crc_calc(crc:word; var data; len:word): word;{Wyznacza CRC-CCITT dla wielomianu: X^16 + X^12 + X^5 + 1przy u¿yciu tablicy pomocniczej, która musi byæ zainicjowana funkcj¹ crc_init() ZANIM u¿yje siêcrc_calc().Crc: dotychczas wyznaczone CRC,data: wska�nik do bufora z danymi,len: ilo�æ danych.}var i: byte;Begin i:=0; while len<>0 do begin crc:= crc_table[(crc Shr 8) Xor Word(String(data)[i])] Xor (crc Shl 8); Dec(len); Inc(i); end; crc_calc:=crc;End;

Produkujemy ponad 200 typów wyrobów w nastêpuj¹cychgrupach asortymentowych:

r MIERNIKI TABLICOWE ANALOGOWE

r MIERNIKI TABLICOWE CYFROWE

r MIERNIKI PRZENO�NE, ANALOGOWE I CYFROWE

r REJESTRATORY KOMPENSACYJNE, PROGRAMOWALNE I PNEUMATYCZNE

r REGULATORY ELEKTRONICZNE DO PROCESÓW PRZEMYS£OWYCH

r REGULATORY ELEKTRONICZNE DO URZ¥DZEÑ CH£ODNICZYCH

r REGULATORY DO URZ¥DZEÑ GRZEWCZYCH

r PRZETWORNIKI POMIAROWE

r SYSTEMY MIKROPROCESOROWE DLA PROCESÓW PRZEMYS£OWYCH

r PRZEMIENNIKI CZÊSTOTLIWO�CI

r STEROWNIKI MOCY I PRZEKA�NIKI PÓ£PRZEWODNIKOWE

r OBROTOMIERZE, ZEGARY I WSKA�NIKI DLA MOTORYZACJI

r PRZYBORY POMIAROWE ZAMIENNE (BOCZNIKI, OPORNIKI, CZUJNIKI)

Oferujemy równie¿ us³ugi w zakresie produkcji:

r ODLEWÓW CI�NIENIOWYCH ZE STOPÓW ALUMINIUM I CYNKU

r FORM ODLEWNICZYCH I CI�NIENIOWYCH

r CZ�CI MECHANIKI PRECYZYJNEJ

Procedury jako�ciowe

Zgodne z miêdzynarodowym systemem jako�ci ISO-9001Na ¿yczenie, wysy³amy szczegó³owe katalogi na powy¿sze rodziny wyrobów

Lubuskie Zak³ady Aparatów Elektrycznych LUMEL S.A.ul. Sulechowska 1, 65-950 Zielona Góratel. (0-68) 329 51 00fax (0-68) 329 51 01e-mail: lumel@lumel.com.plhttp://www.lumel.com.pl

Dzia³ Sprzeda¿y: tel. (0-68) 327 06 41,fax (0-68) 325 56 50e-mail: sprzedaz@lumel.com.pl

Dzia³ Marketingu: tel. (0-68) 329 53 07

Sklep Firmowy: tel. (0-68) 329 53 30

P

raco

wni

a W

ydaw

nict

w L

UM

EL

S.A

., w

rzes

ieñ

2001