Protokoly

Protokol dekóduje data z driveru a předává je proměnným. Nastavení protokolu se zadává v poli Settings ve formátu klíč=hodnota;klíč=hodnota; parametry jednotlivých proměnných v poli Comm params při přiřazení proměnné k protokolu.

Protokoly s vlastním nastavením mají pole Settings při přidání automaticky předvyplněné výchozími hodnotami (u každého níže řádek Předvyplní se). Jde jen o výchozí hodnoty — vždy je přepište podle reálné situace (např. masterId/slaveId u XCP, mode u Modbusu). Protokoly bez vlastního nastavení (Raw CAN Frames, JSON Signal Stream, Simulation Signals, Virtual Variables, Data Log Pass-Through, Data Log Replay) se konfigurují jen přes parametry proměnných a pole Settings zůstává prázdné. Neznámý klíč v poli Settings ohlásí každý protokol varováním v logu spolu s výčtem klíčů, které čte — překlep se tak neztratí v tichém použití výchozí hodnoty.

Také pole Comm params se při přiřazení proměnné k protokolu předvyplní šablonou daného protokolu s placeholdery (např. canId="0x100" u Raw CAN) — placeholdery vždy přepište skutečnými hodnotami. Chybný Comm param (chybějící povinný parametr, špatný formát) proměnnou z komunikace vyřadí: v logu se objeví varování a proměnná zůstane bez dat; protokol kvůli ní nepřestane pracovat. Neznámé klíče se bez hlášení ignorují; klíče se porovnávají bez ohledu na velikost písmen a hodnoty smějí být v uvozovkách.

Protokol musí odpovídat typu dat driveru — obvyklé dvojice:

Project Configuration to vynucuje: protokoly, které s vybraným driverem nemohou pracovat, jsou v seznamu protokolů zašedlé s vysvětlením v tooltipu.

Raw CAN Frames

Technický název (v projektu): RawCanProtocol

Surové CAN rámce mapované na proměnné podle identifikátoru, v obou směrech, bez parsování vyšší vrstvy (J1939, CANopen). Je určen pro monitorování sběrnice a na jednoduchá zařízení, která posílají hodnoty v pevných bajtech rámce.

• Čtení: každý přijatý rámec s daným canId aktualizuje proměnné se směrem read nebo readWrite, které na něj ukazují. Hodnota se přebírá z bajtů rámce od offset, v šířce dané typem proměnné a v pořadí bajtů byteOrder. Z jednoho rámce může číst více proměnných s různým offset (například hodnota v bajtech 0–3 a čas v bajtech 4–7).
• Zápis: zápis do proměnné se směrem write nebo readWrite odešle jeden rámec s jejím canId: hodnota leží na offset ve stejné šířce a pořadí bajtů, zbytek datové části jsou nuly, délka rámce právě po konec hodnoty.
• Identifikátory: standardní 11bitové i rozšířené 29bitové. Id nad 0x7FF je automaticky rozšířené; rozšířený rámec, jehož id se vejde do 11 bitů, vynutíte klíčem extended="true". Proměnná dostane jen rámce se shodným id a shodným typem identifikátoru.
• Časové značky: vzorky nesou čas příjmu z adaptéru (PEAK dodává mikrosekundy), srovnaný s časem PC při prvním rámci; po znovuotevření adaptéru se srovnání provede znovu.

Protokol nemá žádná vlastní nastavení. Parametry proměnné:

Šablona Comm params předvyplní direction="read";canId="0x100";offset="0";byteOrder="le"; 0x100 je jen zástupná hodnota, nahraďte ji skutečným identifikátorem. Chybějící nebo nečitelný canId, offset mimo 0–7, neznámý byteOrder nebo direction se ohlásí varováním v logu a proměnná zůstane nekomunikovaná — dřívější tiché naslouchání na id 0 již není podporováno. Rámec kratší než hodnota se doplní nulami.

Podporuje všechny číselné typy skalárních proměnných včetně float a double. Matrix, textové a enum proměnné protokol neobsluhuje (ohlásí jednou v logu). Ukázku s Python generátorem na Raspberry najdete v příkladu Raw CAN rámce z Raspberry.

XCP on CAN

Technický název (v projektu): XcpProtocol

