Protokół wymiany komunikatów w systemie pomiarowym

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. 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. Działanie analizatora składni : Przykład działania firmowego analizatora składni poleceń SCPI. JPA-SCPI Parser www.jpacsoft.com

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) ijest 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. 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 Parametry sprzężone:

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 10001 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.