Szóval akkor van egy DC motor, ami x irányban mozgat, ennek vezérlése oké. Aztán van egy másik, léptetőmotor, ami y irányban mozog, 256 lépésből.
Elvesztettem a fonalat, szóval miért nem jó a delay?

Igen, XY irány. A dc motor jobbra(); ballra(); mozgat, az sima ügy.

De van a léptető motor ami 256 lépéssel le(); és fel(); kell hogy mozogjon. A delay jó volt eddig. De kapott végállás kapcsolót a szerkezet az RA1 inputra. Bármelyik oldalhoz hozzáér le kell mennie egy tárgyért és felvennie úgy, hogy leállítja a jobbra balra irányt míg felveszi. Ennek az érzékelése nem jó, mert a sok delay késlelteti a programot. Így össze vissza megy. :S

Erre a problémára keresnék megoldást.

BEÜLTETŐGÉP MOTOR VEZÉRLÉS

Amit kapott végállás kapcsolót, az azt nézi, hogy jobb/bal oldalt van (tehát teljesen végigment)?

Igen!

Hát kiadod feszt a DC motorra, míg nem kapsz jelet a végállástól. Ekkor leállítod, és elindítod a léptetőmotoros ciklust (le-fel). Aztán megint adsz a DC motornak feszkót, hogy a másik irányba menjen. És így tovább. Nem értem, hol jön be a delayos probléma.
Szerk.: vagy hamarabb akarod leengedni a kart, minthogy a végére érne?

Akkor nem érted amit írtam. Nem tudnak egymásról hogy hányan vannak és nincs sorszámuk sem. Azért nincs sorszámuk mert akkor minden egyes példányba más szoftvert kellene égetnem. Azért nem lehet menüből (vagy akárhogy) sorszámot beállítani mert mi van ha két ugyan olyan sorszámút állít be az user. Persze, ezt is le lehet biztos kezelni de ez bonyolult(abb). Nem lehet azt sem hogy van egy mester és ő adja az 500ms-os jelet mert mi van ha az user két mestert állít be. Egyébként az 500ms nagyon kritikus, azt mindenképp a PIC-ek saját maguknak intézik. Azért, mert a hajszál pontos 500ms-nak nagyon fontos szerepe van a mintavételezésben. Konkrétan a fogyasztás-mérés miatt rendkívül fontos a pontos fél másodperc.

Igen, minden panelmérő több bájtot küld. Említettem is hogy kb 30-at, mert elküldi a feszültséget, az áramot és a teljesítményt, de ezek két bájtosak. Azaz eddig hat bájt. Plusz mind a három jellemzőhöz kell még egy-egy bájt ami a méréshatárt tartalmazza hogy az adott érték milyen méréshatárban értendő. És mindez ugye négyszer (saját, mögöttes, kettővel mögötte lévő és hárommal mögötte lévő), azaz összesen 36 bájt. Plusz lesz még pár speciális bájt ami most a jelen téma tekintetében nem fontos.

De ha mindegyik 500ms-ként küld, akkor abból gabalyodás lesz. Ha egyszerre adnak, akkor meg megint nem jó. Ha egymás után, akkor nem lehet eldönteni, hogy melyik kitől érkezett.
Egyelőre passzolom.

Jól mondod Ez így jó, de! ott jön be a delay probléma, hogy amíg ez a szerencsétlen szerkezet megküldi a motort izomból - az érzékelő érzékeli hogy jobb vagy bal oldalt van - és mivel visszapattan az érzékelőtől a kocsi, (akkora erővel megy) már küldi is vissza balra, azaz küldené, de fut még a fel le ciklus, abba a delay, jah és amíg a delay megy addig az érzékelőről a jelet se olvassa, így aztán úgy megőrül az egész hogy csak na.
Erre jöttek, hogy csináljam meg interrupt meg timer segítségével. Jó, oké, indítgatom az időzítőt meg le is állítgatom, de ettől még a léptető motor amiben a delay dolgozik nem fog menni, mert hogy innentől már nincs delay, csak interrupt. De akkor a léptetések közé hogy szúrok be késleltetést? ... Ajj... szerintem ez nehéz ügy. Nem olyan egyszerű mint ahogy gondoltam.