Zjednodušený XCP master (ASAM MCD-1 XCP) po CAN. Paměť ECU čte pollingem (SHORT_UPLOAD, u větších bloků UPLOAD), na vyžádání tlačítkem Read v controlu (událost On Request), nebo přes DAQ — hodnoty vysílá sama ECU (režimy vysvětluje společná kapitola Polling, DAQ a STIM u XCP níže, platí pro obě varianty XCP). Zápis na žádost operátora přes SET_MTA + DOWNLOAD, periodické buzení proměnných proudem přes STIM. Přenáší skalární proměnné i proměnné Matrix (mapy, křivky, bloky hodnot) a využívá block mód, pokud ho slave nabízí (Block mód). Bez seed & key (chráněná kalibrace zápis zablokuje; chráněný DAQ prostředek znamená návrat k pollingu). Pořadí bajtů a granularitu adres protokol zjistí z odpovědi na CONNECT.

Předvyplní se: masterId=0x200;slaveId=0x201;extendedIds=false;requestTimeoutMs=1000;requestRetries=2;daqTimestamps=slave

Nastavení protokolu:

Parametry proměnných jsou společné oběma variantám XCP — viz Polling, DAQ a STIM u XCP.

Specifika CAN:

• Hodnoty delší než 6–7 bajtů (Long/ULong/Double) a matice se přenášejí více pakety (s block módem jako UPLOAD burst, resp. bloky DOWNLOAD + DOWNLOAD_NEXT, jinak řetězcem jednotlivě potvrzovaných příkazů) a přenos není atomický — pokud ECU hodnotu právě mění, může být výsledek nekonzistentní. (Režimu DAQ se tento problém netýká: ECU hodnoty vzorkuje konzistentně při své události.)
• Na klasickém CAN nese jeden paket jen 6–7 datových bajtů, takže velká matice znamená stovky až tisíce rámců — viz Block mód.
• DAQ paket na klasickém CAN nese nejvýše 8 bajtů včetně hlavičky, do jednoho paketu se tedy vejde jen několik malých hodnot — protokol proměnné automaticky rozloží do více paketů na cyklus.
• Protokol podporuje jen slave s adresní granularitou BYTE (běžný případ); jinou granularitu odmítne a zůstane ve stavu Faulted.
• requestTimeoutMs platí na jeden příkaz; při timeoutu protokol pošle SYNCH a příkaz zopakuje, nejvýše requestRetrieskrát — s výchozími hodnotami je maximální doba čekání přibližně trojnásobek timeoutu.
• Chybné nastavení protokolu (chybějící id nebo id v jiném než hexadecimálním formátu, id mimo rozsah CAN, requestTimeoutMs ≤ 0, záporné requestRetries) převede protokol při startu do stavu Faulted s popisem v logu.

XCP on TCP

Technický název (v projektu): XcpTcpProtocol

Tentýž zjednodušený XCP master po XCP on Ethernet (transport TCP): polling nebo DAQ čtení, zápisy operátora i STIM, pořadí bajtů a limity z odpovědi na CONNECT. ECU je TCP server; QInsight se k ní připojuje driverem TCP Client — IP adresa a port se proto nastavují na driveru, ne na protokolu.

Předvyplní se: requestTimeoutMs=1000;requestRetries=2;daqTimestamps=slave

Nastavení protokolu:

Parametry proměnných jsou společné oběma variantám XCP — viz Polling, DAQ a STIM u XCP.

Specifika TCP:

• Ethernet dovoluje velké XCP pakety, takže každá skalární hodnota (do 8 bajtů včetně Double) se přenáší jedním paketem, atomicky — žádné řetězení jako na CAN — a jeden DAQ paket typicky nese celou skupinu proměnných najednou.
• Matice do 247 B (MAX_CTO − 1) se čte jedním SHORT_UPLOAD; větší matice se přenáší více pakety a přenos není atomický (typicky UPLOAD burst v block módu — mapa 1 KB je jeden burst pěti paketů).
• Navázání a obnova samotného TCP spojení (connectionTimeoutMs, reconnectDelayMs, reconnectAttempts, keepAliveMs) se nastavují na driveru TCP Client; zdejší requestTimeoutMs a requestRetries pokrývají jen výměnu příkaz/odpověď XCP.

