Protokół wymiany komunikatów w systemie pomiarowym

Prezentacja na temat: "Protokół wymiany komunikatów w systemie pomiarowym"— Zapis prezentacji:

1 Protokół wymiany komunikatów w systemie pomiarowym
Ustalenia IEEE488.2

2 Model funkcjonowania urządzenia:
Rysunek przedstawia schemat funkcjonalny urządzenia widziany z perspektywy obsługi komunikatów zdalnych. Urządzenie przyjmuje komunikaty programujące, których celem jest odpowiednie ustawienie pewnej funkcji urządzeniowej (np. FREQ 123.4) lub dostarczenie przez nią informacji zwrotnej (np. FREQ? ) w postaci komunikatu odpowiedzi. Komunikat odebrany jest poddawany w urządzeniu pewnym procesom przetwarzania. Rodzaj oraz kolejność tych operacji jest określana przez układ sterowania obsługą komunikatów.

3 Model urządzenia; odbieranie komunikatu:
Kontroler systemu wysyła bajty komunikatu. Układ interfejsu urządzenia odbiera je i wstawia do bufora wejściowego. Cechy funkcjonalne układu interfejsowego są określone przez rodzaj zaimplementowanego interfejsu. W przypadku IEEE488 blok obsługuje adresowanie, żądanie obsługi, wydawanie STB, odpowiedzi równoległej,odbiór lub wysłanie bajtu itd. Pojemność bufora może być stała lub modyfikowana. Typowo powinna zapewnić zbuforowanie pojedynczego polecenia. W sytuacji zapełnieniu bufora, układ sterowania musi wstrzymać odbiór bajtów przez interfejs i rozpocząć interpretację odebranych danych. Przepełnienie bufora nie powinno powodować sygnalizacji błędów. Bufor wejściowy gromadzi strumień bajtów bez jakiejkolwiek kontroli ich znaczenia.

4 Model urządzenia; analizator składni (parser):
Operacje parsera: Pobiera zawartość bufora wejściowego (gdy wystąpi znacznik końca komunikatu lub zapełni się bufor wejściowy) ; Rozbiera ciąg bajtów na elementarne komunikaty. Wykonuje analizę składniową. Określa ważność i poprawność syntaktyczną komunikatów i ich elementów składowych. Naruszenie poprawności syntaktycznej spowoduje wygenerowanie błędu Command Error, który jest raportowany przez system statusowy urządzenia. Poprawne syntaktycznie komunikaty (nagłówki i argumenty) są kodowane w sposób specyficzny dla danego urządzenia i przekazywane do bloku sterowania ich wykonaniem.

5 Działanie analizatora składni :
Przykład działania firmowego analizatora składni poleceń SCPI. JPA-SCPI Parser Polecenie poprawne; wynik: Numer polecenia – #34 ; Typ argumentu – numeryczny; Cecha typu – całkowity dodatni (+ve int); Wartość – 12500; Rodzaj jednostki – typ 9 (Hz). Polecenie błędne: Brak spacji pomiędzy nagłówkiem i argumentem.

6 Model urządzenia; sterowanie wykonaniem poleceń:
Blok sterowania wykonaniem poleceń dysponuje kolejką poleceń do wykonania uporządkowaną w kolejności ich otrzymania z kontrolera systemu. Zadania bloku: Sprawdzenie uwarunkowań wykonania polecenia, np. zakresu wartości argumentów. Jeśli są one naruszone blok zgłasza błąd Execution Error. Inicjowanie wykonania polecenia przez blok funkcji przyrządowych (Instrument Functions). ; Inicjowanie wykonuje się w kolejności poleceń znajdujących się w kolejce do wykonania. Blok może zmienić kolejność wykonania poleceń dotyczących programowania zasobów sprzężonych. Inicjowanie następnego polecenia następuje po wykonaniu poprzedniego (polecenie sekwencyjne). Polecenia nakładkowe są wykonywane współbieżnie. Zainicjowanie wykonania następnego realizuje się niezależnie od stanu wykonania poprzedniego.

7 Model urządzenia; wykonanie polecenia:
Blok funkcji urządzeniowych: Wykonuje przekazane do niego polecenia. Funkcja urządzeniowa może zgłosić błąd działania (Device Specific Error) związany z wykonywanym poleceniem a polegającym na niemożliwości jego wykonania w całkowicie poprawny sposób. Typowym przykładem tego błędu jest błąd przekroczenia podzakresu (Overrange) podczas wykonywania pomiaru. Jeśli polecenie jest zapytaniem, blok przekazuje stosowną odpowiedź do bloku formatowania odpowiedzi. Zwykle odpowiedź jest w wewnętrznym kodzie, specyficznym dla urządzenia. Odpowiedzi są generowane zawsze w kolejności otrzymanych zapytań.

