Sziasztok, mivel nincs a CAN busszal kapcsolatban általános téma így ez lesz az. Nos az én kérdésem kimondottan CAN vezérlőkről szól. Csatoltam, 2 adatlapot. Egy kontrollert és egy transceivert. Az első kérdésem az lenne, hogy ha ezeket akarom használni egy kis elektromos gépjárműben, akkor a transceiverek prioritása hogyan fog megoszlani? Tehát egy controller és több egyforma transceiverről van szó. A transceiverek gondolom címzés alapján döntik el, hogy számukra melyik az érvényes adat. De a csatolt adatlapban található transceivert hogyan kell címezni? Az adatlapban nem találtam erre utalást. Vagy hogy is működik?

zia
Valamit félreértettél.
A CAN illesztők, nem döntik el melyik infó szól nekik és melyik nem.
Ezek kis túlzással csak szintillesztők
Szóvalminden adatot beküldenek a "hálózatra" TX és minden adatot leszednek ami ott folyik RX.
Az UART kapcsolaton neked kell eldöntened kinek szól az infó.
"At least 110 nodes can be connected" pedig nem a címezhetősége, hanem inkább a terhelhetősége.
sztm

Szia, én azt hittem hogy ő mindent elvégez. Így már értem. Akkor az a kontrollerek feladata. Viszont akkor ha csak rövid jelutak vannak max. 1m, akkor lehet hogy nem is kell bele CAN illesztő, vagy tegyek bele?

A fizikai réteget a mikrokontroller nem képes előállítani, így kell az illesztő. Egyébként biztosan kell a CAN kommunikáció? Olcsóbban kijönnél, ha pl. RS485/422 kommunikációt használnál. Ha mindenképpen CAN-re van szükség, érdemes a Microchip- nél is körülnézni, vannak kontrollerek, amelyek CAN vezérlő perifériával rendelkeznek, valamint illesztőket is gyártanak.

2 célom van: 1. tanulás 2. egyszerű bővíthetőség. Már nagyjából kezdem átlátni a dolgot. SJA1000-es kontrollert és hozzá TJA1054A jelű transceivereket fogok használni. A chipcadtől veszek 16F-es PIC-eket és írok egy általános progit, amely célspecifikáltan bővíthető. És a címeket mondjuk 5 I/O kivezetésen állítom be áthidalással. Így egyszerűen bővíthető és módosítható lesz a rendszer. A CAN kommunikációról elég sokat olvastam már és már kezdem érteni a működését. Bár ha tudtok program mintákat csatolni ehhez az nagyon jól jönne. (De ha nincs az sem vészes, mert nem olyan bonyolult a dolog.)

Nem csak a microchipnek, hanem mindegyik ismert mikrokontroller gyártónak van CAN perifériás chipje.
A CAN és az RS485/422 között alig van különbség. Hasonló az elv. Soros mindegyik (422 full duplex)
Elvileg a RS485/422 nagyobb távolságokat kibír alacsony sebességen
De ha 1m a max távolság, akkor még ezek sem kellenek.
Sima UART minden illesztés nélkül is bírja ezt.
Persze nem árt az árnyékolás.

Lehet fix jumperes címadás, de lehet dinamikus mint DHCP.

Tisztában vagyok vele, hogy CAN támogatás gyakorlatilag minden kontroller gyártónál van, de mivel azt is tudom, hogy bankimajki leginkább PIC-kel foglalkozik, így inkább azt javasoltam. A különbség annyi, hogy a CAN kialakítása valamivel drágább, nem biztos, hogy azt érdemes alkalmazni. A sima UART pont-pont típusú és nem busz, azzal valódi busz kommunikáció nem oldható meg (Tudom, trükközéssel azt is lehetne).

Üdv!

Feleslegesnek tartom külső SJA1000-es CAN kontroller-t használni szerintem. Szinte mindegyik mikrokontroller gyártónak van olyan terméke, amely integrálva tartalmazza a CAN perifériát is. És 100-200 forinttal drágább csak, így nem kell plusz NYÁK felület, nem kell a buszkommunikációval foglalkoznod, de ami talán a legfontosabb, az a sebesség: egy külső párhuzamos (pl. SJA1000) vagy soros SPI (MCP2515) eszközzel akármit is csinálsz a csomag feldolgozási és küldési képességed lassabb lesz, mintha az integrált CAN-t használnád. Vannak olyan mikrokontrollerek, amelyekben olyan CAN található, amely tud bootloader is lenni, így képes vagy CAN-ről frissíteni az alkalmazásodat. Szóval javaslom, ha van egy problémára integrált periféria, akkor használjuk azt, ha nincs, akkor lehet keresgélni.