Vyzkoušení bez hardwaru: open-source slave XCPlite lze použít jako bezplatnou testovací ECU na localhostu: přeložte a spusťte XCPlite příklad hello_xcp a proměnné i DAQ události v QInsight nastavte podle A2L souboru, který XCPlite vygeneruje (hotový projekt pro XCPlite ve složce Examples není). Ukázky se skutečnou deskou jsou v kapitolách XCP on TCP na NUCLEO-H723ZG a Dvě ECU najednou.

Polling, DAQ a STIM u XCP

Oba XCP protokoly konfigurují proměnné stejně a nabízejí tři způsoby čtení (polling, čtení na vyžádání a DAQ) a proudový zápis (STIM). Který režim proměnná používá, rozhoduje událost (event), na kterou je navázaná — nic jiného se v konfiguraci nemění.

Parametry proměnné (pole Comm params):

Předvyplněné address="0x0" je jen placeholder — vždy ho nahraďte skutečnou adresou z popisu ECU (typicky atributy ECU_ADDRESS a ECU_ADDRESS_EXTENSION v A2L souboru). Šířka a datový typ hodnoty se berou z proměnné samotné, zde se nezadávají. Starší projekty mohou obsahovat klíče size a dataType — přijímají se a kontrolují proti typu proměnné; nesoulad je konfigurační chyba. U matice viz Proměnné typu Matrix u XCP.

Polling — dotazuje se master

Výchozí režim. Proměnná je navázaná na běžnou periodickou událost; master čte adresu v periodě události (časování PC, jeden dotaz/odpověď na proměnnou a cyklus). Jde o jednoduchý a univerzální režim — funguje s každým XCP slavem — každá hodnota však vyžaduje jeden round-trip, takže není vhodný pro rychlé periody ani větší počty proměnných.

Událost:     Poll100ms         (Period 100, Unit Milisec)
Comm params: address="0x39B68";addressExtension="1";direction="read";eventRef="Poll100ms"

On Request — čtení na vyžádání

Proměnná navázaná na událost typu OnRequest se nepolluje ani nečte přes DAQ — master ji přečte jednorázově, až když operátor stiskne Read v controlu (Single-Signal, Watch Table, Matrix). Hodí se pro kalibrační data, která se mění jen na pokyn operátora, typicky velké mapy: blok o tisících bajtech se po lince nepřenáší zbytečně každou periodu.

Událost:     OnRequest         (Type OnRequest)
Comm params: address="0x24014270";direction="readWrite";eventRef="OnRequest"

Čtení na vyžádání funguje jen za běhu komunikace; neúspěšné čtení podbarví tlačítko Read červeně. Proměnná se směrem read nebo readWrite může být skalár i matice. Stejnou událost podporují také Modbus Master a Simulation Signals.

DAQ — vysílá ECU

V režimu DAQ (Data Acquisition) master při připojení jen nakonfiguruje, co se má vzorkovat a na kterém event kanálu ECU — od té chvíle ECU hodnoty vzorkuje sama, vlastní rychlostí, a bez dotazování je vysílá. Přínosy oproti pollingu:

• rychlost — vzorkování v cyklu ECU (např. každou 1 ms), daleko nad možnosti pollingu typu dotaz/odpověď,
• konzistence — všechny hodnoty jednoho event kanálu jsou vzorkované ve stejný okamžik v ECU, takže patří k sobě,
• efektivita — žádné dotazy na jednotlivé hodnoty; větší počet proměnných znamená jen minimální zátěž navíc.

Event kanál ECU je místo v programu ECU, kde ECU zveřejňuje aktuální hodnoty — např. „každý průchod 1ms smyčkou“. Čísla a jména kanálů jsou v A2L souboru ECU (položky EVENT) nebo v její dokumentaci.

Jak DAQ použít: vytvořte periodickou událost a vyplňte jí pole Extra Params (Home → Project Configuration → Events):

direction="DAQ";daqId="1"

Oba klíče platí jen společně. Period události v režimu DAQ nic neřídí — dokumentuje očekávaný cyklus kanálu a při připojení se porovná s hodnotou, kterou nahlásí ECU (nesoulad zapíše warning s oběma hodnotami).

Proměnné se pak na událost vážou stejně jako na kteroukoli jinou — přes eventRef:

