FTDI ?! (diskuse)

[Luk]

Trochu mi to připomíná, když jsem dělal praktickou část maturity (už je to tedy hodně dávno). Bylo to řízení obráběcího stroje pomocí PLC Tecomat. Dalo se to simulovat v nějakém softwaru (pod DOSem), takže pro vyzkoušení ani nebyl potřeba samotný automat, natož ta mechanická část. Psalo se to tehdy v nějakém jazyku hodně podobném assembleru. Nebylo to nic příjemného, ale dalo se to zvládnout.

Tehdy tam bylo jedno téma, které si nikdo nechtěl vytáhnout (a také si ho kupodivu nakonec nikdo nevytáhl) - řízení kolejiště zmíněným automatem. Vlaky se nesměly srazit, musely zastavovat ve stanicích, závory se musely včas sklápět atd. Nikomu se to za celý školní roku nepodařilo zprovoznit, proto se toho všichni báli.

[Zdeněk Štěpánek]

Zlatej tecomat, jeste ho mam doma, i kdyz uz nejak nechce komunikovat. Ja si vytahl k mature rizeni krizovatky, ucitel ocekaval sileny program plny smycek a cekani, ja si misto toho nastudoval tabulkove funkce a v 5sec cyklu posilal na vystup postupne radky z predpripravene tabulky. Misto 100 radku tak 5.

Jinak tohle je jednoznacne problem ve woknech, tgakze bych prohlasil ze z duvodu spolehlivosti to bude rizene operacnim systemem a ne parodii na zavadec na hry.

Zdenek

[Hrabosh]

Problém je v tom, že můj kolega napsal takový kreslící soft. pod Windows (umí to otevřít ten G-kod, dá s v tom malovat), ze kterého by to mělo jít posílat na to moje zařízení.

Jinak bych to taky neřešil a prezentoval to z mojeho ntb, kde mám Gentoo. Akorát bych ho musel přejmenovat, protože se ted jmenuje PrDELL (=Přenosný DELL) a vzhledem k tomu, že je název počítae v konzoli vidět, mohl by to u rezentace diplomky být problém ...

[Zdeněk Burda]

Přejmenování většinou není potřeba, stačí v daném shellu změnit prompt ($PS).

[zde]

Zvláštní.. když jsem nafasoval ntb (taky Dell), dal jsem úplně stejnej hostname .-)

[Pavel Vymetálek]

Pokud si dobře vzpomínám, tak jsem podobný problém vyřešil použitím starších (win) ovladačů od FTDI. S ovladači v 2.00.00 to nechodilo tak nějak pořádně... Teď tam mám ovladače v 1.00.2154 nebo 1.00.2176.

Na webu FTDichip jsem to už nenašel, posílali mi to Papouchové. Můžu poslat, bude-li zájem.

P.S.: V Linuxu to chodilo 100%, jak to tak bývá...

[Pavel Vymetálek]

Hm, to měla být odpověď na původní dotaz.

[Hrabosh]

Super, to bych byl moc rád. Mailnul jsem Ti ...

[bazil]

mno tak pokud se ten převodník identifikuje ve win jako nějakej com port bo jak, tak se mu dá nastavit ve správci zařízení, v jeho vlastnostech na kartě port settings(česky to tu nemám) jeho flow control, což bude asi řízení toku ... máte to nastavené ? ... vím že asi jo, ale stejně se zeptám

[Hrabosh]

To nastavené mám. Jinak by to IMHO těžko naplnilo ten buffer dvakrát ...

[V/S/7]

Jediné co mě napadá k laborování je Latency Time. Je nastaven implicitně na 16ms. Dá se tam dát klidně 1ms. Používáme také drivery verze 1.00.xx .S novějšími byli nějaké problémy.

[Hrabosh]

Ta nastevení jsem před chvílí objevil. Zkoušel jsem nastavovat Latency timer i buffery, ale nikdy to nefungovalo dobře. Nicméně se mi povedlo dosáhnout toho, že Wind. tomu zařízení poslaly víc dat, ale zase zpřeházeně (resp. vynechané řádky), takže to malovalo kraviny.

V Linuxu jsou výchozí hodnoty různých timerů a bufferů stejné ? A jsou nekde uloženy, nebo bych je musel vytáhnout ze zdrojáku ?

[V/S/7]

Používám pro komunikaci komponentu pro C++ Builder(6.0 a starší) a hw nebo žádné řízení toku dat. V případě nouze můžu poslat. Pro linux jsem pro FTDI zatím nic neprogramoval.

[KKL]

Ahoj, o plottrech nemam prehled. Mozna je to nastavenim com portu ve windows ? Otevri si spravce zarizeni, porty com & lpt, vyber ten na kterym to mas pripojeny , vlastnosti, nastaveni portu. Rizeni toku je obvykle na zadne, pripadne hardware, zkus tedy nastavit xon/xoff . Pokud mas nejaky vlastni ovladac, ktery vypada jinak tak na tento prispevek zapomen :) Jak rikam, nikdy jsem to nevidel.