Imi.

Szia 16F szériás PIC-kel akarom első körben elláttatni a fő kontroller hatáskörét. És ha azzal már jól működik, akkor kap valami kisebb PC szerű dolgot. (De az még a szponzoroktól is függ. ) És nem is rohannék ennyire előre. Elsőnek alapszinten működjön a dolog. Majd utána lehet variálni.

Legalább PIC18 vagy PIC24. De legelőször olvasni, olvasni, olvasni!
Bővebben: Link, Link2, Link3

Szia, általában olvasok mielőtt kérdezek.
És azért 16F szériás PIC, mert azokat még nagyjából ismerem. Ha komolyabb kell, akkor nem PIC lesz, hanem P8X32A vagy valami ARM architechnikájú. Nem szeretnék továbblépni a PIC-ek listáján, mivel nincs túl sok haszna számomra. (Apróbb dolgokhoz pedig a 16F megfelel.) A jármű komolyabb vezérléséhez pedig ha a 16F kevés, akkor a 18F és attól komolyabbak sem sokkal jobbak. Inkább veszek egy NI-os cRIO-t és labviewban programozom. És azzal már igen komoly dolgokat meg lehet csinálni. Emiatt kell a külső CAN kontroller is, mivel így könnyen cserélhető a vezérlés fő része. És könnyen adaptálható bele szinte bármi.

Sziasztok!

Tudna valaki adni egy leírás (magyar nyelven lenne a legjobb de az angol sem akadály) amiben minden le van írva a CAN és az ECAN buszokról?

Előre is köszi!

Ha 16F-es PIC-el kezdesz, akkor nem tudod kihasználni a hardveres CAN-t, mivel nincs is benne. SW-ből a küldést meg lehet oldani, de a fogadása már sokkal bonyolultabb, mint pl. egy C-ben megírt 18F CAN rutin.
Erősen javasolt a 18F sorozat vagy felette.
Ha csak a kommunikációt teszteled, arra tökéletes. Ha olyan célod van vele, hogy egy konkrét autóból akarsz CAN-en keresztül adatokat lekérni, akkor ismerni kell az adott autó CAN adatbázisát. Ebben vannak eltárolva az ID-k, mi hány byte-os, illetve milyen időközönként kell kiküldeni, CAN ramp-ek stb.

Szia, fogalmazzunk úgy hogy én építek egy komplett járművet. (És csak teszt lesz a 16F szériával.) Már eléggé a P8X32A felé tartok végleges verzióban, mivel rengeteg dolgot képes párhuzamosan ellátni és az ára sem vészes.

Üdv.: Miki

Szia, itt a lényeg le van írva: Bővebben: Link Amennyiben kevésnek találod az anyagot, akkor van még pár .pdf kit. fájlom, amelyekben a CAN-ről van szó. De sokkal többet azokból sem tudsz meg.
A linken a tudásbázis menüpontot nyisd meg és ott lesz a CAN.
Üdv.: Miki

Üdv Mindenkinek!

Az MCP2551-es CAN illesztő adatlapján fel van tüntetve, hogy használható 12V és 24V-os rendszerekben. De hogyan lehet az IC 5V-os kimenetét előfeszíteni mondjuk 12V-ra?

Sziasztok!

Adott egy CAN-buszos hálózat. 15-20db interfészszel, melyekre különféle szenzorok/távadók csatlakoznak.
Az buszon érkező adatok kiértékelését, naplózását egy windows alatt futó szoftver végzi.

Szimulálni szeretném a buszon lévő adatokat a szoftver számára (a valós interfészek fizikai címével és a távadókról érkező adatokkal). Valamilyen szoftveres megoldásra gondoltam, ahol meg lehetne adni az adott interfész fizikai címét és a távadóktól érkező jelet pl. 4-20mA-t, ami aztán felkerül a buszra adatcsomag formájában.
Milyen megoldás létezik erre?

A segítséget előre is köszönöm!