8 Model urządzenia; formatowanie odpowiedzi:
Blok formatowania: Blok konwertuje wewnętrzną reprezentację odpowiedzi do komunikatu odpowiedzi w postaci zgodnej z przyjętym formatem odpowiedzi. Komunikat odpowiedzi może mieć postać tekstową lub binarną. Tekstowa może być z nagłówkiem lub bez. Format odpowiedzi jest ustalony lub wybierany za pomocą odpowiednich poleceń programujących.

9 Model urządzenia; wysłanie odpowiedzi:
Komunikat odpowiedzi wypracowany przez formater jest wstawiany do kolejki wyjściowej odpowiedzi urządzenia. Kolejność odpowiedzi odpowiada kolejności zapytań. Blok interfejsu pobiera komunikaty z kolejki wyjściowej i wysyła przez interfejs do kontrolera systemu. Np. interfejs IEEE488 wyśle komunikat odpowiedzi, gdy zostanie zaadresowany do nadawania.

10 Komunikacja kontroler - urządzenie:
Komunikacja pomiędzy kontrolerem i urządzeniem systemu opiera się na wymianie komunikatów poleceń i komunikatów odpowiedzi (Program and Response Messages). Komunikaty poleceń dzielą się na polecenia nastawcze i zapytania. Wzajemne współdziałanie urządzeń to wymiana komunikatów (zdań – poleceń i odpowiedzi). Wymiana zdań nie może być chaotyczna. Musi podlegać pewnym regułom – protokół komunikacyjny. W systemie kontroler jest urządzeniem nadrzędnym – jest też moderatorem wymiany zdań.

11 Cel określenia protokołu:
Celem protokołu jest zapewnienie niezawodnej wymiany komunikatów pomiędzy kontrolerem i urządzeniem (zapewnia skuteczne działanie systemu). Dobrze zdefiniowane zasady gwarantują, że urządzenie wyjdzie z każdej błędnej sytuacji lub niedotrzymania zaleceń protokołu i rozpocznie normalne, poprawne działanie dla kolejnej sekwencji poleceń. Jednocześnie system statusowy urządzenia dostarczy informacje opisujące zaistniałą sytuację. Protokół zdefiniowany w IEEE488.2 określa między innymi: Zasady odbioru złożonych poleceń; Reakcji urządzenia na niekompletne polecenie; Reakcji urządzenia na przerwanie przetwarzania komunikatu nowym komunikatem. Warunki wysłania komunikatu odpowiedzi.

12 Zasady podstawowe komunikacji kontroler - urządzenie:
Polecenia są generalnie wykonywane w kolejności ich odebrania. Istnieją jednak pewne okoliczności, w których ta zasada nie jest zachowana. Urządzenie dostarcza danych tylko w odpowiedzi na zadane wcześniej zapytanie. Odpowiedzi urządzenia są wysłane do kontrolera w kolejności odebranych zapytań.

13 Reguły rządzące komunikacją kontroler - urządzenie:
Reguła 1: Kontroler nie uzyska odpowiedzi z urządzenia dotąd dopóki nie prześle całego komunikatu zakończonego terminatorem. Oznacza to, że przejście kontrolera do odbioru może mieć miejsce dopiero po wysłaniu terminatora polecenia zawierającego zapytanie. Reguła 2: Kontroler nie może wysłać do urządzenia komunikatu programującego, zapytania lub rozkazu GET dopóki nie odczyta w całości odpowiedzi na wcześniej wysłane zapytanie. Oznacza to, że kontroler może wysłać polecenie do danego urządzenia, gdy urządzenie to wyśle cały komunikat odpowiedzi łącznie z terminatorem.

14 Reguły rządzące komunikacją kontroler - urządzenie:
Reguła 3: Kontroler nie może podjąć próby odczytania odpowiedzi z przyrządu, jeśli jawnie zapytaniem jej nie zażądał. Czytanie odpowiedzi musi poprzedzać zapytanie skierowane do urządzenia. Reguła 4: Odpowiedź o nieokreślonej długości (tekstowa lub binarna) musi kończyć się terminatorem odpowiedzi, aby uniknąć niejednoznaczności jej interpretacji. Kontroler może wysłać złożone zapytanie do przyrządu. Jednym z nich może być pytanie dające odpowiedź w postaci bloku danych o nieokreślonej długości. W tej sytuacji programista musi zapewnić, aby takie zapytanie było ostatnim z zapytań. Przykładem takiego zapytania jest *IDN? . Odpowiedzią jest dana identyfikacyjna mająca postać bloku ASCII o nieokreślonej długości.