Událost:     Daq_mainloop      (Period 1, Unit Milisec,
                                Extra Params: direction="DAQ";daqId="1")
Comm params: address="0x39B68";addressExtension="1";direction="read";eventRef="Daq_mainloop"

Proměnné navázané na DAQ událost proudí z ECU; proměnné na běžné periodické události se dál pollují. Oba režimy se v jednom protokolu volně kombinují — typicky rychlá měření přes DAQ a kalibrační parametry pollingem (a zápisem). Na zápisy nemá DAQ žádný vliv.

Chování a diagnostika DAQ

• Validace je striktní. Překlep v Extra Params nikdy nevede k tichému vypnutí DAQ: direction="DAQ" bez daqId (nebo obráceně) nebo chybný zápis vyřadí proměnnou z komunikace už při načtení projektu s warningem v logu, který přesně popisuje, co je špatně. Neznámý klíč pouze zapíše warning a ignoruje se.
• Kanál se ověřuje při připojení. Protokol si od ECU vyžádá jméno a cyklus kanálu (pokud to slave podporuje), jméno kanálu z ECU zapíše do logu — zkontrolujte, zda daqId odkazuje na zamýšlený kanál — a cyklus porovná s Period události.
• Automatický návrat k pollingu. Pokud slave DAQ prostředek nemá, chrání ho přes seed & key, kanál odmítne nebo se konfigurace DAQ nezdaří, dotčené proměnné se automaticky vrátí k pollingu (rychlost pak určuje Period události) a warning vysvětlí důvod. Session běží dál v obou případech.
• Časové značky DAQ vzorků řídí nastavení daqTimestamps. Výchozí slave klade vzorky na časovou osu podle časových značek ECU — vzorky pak nesou přesný okamžik vzorkování v ECU, ne okamžik doručení paketu (u dávkovaných přenosů podstatný rozdíl). Značky se ukotvují k času PC a pomalý náběh hodin ECU se průběžně kompenzuje; trvalý drift nad ~0,3 % zapíše diagnostický warning (obvykle jde o příznak nevhodného zdroje hodin v ECU). U slave bez časových značek se automaticky použije čas příjmu. Hodnota master časové značky ECU ignoruje a vzorky nesou vždy čas příjmu paketu na PC.
• Přetížení je warning, ne porucha. Pokud ECU nestíhá, vzorky zahodí a přetížení signalizuje; QInsight zapíše warning a měření pokračuje dalšími vzorky. Totéž platí, pokud krátkodobý nápor dat nestihne zpracovat strana PC.

STIM — stimulace z masteru

DAQ má i opačný směr: STIM (stimulace). Master periodicky vysílá aktuální hodnoty zapisovatelných proměnných do ECU proudem datových paketů — bez dotazu a odpovědi na každý zápis. Je vhodný pro plynulé buzení vstupů ECU, např. žádané hodnoty z Python skriptu nebo posuvníku operátora.

Konfigurace zrcadlí DAQ — jen s opačným směrem:

Událost:     Stim_mainloop     (Period 10, Unit Milisec,
                                Extra Params: direction="STIM";daqId="2")
Comm params: address="0x39B70";direction="write";eventRef="Stim_mainloop"

• Událost s Extra Params direction="STIM";daqId="N" označuje event kanál ECU, který stimulaci přijímá. Na rozdíl od DAQ zde Period událost řídí: je to interval, ve kterém master proudy paketů vysílá (časování PC), proto musí být událost periodická s kladnou periodou.
• Proměnné se na událost vážou přes eventRef a musí mít direction="write"; stimulovat lze jen skalární proměnné.
• Každou periodu se odešlou aktuální hodnoty všech proměnných kanálu — poslední zápis operátora či skriptu tak do ECU proudí opakovaně, dokud ho nový zápis nenahradí.

Automatický návrat k přímým zápisům: pokud slave STIM prostředek nemá, chrání ho přes seed & key, kanál neprojde validací nebo se hodnota do STIM paketu nevejde, dotčené proměnné se s warningem vrátí k běžnému zápisu při změně (SET_MTA + DOWNLOAD) a session běží dál. Po dobu aktivní stimulace se zápisy stimulovaných proměnných přenášejí výhradně proudem — jednotlivé zapisovací příkazy se pro ně neposílají. DAQ, STIM i polling se v jednom protokolu volně kombinují.