Ahogy írtad te is, önmagában a feladat egyszerű. De kivitelezni nagyon nehéz szerintem. Valakinek ez egy perc lenne itt megírni, nekem órák vagy napok. Ezért kérnék segítséget. Ötletet. Konkrétumokat.

Szóval az a baj, hogy "visszapattan" x tengelyen?
Szerk.: vagyis azt akarod elkerülni, hogy visszapattanjon?

Na akkor lekamerázom, hogy a jelenlegi programmal mi a problémám és felteszem a programot. Egy pár perc múlva...

Lényegében a visszapattanás okoz egy problémát. Mert leáll a szerkezet a végállásnál de visszapattan a gyorsaság miatt és már egy picivel arrébb teszi. Ezért már tettem bele egy PWM részt is, és mielőtt elérné a végét lelassítom a szerkezetet egész lassúra majd rajtahagyok egy kis nyomatékot a motoron, hogy szorítsa jobb/bal oldalra a kocsit... Így a motoron lesz egy kis áram. Na így már nem pattan vissza, de megőrül az input :S

De mutatom inkább és akkor érthető lesz minden.

Arra nagyon kicsi az esély hogy egy panelmérő egyszerre ad és vesz is. De nem történik semmi probléma mert az adás nem megszakításban történik hanem 500ms-onként mikor megvannak az új mérési eredmények. Elkezd adni a PIC, közben lehet hogy épp pont akkor kezd el érkezni is adat. Az viszont megszakításban van kezelve, szóval amint befejezte a vételt, folytatódik az adás. A következő PIC-et (amelyiknek ad) azt meg nem zavarja hogy adás közben két bájt közt most egy picit nagyobb szünet volt.

Azt pedig hogy melyik kitől érkezett, épp az általam felvázolt elvből eredően garantáltan tudni lehet! Mondom, az elsőnek érkezett adat a mögötte lévő panelmérőé, a második az az mögöttié, a harmadik az az mögöttié, a negyedik pedig az az mögöttié.

Hp41C, watt, _vl_!
Ti nagyon okos emberek vagytok, mit szóltok a dologhoz?

Világos, na majd kíváncsi vagyok, hogy fog menni ez a gyakorlatban.
Bár szerintem menni fog!
Szerk.: pff, én meg nem vagyok nagyon okos...
Bár valószínűleg simán megírják azt a megoldást, amit én órák alatt se bírtam kitalálni.

Köszi, bár ha így haladok a tanulással (lustaság :\ ), inkább buta leszek, mint okos.

Szia!
Ha jól értem, akkor gyűrűbe ( ringbe ) kötöd őket !? Akkor a masternek konfiguráltak indítsanak el egy üzenetet, amelyben egy véletlenszám is van . Aki veszi és nem master, az továbbadja, ha valaki master és a bekapcsolásnál az ő véletlenszáma nagyobb, akkor felülírja. Addig engedik körbe az üzenetet, míg az a master, aki a legnagyobb kódot "dobta" visszakapja a sajátját, addigra minden master fogja tudni, hogy ő lett-e a domináns! Ezután már csak ő kezdeményezhet! Ezek után elindít egy újabb kört ( de most már a többiek szolgák! ) :egy byte-ot, ami alapból nulla!. Ahogy halad körbe, minden egység megnöveli 1-el az értékét, így mire visszaér fogja tudni, hogy hány egysége van ( az egységek pedig megjegyezték, hogy ők a hanyas számúak!) !
Egy kicsit bonyolultnak tűnik, de a leírásod alapján ez jutott eszembe ...

A sorszámot, (illetve azt, hogy az illető master) bele lehetne tenni az EEPROMba.

Azt írta, hogy nem akar egyedi programozgatást ( vagy lehet automatikussá tenni ?!)!

Az EEPROM írása független a program beégetésétől.

Az input mitől őrül meg, mire gondoltál ?! A tehetetlenséget nem tudod könnyen legyőzni: ha adod neki a kakaót, akkor nagy a lendület és képes visszapattanni! A célt lassabban közelítsd meg, amikor már pl DC fékkel ( kivezetéseket rövidrezárod vagy ellenkező polaritást kapcsolsz rá! ) meg tudod fogni a motort, vagy ha erre nincs lehetőség, akkor jelzés hamarabb, hogy még a visszapattanásig meg tudd állítani!