15 Reguły rządzące komunikacją kontroler - urządzenie:
Reguła 5: Rozsądną zasadą jest ograniczanie liczby poleceń w poleceniach złożonych, aby nie doprowadzić do zablokowania układu obsługi poleceń w urządzeniu. Blokada nie wystąpi, jeśli długość komunikatu jest mniejsza od pojemności bufora wejściowego. Blokowanie nie dotyczy złożonych poleceń programujących, nawet w sytuacji gdy urządzenie dysponuje buforem o małej pojemności. Jeśli się zapełni, nastąpi wstrzymanie transmisji aż urządzenie wykona część dostarczonych poleceń i zwolni bufor wejściowy dla pozostałej części polecenia. Blokowanie może wystąpić , jeśli stosuje się polecenia złożone z zapytaniami. Szczególnie, gdy ich wynikiem są obszerne zbiory danych. Zapełnienie kolejki wyjściowej, gdy część komunikatu nie została jeszcze odebrana powoduje impas działania układu przetwarzania komunikatów.

16 Impas komunikacyjny: Długi,złożony komunikat programujący z zapytaniami. Bufor wejściowy pełny. Odbiór wstrzymany. Część komunikatu czeka na odbiór. Odpowiedzi zapełniły kolejkę wyjściową. Formater zablokowany. Funkcje urządzeniowe zablokowane. Polecenia są wykonywane sekwencyjnie, zatem układ sterowania wykonaniem też zablokowany. Analizator składni zablokowany. Kompletny IMPAS; zamrożenie komunikacji. Kontroler może przerwać nadawanie komunikatu, ale nie może przejść do odbioru , ponieważ komunikat nie został zakończony terminatorem! Jeśli to zrobi, urządzenie zgłosi błąd a dane zostaną stracone.

17 Diagram stanów układu obsługi poleceń :
Stany układu: IDLE – Czeka na polecenie; READ – Układ interfejsowy odczytuje bajty, analizator składni i układ sterowania wykonaniem poleceń są aktywne; QUERY – Parser wykrył zapytanie; Układ interfejsowy odczytuje bajty, analizator składni , układ sterowania wykonaniem poleceń oraz formater odpowiedzi są aktywne; SEND - Układ interfejsowy wysyła bajty odpowiedzi, ale w buforze wejściowym są jeszcze polecenia; analizator składni , układ sterowania wykonaniem poleceń oraz formater odpowiedzi są aktywne; RESPONSE - Układ interfejsowy wysyła bajty odpowiedzi; analizator składni , układ sterowania wykonaniem poleceń zakończyły działanie (wszystkie polecenia przeanalizowane i przekazane do wykonania). Formater odpowiedzi jest jeszcze aktywny; DONE – Odpowiedź wysłana łącznie z terminatorem. Oczekiwanie na następne polecenie. DEADLOCK - Układ interfejsowy odczytuje bajty, analizator składni i układ sterowania wykonaniem poleceń są aktywne; zapytania są odrzucane.

18 Obsługa poleceń prostych:
OUTP:LOAD 50<NL> OUTP:LOAD?<NL>

19 Obsługa polecenia złożonego :

20 Polecenie złożone realizowane w kilku transakcjach:
HP VEE : Terminator polecenia ON/OFF

21 Polecenie złożone realizowane w kilku transakcjach:
LabView:

22 Błędy obsługi zapytań (Query error - unterminated) :
Polecenie bez terminatora -> próba czytania z urządzenia. Zdarzenie ‘nie zakończone polecenie’ (UNTERMINATED) wystąpi w urządzeniu, gdy kontroler próbuje odczytać dane z urządzenia : Bez wcześniejszego zapytania; Po wysłaniu polecenia nie zawierającego zapytania i nie zakończonego terminatorem; Po wysłaniu polecenia z zapytaniem ale nie zakończonego terminatorem ; Zdarzenia te kończą się przerwaniem obsługi polecenia i zgłoszeniem błędu Query Error. Kolejka wyjściowa odpowiedzi jest zerowana. Układ wraca do stanu spoczynkowego IDLE i jest gotowy do działania.

