Nefunguje vyčítání čipů. Proč není použit SPORTident Reader?

[VoiToi]

Konečně jsem měl možnost vyzkoušet vyčítání čipů a bohužel to nedopadlo valně, ať dělám co dělám, vždy vyčtení skončí chybou: "DriverInfo: <ERR> RX data timeout"

Celý aplikační log s chybou i RAW daty je v příloze: qe_log.txt

Vyčítání pomocí SI Config Plus i pomocí OBReadSI mi funguje (samozřejmě na stejném portu a se stejným nastavením, jako to zkouším v QE).

Překvapuje mě ale, proč zde znovu vymýšlíme kolo. Proč není implementováno čtení nějakého výstupu programu SPORTident Reader? Viz https://www.sportident.com/products.html#software. Třeba výstupní CSV soubor je krásně triviální, ale je možnost komunikovat i přes databázi (včetně SQLLite) nebo přes webové služby...

[arnost00]

Myslim ze pro QE musi byt nastaveno autosend ... zkus to.

[VoiToi]

Díky, se zapnutým autosend to jde. Stejně bych byl pro možnost načítat nějaký výstup SportIdent Readeru (který se autorovi bude zdát nejsnazší). Až Sportident změní zase nějaký formát uložení dat, měl by alespoň ten Reader vždy fungovat. Připadá mi zbytečné implementovat znovu to samé a snažit se rozumět vnitřní struktuře dat v čipech.

[VoiToi]

Měním tedy summary na požadavek na SportIdent Reader.

[fvacek]

Nebudu tu vypisovat 1000+1 duvod proc nechci do QE zavlect zavislost na Windows. Je to i duvod, proc jsem kolo znovu vymyslel. Uznavam, ze protokol SE neni uplne developer-friendly, ale neni to zas tak velky problem naimplementovat.

Kazdopadne, myslenka nacitat cipy ze souboru nebo databaze je celkem zajimava. Sice me zrovna nenapada zadny use-case, ale to neznamena, ze neexistuje. Takze, pokud se najde, muzeme na tuto funkci udelat feature-request a postupne ji naimplementovat.

S tim autosendem me to mrzi, mozna by pro zacatek stacilo varovani, ze krabicka neni v autosendu a vycitani nebude fungovat nebo odstranit toto omezeni.

[mezkov]

Zrovna jsem na tohle taky narazil. Problém nastává při vyčítání čipů řady 6 a vyšší. QE špatně formátuje data povelů k vyčítání - dává tam jeden byte navíc. Oprava je jednoduchá, jen mi už nezbyl čas, abych ji hodil sem.

Je to dobře, že má QE to vyčítání zabudované v sobě. To pak odpadá nutnost stahovat a konfigurovat ještě nějaký další software. Navíc když ten program je jen pro windows.

[fvacek]

Tomu nerozumim, QE pouziva autosend, aby nemusel posilat zadny povely k vycitani, tak kde je ten byte navic? Pokud nekdo narazil na problem s vycitanim jakeho-koliv typu cipu, prosim zareportujte to. Ja ziju v domeni, ze umim vycist vsechny cipy, ktere SI dosud vydal. Alespon v roce 2015 jsem poradal cca 5 zavodu + HSH a nenarazil jsem na cip, ktery by nesel vycist nebo byl vycten spatne.

[mezkov]

Ale QE to vycitani bez autosendu ma implementovano take. Kdyz prijme oznameni o vlozeni cipu, vysle povel k vycteni cipu, ale se spatnymi daty.

Jestlize je teda zamer, aby QE tenhle rezim neumel, tak bych cekal, ze na detekci cipu nebude reagovat nebo zobrazi nejake varovani. Ted je v logu videt, ze to vycitani probiha a skonci timeoutem, takze to na prvni pohled vypada, ze je chyba v te krabicce.

[fvacek]

Uplne jsem zapomnel, ze jsem to nekdy psal. Tak super, fixneme to a budeme vycitat i bez autosendu :) Dalsi dulezita vec je i to, ze QE umi pouze extended mode, ale ten uz je asi SI default.

[fvacek]

autosend asi casem poresime, ale legacy mod uz podporovat nechci. Je blbe navrzenej a extended mod je jeho nastupce, kterej v SI sami navrhli, protoze s tim puvodnim uz to fakt neslo. Pocitam, ze ho stejne co nevidet prestanou podporovat sami.

[VoiToi]