Az igaz, csak akkor mindig neki kell egyesével állítgatni a címeket programozásnál ( mikor postázza eladásra --> dokumentálás! ), hogy ne legyen kettő egyforma! Nem beszélve arról, hogy pl. 1 byte-on ez csak 256 különböző cím és mi a biztosíték rá, hogy ennél nem fog többet eladni ( 2 vagy több byte-ot pedig nem akar áldozni az adatok küldésénél a címre ! ) !

Csak a masternél kell beállítani státuszt, a slave maradhat olyan, amilyen.

Üdv! Belebeszélhetek?
Tetszik az ötlet. Igazából két fő probléma van. Az eszközök egyértelmű felsorakoztatása indulásnál és a négynél kevesebb eszköz problémája (alapként négy eszközről beszéltünk)

Ha én csinálnám, akkor ezt a módszert használnám:
1234 2341 3412 4123
Ez azt jelenti, hogy a négy eszközhöz négy csomag tartozik, amit mindenki továbbküld. Ahhoz, hogy ne kelljen szinkronizáció, az szükséges, (ahogy írtad is) hogy minden eszköz A-nak tudja magát. Tehát elküldi a saját adatait az első helyen és a vett adatokat utána besorolva abban a sorrendben, ahogy jöttek. Innen kezdve, minden különösebb arbitráció nélkül, mindegyikük tudni fogja, hol áll a sorban. Vagyis a fogadó számára világos lesz. hogy a legelső csomag a szomszédé, a következő annak a szomszédjáé, stb. Egyfajta veremtár, ahol forgatják az adatokat.

Mivel a kijelzés szempontjából nem feltétlenül lényeges, hogy pontosan időzítse magát a mintavételezéssel, ez nem is zavarhat be. Tehát ha egy eszköz többször küld adatot, a vevő úgyis a maga tempójában küldi tovább, és amit küld, az a legfrissebb vett adat lesz, a többi max. elkallódik.

Az a probléma, hogy ez a verem módszer megcsúszik, ha kevesebb eszköz van a rendszerben. Három eszköznél ez lesz a vermekben:
1230 2301 3012 aztán 1123, ami nem jó. Persze lehet szoftverből trükközni. Pl. egy csomagvezérlő bájtot teszünk a saját csomaghoz, amit küldésnél inkrementálnak az eszközök. Négy lépésnél a saját csomaghoz tartozó eszköz bájtja 3, mert háromszor lökték tovább. Ha 2, akkor egyet kell lökni a vermen (1123>>1230), ha 1, akkor kettőt. Mert ugye csak ott keletkezik a hiba, ahol a verem először körbeér. Ilyenkor le kell nullázni a többi csomag vezérlőjét is, nehogy ők is korrigáljanak.
Ezt sokkal bonyolultabb leírni, mint leprogramozni.

Tehát akkor minden eszköz forgatja a vermet, felteszi a maga csomagját felülre, nullázza a saját vezérlőbájtját, egyet hozzáad a többiéhez. Ha hibát észlel, megoldja és kikapcsolja a hibajelzőt. Mindenki tud mindent, ütemezési hiba kiejtve, mindenhol lehet kijelző, amibe menüből beállítható, hogy mit jelezzen. Gondolom van adattípus-jelző a csomagokban, így pl. csak az U1-4 között kell választani, hogy milyen sorrendben jelenjen meg.
Szerintem ez a legegyszerűbb módszer.
(Már ha nem keveredtem bele valami álokoskodásba. Ez esetben bocs. Hónapok óta soros vonali arbitrációkon töröm a fejem és már kissé belecsavarodtam.)

Hehe Téged azért nem írtalak mert velük ellentétben te már kifejtetted a véleményedet.

A gyűrű (ring) topológia nekem személy szerint már régen se tetszett, amikor Token-Ringgel, meg hasonlókkal játszottam. Bármelyik kapcsolat hibája a teljes kommunikáció leállását jelenti, ugyanígy ha egyet kihúzol/elresetelsz, akkor megintcsak szétesik a gyűrű.
Személy szerint én bizony kijelölt mastert használnék (optimális esetben a bekábelezéssel lehetne kijelölni a mastert).
Lehetséges kommunikációs megoldások:
- több pont-pont soros összeköttetés (ha szoftveres adatátvitelt használsz, akkor ez nem is annyira fájdalmas, különben ugye kéne annyi UART, ahány kapcsolatod lesz),
- multiplexált pont-pont soros összeköttetés (itt ugye kell multiplexer és annak vezérlése a masterra, szóval nem tud teljesen egyforma lenni mindegyik panel, bár legfeljebb nem ültetsz be dolgokat a többin),
- multiplexált SPI (ide is kell valami multiplexer),
- multidrop I2C (itt mindent szoftverből lehet konfigurálni), ez itt azért lehet problémás, mert leválasztást is szeretnél.
Létezik ezen felül még RS485, CAN, Ethernet, amik ide már az ágyúval-verébre tipikus esete lenne, de dobozon kívüli kommunikációra jók.