Zápisy operátora

Hodnoty se při zápisu zadávají v inženýrských jednotkách — surová hodnota pro ECU se dopočítá inverzní konverzí prezentace (viz Zápis hodnot do zařízení); protokol do ECU vždy posílá raw. Zápis je zablokovaný nejen u chráněné kalibrace, ale i když slave kalibrační prostředek vůbec nenabízí.

Zapsaná hodnota se v controlech neukazuje hned — objeví se, až ji zařízení vrátí dalším pollingem nebo čtením Read. Úspěšné zápisy se do logu nezapisují; neúspěšný zápis zapíše warning.

Proměnné typu Matrix u XCP

XCP přenáší i proměnné Matrix (pole, křivka, mapa) — celý blok (osy i data) jako jednu souvislou oblast paměti ECU:

• address je začátek bloku, tedy první breakpoint osy X (u pole bez os první datová hodnota); pořadí v paměti je osa X → osa Y → data po řádcích,
• dataType se u matice ignoruje — typy sekcí určuje Layout proměnné; volitelné size musí odpovídat velikosti celého bloku,
• Endianness proměnné musí odpovídat ECU; pořadí bajtů ze CONNECT se u matice neuplatní, nesoulad jen zapíše warning při připojení,
• matice se čte pollingem (periodická událost) nebo na vyžádání (On Request); navázání na DAQ nebo STIM událost je konfigurační chyba,
• limit: datová sekce nejvýše 16 384 B (64 × 64 × float), osy navíc — mapa 64 × 64 float s osami ushort má 16 640 B,
• při zápisu se posílají jen změněné buňky: sousední nebo překrývající se buňky se sloučí do jednoho okna a každé okno se zapíše přes SET_MTA + DOWNLOAD (v block módu po blocích). Vložený řádek 64 buněk je tak jediný přenos.

Block mód

Při připojení protokol zjistí, zda slave podporuje block mód (bit v odpovědi na CONNECT, parametry MAX_BS a MIN_ST z GET_COMM_MODE_INFO), a zapíše to do logu:

XCP: block mode — slave yes, master yes (MAX_BS 255, MIN_ST 0 × 100 µs).

• Čtení (slave block mode) — větší blok se čte jedním SET_MTA a UPLOAD bursty po nejvýše 255 B; slave odpoví řadou paketů bez dalších dotazů.
• Zápis (master block mode) — data jdou po blocích DOWNLOAD + DOWNLOAD_NEXT (nejvýše MAX_BS paketů a 255 B, rozestup MIN_ST), každý blok se potvrzuje jednou. Chyba sekvence (ERR_SEQUENCE) blok zopakuje od SET_MTA.
• Bez block módu se větší přenosy řetězí po jednotlivých paketech, z nichž každý se potvrzuje — funguje to s každým slavem, jen pomaleji.

Block mód se týká přenosů větších než jeden paket — hlavně matic a na CAN i 8bajtových skalárů. Nastavení v QInsight nevyžaduje.

Modbus Master (RTU/TCP)

Technický název (v projektu): ModbusMasterProtocol

Modbus master (klient): periodicky čte coily a registry a zapisuje hodnoty na žádost operátora. Rámování rtu (CRC16, sériová linka) nebo tcp (MBAP hlavička).

Předvyplní se: mode=rtu;unitId=1;requestTimeoutMs=1000;requestRetries=2

Nastavení protokolu:

Parametry proměnné:

Počet registrů plyne z datového typu proměnné: 1 (Byte, SByte, UShort, Short), 2 (UInt, Int, Float), 4 (ULong, Long, Double). Bitové tabulky (coil, discreteInput) obsazují vždy 1 bit bez ohledu na typ; nenulová hodnota = ON. Mapovat lze jen číselné skalární proměnné (bool, text ani enum nelze).

Dále k chování masteru:

• requestRetries je počet opakování navíc k prvnímu pokusu (výchozí 2 = až 3 vysílání) a requestTimeoutMs platí na každý pokus zvlášť. Dřívější názvy timeoutMs a retries se už nečtou — v logu se objeví varování o neznámém klíči.
• Výpadek spojení (odpojený převodník nebo kabel) řeší driver: master mezitím dotazy pozastaví a po obnovení transportu pokračuje automaticky — viz Obnova spojení.
• unitId se zadává desítkově. address smí být hex (0x64), po uložení projektu se ale zobrazí desítkově (100) — jde o tutéž hodnotu.
• Pro registerType jsou přijímány i zkrácené aliasy discrete, input, holding; pro wordOrder aliasy be/le.
• Každá čtená proměnná se čte samostatným požadavkem v periodě své události; eventRef musí být existující periodická událost, nebo událost On Request — taková proměnná (skalár i matice) se nepolluje a čte se jednorázově tlačítkem Read v controlu (viz Polling, DAQ a STIM u XCP).
• Zapsaná hodnota se v controlech objeví až po dalším čtení ze zařízení.
• Chybné Comm params proměnnou s varováním v logu vyřadí z komunikace.

Proměnné typu Matrix

Modbus Master přenáší i proměnné Matrix (pole/křivka/mapa) — celý blok jako souvislý rozsah registrů od address:

• povolené tabulky jsou jen registrové: holdingRegister (čtení i zápis) a inputRegister (jen čtení); bitové tabulky coil/discreteInput jsou pro matici zakázané,
• počet registrů = velikost matice v bajtech / 2 (zaokrouhleno nahoru); čtení probíhá jedním požadavkem FC03/FC04, zápis posílá jen registry změněných buněk (FC06/FC16),
• limit velikosti: matice se nedělí do více rámců — zapisovatelná matice smí mít max. 123 registrů (246 B), matice jen pro čtení 125 registrů (250 B); větší matici protokol odmítne s varováním v logu,
• wordOrder se u matice neuplatní — pořadí bajtů určuje Endianness proměnné (registr = 2 bajty, vyšší bajt první).

Modbus Slave (RTU/TCP)

Technický název (v projektu): ModbusSlaveProtocol

Modbus slave (server): vystavuje proměnné jako coily, diskrétní vstupy, input a holding registry. Vzdálený master čte aktuální hodnoty proměnných; zápis od mastera (FC 05/06/16) hodnotu proměnné nastaví.

Předvyplní se: mode=rtu;unitId=1;respondToAnyUnit=false

Nastavení protokolu:

Parametry proměnné jsou stejné jako u masteru (registerType, address, wordOrder); eventRef není potřeba. K chování slave:

• U tabulek jen pro čtení (discreteInput, inputRegister) musí direction zůstat read — jiný směr je chyba a proměnná se nevytvoří.
• Slave obsluhuje jen skalární proměnné; Matrix proměnné do map nezařadí a upozorní na to varováním v logu.
• Každá proměnná zabírá souvislý rozsah adres; překrývající se adresy jsou chyba při startu.
• Zápis od mastera musí pokrýt celý rozsah proměnné najednou: víceregistrovou hodnotu (Float, Int, Double…) nelze zapsat po jednom registru přes FC06 — jen jedním FC16 přes celý rozsah; částečný zápis slave odmítne jako ILLEGAL DATA ADDRESS. Obdobně čtení zasahující nenamapovanou adresu (mezeru mezi proměnnými) se odmítne celé.
• Výchozí hodnota respondToAnyUnit z tabulky platí pro vynechaný parametr — předvyplněná šablona ale obsahuje false, takže pro TCP chování „odpovídat komukoli“ nastavte true ručně. Hodnoty jsou true/false (ne 1/0).

JSON Signal Stream

Technický název (v projektu): JsonSignalProtocol

Textové řádky s JSON objekty, jeden objekt na řádek, oddělené \n — stejný tvar v obou směrech:

{"name": "temp", "value": 23.4, "t": 12.345}
{"name": "state", "value": "RUNNING"}
{"name": "alarm", "value": true}

Další pole ve zprávě se ignorují. Protokol řádky sestavuje sám z bajtů, které mu driver předává, včetně řádku rozděleného mezi dva pakety — běží proto na kterémkoli bajtovém driveru: TCP Client (QInsight se připojí k zařízení), TCP Server (zařízení se připojí k QInsight) i Serial Port.

Čtení: zprávy ze zařízení plní proměnné se směrem read nebo readWrite. Pokud zařízení posílá t, protokol při prvním vzorku určí posun mezi časem zařízení a časem PC a dále vzorkům přiřazuje časové značky podle t; při skoku t zpět (restart zařízení) se posun určí znovu.