Köszönöm!

CANoe SW és PCMCI kártya.
Elég borsos az ára.

Szia!

Esetleg van gyakorlati tapasztalatod is a CANoe programmal?
Esetleg küldenél linkeket?
Köszi!

Sziasztok!

A CAN busz fizikai rétegéről szeretnék kérdezni. A Microchip illesztőit használom, és egy modellvasúti rendszer vezérlését kéne megoldani vele. A mikrovezérlők a pálya mentén a vezérlendő objektumok közelében vannak elhelyezve. A kérdésem az lenne, hogy a CAN busz mekkora kiágazásokat bír el (mert elméletileg ha jól tudom egyetlen kábelpárra kéne felfűzni az összes egységet) és fog e működni, ha kiágazást alakítok ki?

Segítségeteket előre is köszönöm!

Üdv!

Sebességfüggő, ezt STUB-nak hívják, 1MBit-nél 30cm-nél nem lehet nagyobb.

Egyszer véletlenül nálam 20 méter volt, a sebesség 20kbps volt, de nem működött.

Imi.

Szia, ezeket az adatokat honnét vetted? Milyen illesztőt használtál? Mivel már nagyon sok szakirodalmat olvastam, de nem találtam konkrét értékeket. Az első állításoddal nyögvenyelősen de egyetértek. Bár jövőhéten megyek CAN mérésre és majd a kíváncsiság kedvéért lemérem nagyobb jelutakkal is a max. sebességet. De a másodikkal nem. Iparban rengeteg helyen használják. És ennél nagyobb sebességekkel is.

Üdv.: Miki

Üdv!

Tapasztalat alapján. MCP2551 és PCA82C250.

Mit használnak rengetegen ? A 20 méter leágazást ? Az érdekes lenne. Oda kell vinni a kábelt a NYÁK-hoz, ott bekötni a sorkapocsba, és ugyanonnan vinni tovább a kábel elmenő részét. Így a STUB mindössze a NYÁK-on lévő sorkapocsból a NYÁK-on lévő CAN illesztőig terjedő út, ami jó NYÁK terv esetén 5-20 mm.

Imi.

Pl. Liftekben, vezérlésekben. Ahol azért 10m-ek előfordulnak. Bár még csak kívülről láttam ilyeneket, tehát annyit tudok hogy CAN szabvány, hogy milyen illesztő és milyen sebességgel azt nem tudom pontosan, de majd előadáson rákérdezek. Ill. gépjárművekben is igen nagy távolságok lehetnek. És gondolom hogy több, mint 20kbps-mal tolják. (Mert akkor igen csak belassulna a rendszer.)

Üdv.: Miki

Üdv!

Szerintem félreértjük egymást. Lásd mellékelt kép.
De az is lehet, hogy én értettem félre tmarcell hozzászólását.

Szóval én a képen Ld-vel (Drop Length) jelölt hosszt neveztem STUB-nak. Na ezt minimalizálni kell, mert különben a reflexiók miatt összeomlik. Szerintem te az Lt (Trunk Length)-ről beszélsz. Ha a STUB-okat sikerül minimalizálni (mind hosszban, mind darabszámban), akkor az Lt lehet 1200 méter is 20kbps-en. Ha a STUB-okból sok van, és azok hosszúak, akkor baj van.

Imi.

Rendben jól gondolod. Én nem így gondoltam.

Üdv.: Miki

Én az Ld-vel jelölt hosszra gondoltam.

Üdv!

Örülök a topic-nak, mert így nem kell minden CAN-es kérdésnek újat nyitogatni.

Szóval én eddig RS485-RS422 használtam és nagyon meg voltam elégedve vele, mert igen mostoha körülmények között is jól működnek.

Egyre gyakrabban belefutok olyan alkalmazásokba, ahol rengeteg az IO igény, és ez RS485 -nel már egyre nehézkesebb megvalósítani. (Lekérdez-válaszol).

Ezért gondolkodtam el, hogy mi lenne, ha CAN-ra váltanék, de éles projektben ezt nem mertem megtenni, mert annyira nem ismerem a CAN-t.

Tehát a kérdésem az lenne, hogy alkalmas- e ez a CAN-busz kiváltani az RS485-t?