23 Błędy obsługi zapytań (Query error - interrupted) :
Polecenie z pytaniami -> Następne polecenie Zdarzenie ‘przerwanie zapytania’ (INTERRUPTED) wystąpi w urządzeniu, gdy kontroler po wysłaniu zapytania wysyła następny komunikat nie odczytując wcześniej całej odpowiedzi. Sytuacje krytyczne: Po zapytaniu zakończonym terminatorem kontroler wysyła kolejne polecenie, np. MEAS?<NL> i po nim VOLT:RANG 1<NL>; Po wysłaniu złożonego polecenia z zapytaniami zakończonego terminatorem kontroler odbiera część odpowiedzi i przechodzi do wysłania kolejnego polecenia, np. ....;MEAS?;......<NL> , odczyt części odpowiedzi i wysłanie polecenia VOLT:RANG 1<NL>; Po wysłaniu zapytania zakończonego terminatorem kontroler odbiera część odpowiedzi i przechodzi do wysłania kolejnego polecenia, np. MEAS?<NL> , odczyt części odpowiedzi i wysłanie polecenia VOLT:RANG 1<NL>; Zdarzenia te kończą się zgłoszeniem błędu Query Error. Kolejka wyjściowa odpowiedzi jest zerowana. Polecenie, które spowodowało błąd jest realizowane.

24 Błędy obsługi zapytań (Query error - deadlock) :
Zdarzenie ‘impas’ (DEADLOCK) może wystąpić w urządzeniu, które dostanie złożony komunikat z wieloma zapytaniami a odpowiedzi są obszernymi zbiorami danych. Urządzenie może być niezdolne do kompletnego wykonania polecenia, ponieważ: Bufor wejściowy oraz kolejka wyjściowa są pełne; Działanie parsera, bloku sterowania wykonaniem poleceń oraz formatera jest zablokowane; Odbiór kolejnych bajtów polecenia jest zatrzymany z powodu przepełnienia bufora wejściowego; Urządzenie nie może wysłać opracowanych odpowiedzi, gdyż transfer polecenia jeszcze się nie zakończył. Kontroler nie może przejść do odbioru dopóki nie wyśle terminatora polecenia. Kanał komunikacyjny jest zablokowany. Układ sterowania obsługą poleceń w urządzeniu wchodzi wtedy w stan DEADLOCK. W stanie impasu układ sterowania obsługi komunikatu: Zeruje kolejkę wyjściową; opracowane odpowiedzi są stracone; Ustawia błąd Query Error; Zeruje formater odpowiedzi; Realizuje pozostałe polecenia odrzucając zapytania (realizuje tylko nastawy). Po przetworzeniu terminatora polecenia (eom) układ wraca do stanu spoczynkowego (IDLE) i jest gotowy do przyjęcia kolejnych poleceń.

25 Zasoby funkcjonalne z parametrami sprzężonymi:
Przykład – parametry próbkowania sygnału: Odstęp czasowy próbkowania dT = 5us Czas próbkowania Tp = 2.5ms Liczba punktów próbkowania Ns = 501 Relacja wiążąca parametry Tp = dT * ( Ns – 1 ) Należy ustawić Tp=10ms i dT=1us: SENSe:SWEep:TIME 0.01<NL> rezultat : Tp=10ms, Ns=501, dT=20us i drugie polecenie SENSe:SWEep:TINTerval 1.0E-6<NL> rezultat : dT=1us, Ns=501, Tp=0.5ms Żądany rezultat nie został uzyskany, chociaż każde z poleceń jest poprawne!

26 Parametry sprzężone: Jeśli polecenie modyfikuje jeden parametr, urządzenie zmodyfikuje jeden lub więcej parametrów należących do grupy wzajemnie powiązanych parametrów. Wybór, który z parametrów zostanie zmodyfikowany jest arbitralnie określony przez konstrukcję urządzenia. Np. przyjęty algorytm modyfikacji może opisywać następujący diagram : SENSe:SWEep:TIME 0.01<NL> rezultat : Tp=10ms, Ns=501, dT=20us i drugie polecenie SENSe:SWEep:TINTerval 1.0E-6<NL> rezultat : dT=1us, Ns=501, Tp=0.5ms

27 Parametry sprzężone: Przedstawiony przykład sugeruje, że przyrząd powinien pozostawić Tp a zmodyfikować Ns. Aby to uzyskać należałoby przyjąć inną kolejność programowania. Ustawić Ns a potem dT. Parametr Tp zostanie wtedy ustawiony przez urządzenie. Takie postępowanie wymaga od programisty precyzyjnej znajomości zasad modyfikacji parametrów sprzężonych. Jeśli nie są one znane, to wynik programowania jest nieprzewidywalny. Przyjęto zasadę, że parametry takie należy podać w jednym złożonym poleceniu: Urządzenie po odebraniu polecenia dotyczącego parametrów sprzężonych, odkłada je i realizuje następne polecenie. Poleceniami z parametrami sprzężonymi zajmuje się po odebraniu terminatora polecenia. Jeśli odłożone polecenia dotyczą jednego zestawu danych sprzężonych, urządzenie wylicza pozostałe dane sprzężone tak, aby spełnić zależność wiążącą i ustawić parametry zgodnie z poleceniem programującym. SENSe:SWEep:TIME 0.01; TINTerval 1.0E-6<NL> Polecenie zmodyfikuje Ns do i ustawi Tp=10ms oraz dT=1us. Wynik końcowy jest teraz niezależny od kolejności poleceń, wcześniejszego ustawienia przyrządu oraz diagramu sprzężenia parametrów. Uwaga: Urządzenie zmienia kolejność wykonania poleceń; nie wykonuje ich w kolejności otrzymania.

