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) se konfigurují jen přes parametry proměnných a pole Settings zůstává prázdné.

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á se prostě neplní, protokol kvůli ní nespadne. 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 pracovat neumí, jsou v seznamu protokolů zašedlé s vysvětlením v tooltipu.

Raw CAN Frames

Technický název (v projektu): RawCanProtocol

Monitorování CAN sběrnice: standardní (11bitové) CAN rámy mapuje podle identifikátoru přímo na proměnné — bez parsování vyšší vrstvy. Pouze čtení; rozšířené (29bitové) rámce ignoruje.

Protokol nemá žádná vlastní nastavení.

Comm params se předvyplní: canId="0x100";offset="0";byteOrder="le"

Pozor: canId se vykládá vždy hexadecimálně, i bez prefixu 0x — canId=100 znamená 0x100 (dekadicky 256), ne sto. Hodnota se nekontroluje proti 11bitovému rozsahu; id mimo rozsah nebo překlep (ten se tiše nahradí nulou) se projeví jen tím, že proměnná nikdy nedostane data. U byteOrder platí jen tokeny z tabulky — cokoli jiného se tiše bere jako le. offset za koncem rámce dává samé nuly.

Podporuje všechny číselné typy skalárních proměnných včetně float a double (šířka se bere z datového typu proměnné; chybějící bajty krátkého rámce se doplní nulami). Matrix, textové a enum proměnné protokol neobsluhuje.

XCP on CAN

Technický název (v projektu): XcpProtocol

Zjednodušený XCP master (ASAM MCD-1 XCP) po CAN. Paměť ECU čte buď pollingem (SHORT_UPLOAD), nebo přes DAQ — hodnoty vysílá sama ECU (oba 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. Bez block módu a 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 si protokol zjistí z odpovědi na CONNECT.

Předvyplní se: masterId=0x200;slaveId=0x201;extendedIds=false;timeoutMs=1000;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) se pollují i zapisují řetězcem více příkazů a přenos není atomický — pokud ECU hodnotu právě mění, může být výsledek nekonzistentní. (DAQ tímhle netrpí: ECU hodnoty vzorkuje konzistentně při své události.)
• DAQ paket na klasickém CAN nese nejvýše 8 bajtů včetně hlavičky, do jednoho paketu se tedy vejde jen pár 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.
• timeoutMs platí na jeden příkaz; při timeoutu se transakce až dvakrát opakuje, nejhorší čekání je tedy zhruba trojnásobek.
• Chybné nastavení protokolu (chybějící/nehexové id, id mimo rozsah CAN, timeoutMs ≤ 0) 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: timeoutMs=1000;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á podporovaná 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.
• Timeouty samotného TCP spojení (connectionTimeoutMs, reconnecty) se nastavují na driveru TCP Client; zdejší timeoutMs pokrývá jen výměnu příkaz/odpověď XCP.

Vyzkoušení bez hardwaru: open-source slave XCPlite poslouží jako testovací ECU zdarma na localhostu. V QInsight složce Examples jsou dva hotové projekty: XcpTcp_XCPlite_Daq01.qproj (minimální čistě DAQ projekt — čtyři proměnné vysílané z ECU) a XcpTcp_XCPlite_Test01.qproj (DAQ měření plus kalibrační zápisy). Stačí přeložit XCPlite příklad hello_xcp, spustit ho a otevřít jeden z projektů.

Polling, DAQ a STIM u XCP

Oba XCP protokoly konfigurují proměnné stejně a nabízejí dva způsoby čtení (polling a DAQ) plus 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é, tady 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.

Polling — ptá 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). Jednoduché a univerzální — funguje s každým XCP slavem — ale každá hodnota stojí jeden round-trip, takže to neškáluje na 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"

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ím tempem, a bez ptaní je vysílá. Přínosy proti pollingu:

• rychlost — vzorkování v cyklu ECU (např. každou 1 ms), daleko za možnostmi dotaz/odpověď pollingu,
• 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; mnoho proměnných nestojí skoro nic navíc.

Event kanál ECU je místo v programu ECU, kde ECU zveřejňuje čerstvé 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 úplně stejně jako na každou 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). Zápisů se DAQ nijak nedotýká.

Chování a diagnostika DAQ

• Validace je striktní. Překlep v Extra Params nikdy DAQ tiše nevypne: direction="DAQ" bez daqId (nebo obráceně) či vadný 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íč jen 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 umí), jméno kanálu z ECU zapíše do logu — zkontrolujte ho, ať daqId míří tam, kam myslíte — a cyklus porovná s Period události.
• Automatický návrat k pollingu. Když 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 (tempo pak určuje Period události) a warning vysvětlí proč. 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ý rozjezd hodin ECU se průběžně dorovnává; trvalý drift nad ~0,3 % zapíše diagnostický warning (bývá to příznak špatného zdroje hodin v ECU). Slave bez časových značek automaticky spadne na č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. Když ECU nestíhá, vzorky zahodí a přetížení signalizuje; QInsight zapíše warning a měření pokračuje dalšími vzorky. Totéž platí, když nával krátkodobě nestíhá 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. Hodí se 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ý únik na přímé zápisy: když 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 obyčejnému zápisu na změnu (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í.

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;timeoutMs=1000;retries=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 nejde).

Dále k chování masteru:

• retries je počet opakování navíc k prvnímu pokusu (výchozí 2 = až 3 vysílání) a timeoutMs platí na každý pokus zvlášť.
• 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 fungují 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.
• 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); konfigurátor hlídá jednotný limit 246 B,
• 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

Dekóduje textové řádky s JSON objekty {"name": "...", "value": ..., "t": ...} (oddělené novým řádkem) na hodnoty proměnných. Pouze čtení. Volitelné pole t (čas zdroje v sekundách) se použije pro rekonstrukci časových značek.

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

Podporuje číselné, textové, bool i enum proměnné. Když zadáte víc aliasů najednou, platí pořadí name > signal > signalName > id. Jména signálů se porovnávají bez ohledu na velikost písmen. Nerozpoznatelné řádky, zprávy bez name/value a hodnoty nepřevoditelné na typ proměnné se zahazují bez hlášení — když signál zůstává prázdný, zkontrolujte nejdřív přesnou shodu jména v poli name.

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í. Tvar signálu vybírá parametr signal:

Procházky (walk*) postupují o krok s každým vygenerovaným vzorkem — proměnná s rychlejší událostí tedy bloudí 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). Generují se jen číselné skalární proměnné — text, bool, enum a Matrix se negenerují a v logu se objeví varování.

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

Šablona Comm params předvyplní signal="step". Bez signal se tvar zvolí podle typu hodnoty (int → noisystep, float → step, jinak walk1); neznámá hodnota signal spadne s varováním na tentýž výběr podle typu. 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í. Parametry proměnné:

Na virtuální proměnnou lze navěsit 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 Filtr signálu skriptem.

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