Illetve CAN-nál megoldható -e az hogy mondjuk a bemeneteket nem kérdezem le folyamatosan, hanem ha állapotváltás történik, akkor kérés nélkül elküldik az új állapotot a feldolgozó egységnek?

Továbbá engem zavarba ejt az a kismillió regiszter amiket be kell konfigolni egy can modulban.

A pl a maszkok, szűrők. Nekem az lenne az igazi, ha a CAN tudna úgy működni, hogy én a saját magam által kitalált PACKET-et átküldi A-ból B-be, majd én eldöntöm, hogy kinek szólt az üzenet.
Van -e erre itt lehetőség?
Vagy eleve rosszul gondolkodok?

Szóval örülnék, neki, ha esetleg e téren tapasztalattal rendelkezők megosztanák velem(velünk) tapasztalataikat. Mondjuk RS485 VS CAN összehasonlításban.

Igazából itt a mikrovezérlős CAN-ra gondolok, tehát az nem sokat segít, hogy mondjuk egy SIEMENS PLC milyen jól működik ipari környezetben a ráaggatott CAN egységekkel stb. mert azt tudjuk.

Válaszokat előre is köszönöm, ebből talán megtudom, hogy érdemes e átállni, CAN-re.

Üdv!



Ugye az RS485 alapból nem multimaster. Vagyis ha valaki kitesz egy bitet a buszra, majd ebben az időben valaki más is kitesz egy ellentétes bitet a buszra, akkor valakinek a bitje elveszik. Tehát vagy használsz valamilyen SW-es algoritmust ennek detektálására vagy ott a TIA 1939 vagy J1708. Ha ilyened nincs, akkor a lekérdez-várom a választ-megjött a válasz-lekérdezés a másik eszköznek, stb hurok. A CAN alapból multimaster méghozzá HW-ből, tehát bárki, bármikor kitehet csomagot a buszra, ha ütközés van, a kisebb ID-jű csomag győz (és nem veszik el, az ethernetnél ugye elveszik), a másik csak a csomag után próbálkozik újra. És ezzel neked nem kell foglalkoznod, mert a CAN kontroller (a mikrokontrollerben lévő CAN IP vagy MCP2515 vagy SJA1000) megoldja ezt. Tehát itt már van egy óriási előnyöd, akkor is ha maradsz a "lekérdez-válaszol" módszernél, hiszen a master egymás után kiküldheti az összes slave lekérdező parancsot, nem kell megvárnia az elsőre a választ. Ha elment az összes lekérdezés, akkor várhat a válaszokra. Ez önmagában sokkal gyorsabb mint az egy kérés - egy válasz módszer.



Ez az RS485-nél miért nem oldható meg ? Ebben az esetben ugyanaz a 3 probléma létezik CAN-él is, mint RS485-nél:

1. mikor elindul a slave, akkor el kell küldenie az aktuális állapotát, hiszen a master nem feltételezheti, hogy a slave éppen 0-ban vagy 1-ben van

2. üzem közben minden változáskor küldeni kell csomagot az aktuális állapotról

3. a masternek valahogy tudnia kell, hogy a slave meghalt, kikapcsolták, stb. Azt javaslom, hogy adott időközönként (mondjuk néhány sec) a slave mindenképp küldjön csomagot, ha van változás, ha nincs. A master pedig ezt egy watchdog-al figyeli.

Tehát ez a probléma nem CAN vagy RS485 specifikus.



A CAN buszon nincs olyan, hogy cím. ID van, de az nincs előírva, hogy ezt mire kell használni. Lehet címnek, vagy valami másnak.

Az általam használt rendszernél voltak Digital Output egységek, ezek ID-je:
slave cím + 0 lekérdezésnél
slave cím + 128 válasznál

Digital Input egységek, ezek ID-je:
slave cím + 256 lekérdezésnél
slave cím + 384 válasznál

Analóg Input egységek, ezek ID-je:
slave cím + 512 lekérdezésnél
slave cím + 768 válasznál

stb.

volt.

A slave címet DIP kapcsolóval lehetett állítani. Tehát lehetne 5-ös sorszámú DO és 5-ös sorszámú AI is, nincs keveredés.

A CanOpen máshogy van, ott az ID:
0x600 + node ID lekérdezésnél és 0x580 + node ID válasznál. Ennyit használ mindössue az ID-ből semmi mást. Minden más adat magában a csomagban van benne.

Imi.