28 Wyzwolenie urządzenia - rozkaz GET :
Rozkaz GET (rozkaz interfejsu IEEE488) pozwala jednocześnie wyzwolić działanie wybranych urządzeń. GET nie jest wysyłany jako zwyczajny bajt danych lecz jako rozkaz interfejsowy (ATN=1; drugi kanał komunikacyjny ). Kontroler może go zawsze wysłać, np. przerywając na chwilę transfer danych do urządzenia. Układ scalony GPIB bloku interfejsowego urządzenia dekoduje go w każdych warunkach tworząc wewnętrzny komunikat lub impuls wyzwolenia ‘get’. Urządzenie wykonuje otrzymane komunikaty w kolejności ich otrzymania. Ta zasada dotyczy zwyczajnych poleceń oraz rozkazu GET. SENSe:SWEep:TI [ ATN=1 <GET> ATN=0 ] ME 0.01; TINTerval 1.0E-6<NL> - wystąpi błąd: Command Error! Przyjęto zasadę, że GET może być wysłany tylko po komunikacie zakończonym terminatorem. W przeciwnym razie urządzenie zgłosi błąd polecenia (Command Error). GET wystąpił po terminatorze polecenia, ale urządzenie jeszcze je realizuje. Wykonanie rozkazu GET zostanie odłożone w czasie do momentu wykonania wszystkich poprzedzających poleceń. Czyli, gdy w chwili odebrania GET w buforze wejściowym były polecenia lub zainicjowane polecenie nie zostało jeszcze wykonane, rozkaz wyzwolenia jest wstawiany na koniec kolejki oczekujących poleceń – odroczenie wykonania.

29 Błędy protokołu – błąd polecenia (Command Error) :
Błąd polecenia – Command Error – jest zgłaszany przez analizator składni odebranych poleceń, gdy: Jest niepoprawne składniowo; Jest syntaktycznie poprawne, ale nie obowiązuje dla urządzenia; Jeden z parametrów polecenia jest złego (niewłaściwego) typu; Rozkaz GET wystąpił przed zakończeniem odbioru polecenia (przed odebraniem terminatora polecenia). Postępowanie urządzenia po wystąpieniu błędu polecenia: Urządzenie odrzuca wszystkie polecenia występujące po zaistnieniu błędu. Urządzenie przestaje odrzucać przychodzące dane i wznowi normalne działanie, gdy: Odbierze terminator polecenia ( opcjonalnie także po odbiorze separatora poleceń); Odbierze komunikat interfejsowy SDC lub DCL; Po ponownym włączeniu zasilania; Po przeadresowaniu urządzenia do nadawania . *RST;*CLS;:OUTP:LOAD 50;:FUNC:SHAP SIN;:VOLT %f;:FREQ %f\n SYST:ERR?\n

30 Zerowanie urządzenia - rozkazy SDC i DCL :
Rozkaz DCL i SDC nie są wysyłane przez kontroler jako zwyczajne bajty danych lecz jako rozkazy interfejsowe (ATN=1). DCL jest odbierany przez każde urządzenie dołączone do magistrali a SDC tylko przez urządzenia zaadresowane do odbioru. Rozkazy docierają do urządzenia w każdych warunkach, niezależnie od stanu kanału komunikacyjnego zwyczajnych danych. Urządzenie zawsze otrzyma rozkaz zerowania (SDC lub DCL), nawet gdy kanał danych jest zablokowany. Komunikaty SDC i DCL działają asynchronicznie. Dlatego standard IEEE488.2 przyjmuje, że rozkazy te służą do awaryjnego przerwania stanu blokady kanału komunikacyjnego. Do zerowania zasobów funkcjonalnych urządzenia służy polecenie wspólne *RST. SDC lub DCL zerują funkcje komunikacyjne urządzenia. Przerywają stan zawieszenia i pozwalają wznowić zablokowany transfer danych.