Az az alapgondolatod, hogy spóroljunk a lábakkal, nekem is kedvenc mániám volt régen. Aztán rájöttem, hogy nem érdemes ezen erőlködni, ha kevés a láb, kell nézni nagyobb mikrokontrollert. Manapság ott tartunk, hogy hatalmas választék van, és könnyedén lehet szerezni a 28-lábas helyett picivel többért 40/44-lábast, vagy ha azt is kinőttük, vannak 48/64/100-lábú mikrokontrollerek is, nem életveszélyes pénzért. Ugyanígy a különféle hardver kommunikációs támogatás is hegyekben vannak a modernebb mikrokontrollerekben. 500ms alatt 30 byte-ot átküldeni, az minimum 1kbps-t jelent. Ez nagyjából a határán van annak, ami szoftverből értelmesen meg lehet/érdemes csinálni.

Na, éreztem, hogy valami nem stimmel.
Szóval kevesebb eszköznél nem tudja a vevő, hogy melyik az ő csomagja, nem is nézheti meg a saját vezérlőbájtját. Ehelyett mindenkiét meg kell néznie és megkeresni a legnagyobbat. Ha az nem 3, akkor kell lépnie.
Na így már talán jó.

Szia!

Igen, gyűrűbe lesznek kötve. Az első a másodikkal, a második a harmadikkal, a harmadik a negyedikkel, a negyedik pedig az elsővel.

Már nem jó. Írtam hogy nem lehet master és slave, mind egyenrangú. Sem a programjukban nem különböznek (nincs külön master és slave verzió), sem az user nem állít be mastert, és véletlenszám-generátor sem helyez előtérbe egységet. Azért, mert nem szeretnék külön szoftvert, mindenképp teljesen ugyan az a szoftver működjön az összes panelmérőben. Az user se állítgasson mert az emberi tényező ami tőlem (a programozótól) független és előfordulhat hogy véletlen vagy szándékosan több mastert állít be. A véletlenszám-generátorban pedig nem bízok, és az egyes áram alá helyezésekkor más-más sorrend lehetne ami nem jó. Vagy lehetne azt hogy az első bekapcsoláskor történik csak véletlenszám-generátorral valamiféle címkiosztás aztán azt mindenki eltárolja EEPROM-ban és utána már ugyan az maradna, de mi van ha az user később betesz még panelmérőt vagy elvesz, megcseréli a sorrendet stb. Ezt mind kivédem azzal hogy nincs master és slave. Mindenki egyenrangú és pontosan ugyan azt csinálja.

Hello! Köszi a válaszod, de azért ennyi eszem van, hogy fékezni kellene. Meg is tettem. Nézzétek akkor a problémát...

Beültető gép sok sok DELAY-el...

A jelenlegi kód a következő ami működteti a PIC18F252-est 16MHz kristállyal:

Igen, de így megint az van hogy minden egyes panelmérő példányba más szoftvert égetek. Csak nem a programmemória lesz más hanem az EEPROM tartalma.

A véletlenszám-generálós megoldás nem biztos, hogy elvetendő. Beégetés után először, amíg üres az EEPROM, generál magának egy szép hosszú (mondjuk legalább 32-bites) azonosítót.

Na, ha van ilyen program ami PICkit3-at kezel és úgy lehet vele programozni hogy minden égetéskor automatikusan inkrementál mondjuk két bájtot az EEPROM-ban (egyedi azonosító, gyári szám, sorszám vagy nevezzük bárminek) az nagyon érdekelne! Ha véletlen-számot generál és azt égeti az EEPROM-ba de megjegyzi hogy eddig miket égetett be és azokat a számokat a későbbiekben kihagyja az még jobb lenne.