Já bych se ještě vrátil k tomu principu vyčítání. Závislost na MS se Sportident Readerem je sice jasná, ale když se podíváme na potenciální uživatele, tak bych řekl že je to marginální omezení. Naopak velkou výhodou by byla nezávislost procesu/procesů vyčítání, což vždy byla hlavní výhoda OB2000 a OBReadSI - vyčítání jelo ať se dělo co se dělo, a o to při závodě hlavně jde. Dále by se tím elegantně vyřešila záležitost více vyčítacích krabiček. Včera se mi stalo, že program náhodně spadl při nastavování tiskárny (více info k tomu nemám, takže ani nezakládám issue). To se může stát, ale problém je, že tím skončí vyčítání a hromadí se lidi. Pokud tedy nebude SI Reader, stejně bych doporučil kompletní vyčlenění modulu pro vyčítání do samostatného co nejprimitivnějšího programu.

[fvacek]

moc tomu nerozumim, proc by mel byt OBReadSI stabilnejsi program nez QE. A pokud neni, kde je ta vyhoda. QE je koncipovan tak, ze muze byt jedna jeho instance vyhrazena pouze pro vycitani a ostatnich N pro dalsi praci. Doknce si muzes QE nakonfigurovat tak, ze v nem bude pouze vycitaci plug-in, to uz primitivnejsi byt nemuze. To plati i o vice vycitacich krabickach, muzes jich mit treba 10, kdyz si pro kazdou pustis QE. (SQL musi byt Postgres) instance ani nemusi bezet na stejnem stroji. To mi prijde dost nezavisle.

[arnost00]

Souhlasím s VoiToiem v tom ze nezavisly program je pekna vec, lidi muzou vycitat porad i kdyz hlavni spadne. Jinak s V.Kasalem jsme spachali : si_read - vycita do txt souboru (format stejny jako kdyz se vycita pres racom), je pro win i linux. Pouziva ho EasyEvent od A.Chromeho. https://sourceforge.net/projects/eobsystem/files/si_read/ Ted o vikendu planuju vycitat i do nej, takze budou i testovaci data.

[arnost00]

Me tedy QE jeste nespadl, ale nekde jsme resili ze UI obcas pri tisku mezicasu nereagovalo, pamatuju si to dobre ?

[xkenia]

Co si pamatuju konverzaci na tema zamrzani UI pri tisku, tak jsme dosli k zaveru, ze problem zpusobuje graficky rezim pri tisku ...

[VoiToi]

Doknce si muzes QE nakonfigurovat tak, ze v nem bude pouze vycitaci plug-in, to uz primitivnejsi byt nemuze

Jestli to fakt jde, tak dávám palec nahoru. Bylo by možné dát na wiki návod jak na to? Jinak ohledně spolehlivosti jsem měl na mysli, že čím má program více funkcí, tak tím logicky je méně spolehlivý, tomu se vyhnout nedá i kdyby měl třeba 99% pokrytí unit testy. OBReadSI v tomto určitě žádný etalon není, už proto, že se snaží kromě vyčítání i tisknout a párkrát mi zamrzl, co si pamatuji. :-)

[fvacek]

na https://github.com/fvacek/quickbox/wiki/Application-profiles je naznak toho, jak se to pouziva. V dokumentaci jsem trochu pozadu. Ani nevim, jestli to je up to date, protoze jsem to uz dlouho nepouzil a nezkousel, ale ten kod tam je. Obecne je QE jenom obecna kostra plna plug-inu, ktery maji sice zavislosti, ale pomoci konfig souboru si muzes vybrat, ktery se maji nacist.

[fvacek]

ad UI lags pro vycitani.

QE nemuze z povahy QML generovat reporty v jinem threadu nez je UI thread, cor muze na pomalejsim stroji zpusobit neresponsinvost UI behem generovani sestavy s ustrizkem, muze to trvat az 200 msec / ustrizek, jestli si dobre vzpominam, diskuze je v issue, ktera to uz resila. Reseni je prozatim ve vyhrazeni jednoho nebo vice QE pouze na tisk ustrizku. Jejich UI se bude mozna obcas na chvilky zasekavat, ale to nebude nikomu vadit, protoze ostatni QE pojedou jako blesk.

[fvacek]

nasel jsem tu UI lag issue #61 . Me osobne se toto nikdy nestalo, ale taky jsem pouzival vzdy konfiguraci jeden QE na vycitani a tisk mezicasu + 1 a vice QE na ostatni praci