Domaci automatizace

[turby@chips.cz]

Zdravim,
 
 ja myslim, ze jakakoli centralizovana omezeni jsou k nicemu. je treba
 jen definovat parametry "ovladacu". to jak budou jednotlive ovladace
 (komponent) fungovat, na jakem hw budou komponenty postaveny ci v cem
 budou psany ovladace je naprosto irelevantni. jedine co musim vedet
 je co tam poslat aby to udelalo co ma a co mi to pripadne vrati.
 jestli nakonec bude povel ci data preneseny vzduchem ci po drate je
 myslim fuk a je na kazdem at zvoli fizickou vrstvu jakou chce.
 Komunikacni modul muze byt jak samostany hw tak i jen "ovladac" pro
 dany typ kontroleru ktery ma periferii na sobe.

 HW1<->KOM_MODUL_RS232<----->KOM_MODUL_RS232<->HW2
 HW1<->KOM_MODUL_RS433<----->KOM_MODUL_RS433<->HW2
 HW1<->KOM_MODUL_RF433<----->KOM_MODUL_RF433<->HW2
 HW1<->KOM_MODUL_CAN<--------->KOM_MODUL_CAN<->HW2
 atd...

 Podstatou je preci jen vzajemna schopnost komunikace. Nikdo z nas
 netusi, jaky vyrobce za rok zkrachuje a jaky protokol zmizi za dva
 roky na smetisti dejin nebo jaky novy, levny a uzasny se za pul roku
 zjevi.
 
--   
 turby@chips.cz

11. května 2005, 10:43:52, napsal jste:
 
>>Tim, ze vyradite rodinu PIC, ale i AVR, eZ8 a dalsi se vystavujete znacnemu
> nebezpeci, ze mnoho lidi od toho da ruce pryc:((((.
>>Naopak by se melo postupovat naproasto opacne.

> Kohokoliv vyrazovat nebylo mim umyslem, otevrenost standartu musi byt
> zaklad, ale stejne tak je treba zacit s nejakym konktetnim hw a zmeho
> pohledu se jako nejvhodnejsi jevi rodina x51 pro svou rozsirenost a
> nenavazanost na jednoho vyrobce. Jeste uvazuji o AVR, ale to je v soucasne
> fazi relativne nedulezite.

> Jak se zda nejsou vetsi namitky proti fyzicke vrstve komunikacniho kanalu a
> to RS485. Popravde tezko vymyslime neco lepsiho co by bylo  stejne snadno a
> levne realizovatelne. Padl zde navrh na rozdelovani site na subsite, jiste
> to je jedna z moznosti, ale z meho pohledu se tim vyrazdne zeslozituje a
> zneprehlednuje cela struktura a nevidim nic co by to jednoznacne vyvazovalo.
> Pri pouziti vhodneho budice RS-485 lze na jednu sbernici umistit 256 nodu a
> to by melo byt vice nez dost i pro Karlstejn vcetne rizeni hladomorny :-).

> Domnivam se, ze hlavni otazkou nyni je nalezeni dalsi vrstvy komunikace a to
> je komunikacni protokol. Lze zacit stavet na zelene louce, ale  osobne bych
> sahl po necem hotovem k cemu existuje dokumentace a nejake hotove sw
> nastroje (analyzatory protokolu, knihovny pro PC nerku-li MCU ). Svou prvni
> automatizaci jsem stavel na orezanem S.N.A.P protokolu
> http://www.hth.com/snap/ , ale nejak se prestal vyvijet. 


> 1. Existuje nejaky "hotovy" protokol vhodny pro tuto aplikaci ?
> 2. Jak by melo vypadat komunikacni schema Master-Slave, Multimaster ? Dle
> meho nazoru by u tohoto typu aplikace kde je pozadovana rock-solid stabilita
> a blbuvzdornost mel byt pouzit model Master- Slave, kde nadrizene zarizeni
> ridici celou automatizaci postupne oslovuje jednotlive slave zarizeni. Je to
> jednoduche, nekolizni, kdyz je nejhur staci vypnout mastra a sit se rozpadne
> na jednotlive izolovane ostrovy, ktere toho moc neumi, ale v dome se sviti,
> topi a chova se jako bezny dum bez inteligence. Pripoustim ma to radu
> nevyhod, priklad modul svetel se bez mastra nedozvi od meteo modulu zda uz
> je tma  
> 3. Jak resit sw pro hlavni ridici jednotku, nerkuli zda je vhodnejsi
> compilovany nebo interpretovany jazyk je v teto fazi mene dulezite, ale jak
> uz jsem psal i jako priznivec C/C++ C# nemohu nevidet znacne vyhody
> interpretovanych jazyku v techto modularnich aplikacich.


> Hlavni otazkou je zda lze najit nejaky vhodny, jednoduchy a otevreny
> komunikacni protokol ?



> P.S. Myslenka na upgrade fw pres komunikacni sbernici je lakava, ale priznam
> se , ze z toho mam tak trochu strach a nedovedu si to zcela predstavit.









> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list