Zápis: zápis do proměnné se směrem write nebo readWrite — z watch table, jiného controlu nebo skriptu — odešle zařízení řádek stejného tvaru, {"name": "setpoint", "value": 42}. Odesílá se surová hodnota proměnné; inženýrskou hodnotu zadanou přes prezentaci QInsight převede předem. Zařízení tak lze i řídit, bez druhého protokolu.

Zahazované zprávy a jejich hlášení: neplatný JSON, zpráva bez name/value, jméno bez odpovídající proměnné a hodnota nepřevoditelná na typ proměnné se zahodí a protokol to ohlásí v logu jednou pro každou příčinu (první chybný řádek je v hlášení citovaný, neznámé jméno se hlásí jednou pro každé jméno). Pokud signál zůstává bez dat, zkontrolujte nejprve log.

Protokol nemá žádná vlastní nastavení. Parametry proměnné:

Šablona Comm params předvyplní direction="read";name="<jméno proměnné>". Klíče id, signal a signalName ze starších projektů se už nečtou; proměnná bez name se páruje podle svého jména. Protistranu pro vyzkoušení bez hardwaru — Python skript generující sinusy a přijímající zápisy — najdete v příkladu JSON signály z Python generátoru.

Simulation Signals

Technický název (v projektu): SimulDataProtocol

Generuje simulované signály pro testování bez hardwaru — používá se výhradně s driverem Simulation. Každá proměnná se generuje přesně v periodě své události (eventRef), takže různé proměnné mohou běžet různou rychlostí; proměnná na události On Request se vygeneruje jednorázově při každém stisku Read v controlu. Co se do proměnné generuje, vybírá parametr signal v Comm params. Zápisy operátora a čtení na vyžádání předává protokolu driver Simulation, takže se simulované zařízení chová jako skutečné: controly ukazují jen to, co protokol „ze zařízení“ přečte. Kompletní ukázku všech signálů najdete v příkladu Simulace: všechny signály.

Generované signály (skalární proměnné)

Procházky (walk*) postupují o krok s každým vygenerovaným vzorkem — proměnná s rychlejší událostí se tedy mění rychleji. Každá proměnná má vlastní nezávislou instanci generátoru (dvě proměnné se stejným signal běží nezávisle); hodnota se převádí na typ proměnné (celočíselné typy se zaokrouhlují a ořezávají na rozsah typu).

Dvojice laosstrain / laosstress běží na společných hodinách protokolu, takže v XY grafu (napětí proti deformaci) kreslí uzavřenou Lissajousovu smyčku. Nelinearita je v rozsahu 0 až 2: harmonická k má amplitudu úměrnou nonlin^k, při 0 je odezva čistý posunutý sinus a s rostoucí hodnotou se smyčka deformuje.

Maticový signál (proměnná Matrix)

Osy matice se zapíší jen při prvním vzorku, takže úprava os uživatelem zůstane zachována i při dalším generování; průběžně se přepisují jen datové buňky. Matice se generuje se směrem read i readWrite; s readWrite lze buňky editovat z Matrix controlu a úprava se zapíše přímo do bufferu (při zapnutém parametru hold generátor stojí, takže editace nezmizí). Hodnoty jsou inženýrské, na surové je převádí prezentace matice.

Parametrové proměnné

Skalární proměnná s některým z klíčů níže v signal (a obecně každá skalární proměnná se směrem readWrite) se negeneruje. Jde o parametr simulace: generátory reagují na její aktuální hodnotu při každém vzorku. Zapisuje se z watch table, jiného controlu nebo ze skriptu.

Parametr se směrem read nebo readWrite se čte zpět jako na skutečném zařízení — v periodě své události protokol ohlásí jeho aktuální hodnotu s novou časovou značkou (nic negeneruje), nebo ji ohlásí jednorázově tlačítkem Read u události On Request. Zapsaná hodnota se tak v controlech objeví po nejbližším čtení. Parametr se směrem write se nečte nikdy a v controlech se neukáže. Parametr bez periodické události zapíše do logu varování Simulation: variable '…' has no periodic event ('…'); not polled.

Existující parametr má přednost před výpočtem: jakmile projekt obsahuje například h2amp, řídí se amplituda 3. harmonické jen jím a nonlin na ni už nemá vliv. Bez parametru použije generátor hodnotu z Comm params (amp, freq, nonlin) nebo svou výchozí.

Klíč init="…" dává parametru výchozí hodnotu: protokol ji zapíše při každém Startu runtime, takže generátory s ní počítají bez jakéhokoli skriptu. V controlech se hodnota zobrazí nejbližším čtením zpět — proto parametr, který chcete vidět, nastavte na readWrite s periodickou událostí. Bez init si proměnná ponechá hodnotu, kterou má.

Parametry proměnné

Protokol nemá žádná vlastní nastavení. Vše se zadává v Comm params proměnné:

Šablona Comm params předvyplní signal="step". Bez signal se tvar zvolí podle typu hodnoty (int → noisystep, float → step, jinak walk1); při neznámé hodnotě signal se s varováním použije tentýž výběr podle typu. Generují se jen číselné proměnné — text, bool a enum se negenerují a v logu se objeví varování; Matrix se generuje jen se signálem thermal. multiplier ze starších projektů se ignoruje.

Virtual Variables

Technický název (v projektu): VirtualDataProtocol

Nosič virtuálních proměnných: proměnných, jejichž hodnoty nepřicházejí ze zařízení, ale počítají je Python skripty — typicky filtry, přepočty a jiné odvozené veličiny. Proměnná přiřazená tomuto protokolu se chová jako každý jiný komunikovaný signál: jde zobrazit v controlech, logovat i přehrávat a počítá se do limitu komunikovaných signálů Free licence. Používá se výhradně s driverem Virtual Variables Host.

Protokol nemá žádný časovač: vzorek vzniká v okamžiku, kdy skript do proměnné zapíše (RawValue nebo EngValue). Každý zápis = jeden vzorek s časovou značkou okamžiku zápisu — i když skript zapíše stejnou hodnotu. Zápisy procházejí vyrovnávací frontou, publikují se v pořadí zápisů a skript nikdy nečeká na vykreslení; když skript nezapisuje, žádné vzorky nevznikají.

Protokol nemá žádná vlastní nastavení a proměnná žádné parametry: Comm params zůstávají prázdné, virtuální proměnnou určuje sama její identita.

Na virtuální proměnnou lze navázat On-change trigger dalšího skriptu a výpočty řetězit — vyhněte se ale cyklu (skript zapisující do proměnné, jejíž trigger ho spouští). Kompletní ukázku s exponenciálním filtrem najdete v příkladu Simulace: všechny signály.

Data Log Pass-Through

Technický název (v projektu): PassThroughProtocol

Sběrný protokol driveru Data Log Recorder: předává mu hodnoty logovaných proměnných 1:1, jak je jejich zdrojový protokol publikuje. Do projektu ho QInsight přidává k driveru sám a proměnné do něj zapisuje podle zaškrtnutí Log to FileDataLogger u proměnné — ručně se nepřidává ani se mu nepřiřazují proměnné. Proměnná logovaná tímto protokolem se nepočítá do limitu komunikovaných signálů Free licence.

Protokol nemá žádná vlastní nastavení a proměnná žádné parametry: pole Settings i Comm params zůstávají prázdné. Postup zapnutí logování a parametry záznamu popisuje kapitola Logování dat.

Data Log Replay

Technický název (v projektu): DataLogReplayProtocol

Protokol driveru Data Log Replay: hodnoty přehrávaného .qilog souboru zapisuje do proměnných projektu i s původní časovou značkou. Záznam se k proměnné páruje podle jejího Id, náhradně podle dvojice namespace + jméno. Do projektu ho přidává tlačítko Import v ribbon menu Runtime spolu s driverem; ručně se nepřidává.

Protokol nemá žádná vlastní nastavení a proměnná žádné parametry: pole Settings i Comm params zůstávají prázdné. Hlášení v logu (jednou za příčinu, ne za každý záznam): proměnná ze záznamu v projektu neexistuje — celý signál se při přehrávání přeskočí; záznam nejde převést na typ proměnné — přeskočí se jen on a přehrávání pokračuje; protokol neběží — záznamy se zahazují. Ovládání přehrávání a parametry driveru popisuje kapitola Přehrávání logu.

Protokoly jsou pluginy — vlastní protokol viz Vlastní rozšíření.