Köszönöm, így már világosabb.

Idézet:
?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??

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:

RS485-nél nem oldható meg, mert csak 1 master lehet a buszon. Tehát egy Input modul nem dönthet úgy, hogy változott a bemenetem és küldök a masternek egy adatot.

De végülis az első szakaszban megválaszoltad, hogy a can multimaster.

A másik kérdés, hogy mennyi adat lehet egy csomagban?

Iletve még arra gondoltam, hogy ha multimaster rendszerű a busz akkor honnan tudom, hogy mennyi adat fog elférni. Tehát mondjuk előfordulhat, hogy a legkisebb ID-jű modul soha nem fog szóhoz jutni nagy adatforgalom esetén?

Ja és talán a legfontosabb, a can bust ipari környezetben mivel szokás védeni?
RS-485 nél voltak a TLV diódák, vagy szupresszor, vagy Zéner páros, ill. soros ellenállás.

Azt hiszem rendelek néhány pic-et CAN hw-val, meg illesztőt és nekiállok gyötörni. Igazából van itthol mcp2515 de azt még sosem tudtam működésre bírni, a kódok is inkább a 2510-hez vannak.

Elnézést az értetlenkedésért, de van súlya a dolognak, nem szeretek vakrepülésbe valamit beépíteni. Szeretem tudni, hogy mit csinálok.

Üdv!

Igen, bocsánat, saját magamnak mondtam ellent néhány mondattal lejjebb. Így van, ha egy rendszer nem multimaster, akkor összeakad(hat)nak a bitek, ezért nem lehet megvalósítani az "akkor küldök, amikor épp nekem tetszik" módszert.

A CAN olyan, mint az Open Collectoros kimenetek egy közös felhúzó ellenállással (pl. I2C). Ha valaki nullába viszi a buszt (nyitja a tranzisztorát), akkor mindenki nullát fog látni, hiába van a többi tranzisztora zárva. Tehát az győzött, aki nullás bitet tett ki a buszra. Ebből következik, hogy a kisebb ID-jű eszköznek van nagyobb prioritása (hiszen az ő ID-jében előbb-utóbb nullás bit lesz ott ahol a másiknak 1-es lesz a bitje). Aki győzött, az kilépteti a többi bitet, aki vesztett, az csendben marad, amíg nem megy ki a teljes csomag. Viszont csomagvesztés ütközés miatt nincs !

Persze ez csak akkor számít, ha egy időben kezdik el a bitek kiadását a buszra. Ha már tart egy csomag küldése, akkor azt már nem lehet félbeszakítani.

0..8 byte lehet egy csomag. Persze ha több kell, akkor valamilyen módszerrel össze kell fűzni őket. A CanOpen is ezt csinálja.

Hogy előfordulhat e olyan, hogy a legnagyobb ID-jű eszköz soha nem jut szóhoz nagy forgalom esetén ? Ezt nem tudom, de szerintem előfordulhat ilyen.

Ugyanazok a védelmi módszerek jók, mint RS485-nél. Vannak CAN-re való TVS-ek is. Tapasztalatom szerint az MCP2551 ugyanabban a környezetben kevésbé strapabíró, mint a PCA82C250, ez utóbbi szinte mindent kibír.

Imi.

Parancsolj:
http://www.vector.com/vi_canoe_en.html
Van egy C-szeru szkriptnyelve, ugy hivjak hogy CAPL, abban tudod a szimulaciokat megirni:
http://www.vector.com/portal/medien/vector_cantech/faq/ProgrammingW...PL.pdf

"Hogy előfordulhat e olyan, hogy a legnagyobb ID-jű eszköz soha nem jut szóhoz nagy forgalom esetén ?"

Nem.
http://www.softing.com/home/en/industrial-automation/products/can-b...010314

Üdv!

Egy állásinterjúra kaptam egy CAN protokolltervezési mintapéldát.

Lényege:
Egy CAN buszra több Applikations-SG és egy HMI-SG van felfűzve. Applikations-SG -n egy alkalmazás fut. HMI-SG: a gépkocsivezetővel való kapcsolatot biztosítja (ez egy kijelzőből és egy beviteli gombból áll)

Mindegyik Applikations-SG -nek a HMI-SG -t kell a vezetővel való kapcsolathoz használnia.

Feladat:

Tervezni kell egy CAN alapú protokoll ?t, amely lehetővé teszi az Applikations-SG kvázi egyidejű kommunikációját a HMI-SG -vel, valamint a HMI-SG -re való hozzáférést szabályozza (egy időben mindig csak egy Applikations-SG kérésélt lehet feldolgozni).

CAN Protokolltervezés alatt mire gondolhatnak? Én első körben egy szoftveres folyamatábrára gondoltam, ami kb. leírná a kommunikációt. Talán ide tartozna még a STANDARD mód estén 11 bites ID mező megtervezése. Pl. :
Motor hőmérséklet: 001 0000 0001
Akkumulátor töltöttsége: 001 0010 0101

Ki mire gondolna még?

Protokollt nem kell tervezned, a CAN maga a protokoll. Definialnod kell a kommunikaciohoz szukseges telegrammokat, es a kommunikacio menetet UML-szekvenciadiagrammokban. Ehhez viszont kene egy specifikacio, hogy milyen funkciokat akarsz vezerelni a kezelofeluleten keresztul.

Kicsit ugy hangzik ez a feladatleiras, mintha a HR-s forditotta volna nemetrol, de nem teljesen ertette volna meg. Zavaros.

Sziasztok !
Nem vagyok jártas nagyon ebben a technikában,de kérdeznék ..
Adott egy állófűtés ami csn-busra volt felfűzve egy vw T5 autóban .
A régebbi fajta állófűtések egyszerűen indultak kellett neki egy +/- Táp meg egy +12v indítójel ,és indult.
Most itt van nálam ez a fűtés és nem tudok mit kezdeni vele .
Kérdésem ,megoldható-e hogy egy vwT5 -ös autóbol kiolvasni azt a can-bus jelet ami indítaná a kazánt ,és ezt jelet egy független panelon egy 12V -os jelre kiadná ?

Lehet kapni olyan kütyüt amit a CAN buszra csatlakoztatva monitorozza pc-n az adatokat.
De rengeteg egység akár több adress-szel kommunikál nagy sebességgel egymással akár ms frekvenciával, leírás nélkül nem fogod tudni ki kivel van.

Ez nem ilyen egyszeru, nem tudsz "jelet" levenni, egy CAN adapterrel fel kell venni a bekapcsolasi es kikapcsolasi szekvenciakat, majd visszafejteni az uzeneteket.

igen .és erre keresek occó hardveres megoldást

Olcso egyik sem lesz, a megoldasok vegso arai nagyban fuggenek attol, hogy mennyit er a munkaidod.

Ha nem sokat, akkor epits sajat interfeszt:
http://www.mictronics.de/projects/usb-can-bus/

Ha "csak" szoftvert akarsz irni:
https://www.olimex.com/Products/AVR/Development/AVR-CAN/

Ha normalis minosegu kulcsrakesz megoldas kell, egyertelmuen a Lawicel CANUSB a legjobb valasztas:
http://elmicro.com/de/canusb.html

köszönöm. még kutatgatok hátha ráakadok valami óccó kütyüre . építgetni nincs időm

Sziasztok!

Egy kis segítséget szeretnék kérni. Adott egy integrált vezérlésű léptetőmotor ami Can-Busz-on keresztül kommunikál (vagy nem).
Hogyan tudnám ellenőrizni egy kis cumóval, hogy ténylegesen folyik-e kommunikáció a kábelen?
Válaszokat előre is köszönöm.

Olyan logikai analizátor kell hozzá amin van "Protocol Analyser". Ha az utóbbi nincs benne csak a négyszög jeleket fogod látni. Ha van benne, akkor ő a protokolnak megfelelően a képernyőre számokat fog tenni.
Nekem pl ez van, totál USBEE kompatibilis, annak a driver-ét, és szoftverét használja:
Logic Analyser

Köszönöm a válaszodat.

Én valami ilyesmire gondoltam.

Nem érdekel, hogy milyen adatokat küld, csak az hogy küld-e adatokat.

A canbus-al az a baj, hogy minden vezérlő mindennel össze van kötve a két szál vezetékkel és mindenki küldi mindenkinek az adatokat azon a két szálon. Tehát a szervómotorod is megkap minden üzenetet, amit a többi vezérlő és végrehajtó is, de csak azt veszi figyelembe, ami neki szükséges. A legegyszerűbb jelvizsgálatra jó egy oszcilloszkóp is, de ezen tényleg csak annyit látsz, hogy van-e kommunikáció. Azt, hogy van-e olyan jel, amit a szervómotor fel tud dolgozni, illetve hogy értelmezi-e a vett jelet, azt nem lehet eldönteni.

Hello,
Valami ilyesmit keresnék én is.... Nevezetesen adott egy gép amelyen található néhány vezérlő amelyek állapotai/értékei egy monotiron jelennek meg.
Honnan tudom eldönteni, hogy a monitor rossz vagy a kábelezés? (egyelőre mélyebben nem kell, csak hogy küldjük-e a monitort javítani vagy máshol a baj...

Tehát erre a célra gyakorlatilag a lehető legegyszerűbb szkóp is elég lenne?

Ha csak a kábelezés hibáját akarod kizárni, hogy van-e valami jel, arra jó. De hogy milyen jelre kell reagálnia és azt megkapja-e azt senki nem fogja tudni megmondani, csak a gyártó.

Hasonló mint a szkóp, de logikai analizátornak hívják.
Szkópok közül amivel vizsgálni tudnád, az dupla időalapos, ez nem tartozik a legegyszerűbb szkóp kategóriába.

Hi Mesterek!
Tud valaki ajánlani valamilyen szakirodalmat a can busz hoz a nullától? Autó diagnosztika miatt érdekelne majd

Kezdetnek innen olvasgathatsz.

Az sem mindegy milyen processzoron szeretnéd csinálni.
PIC24, PIC32, dsPIC33, és STM32 Cortex-M3/M4 procikon tudok neked segíteni benne, ASM, és C-ben.

Sziasztok

CAN buszt szeretnék megvalósítani MCP2551 transceiverrel. Kérdésem, hogy CAN busz esetében az egyes eszközök között a földeléseket össze kell kötni? Nem találltam rá egyértelmű választ.
Köszönöm előre is.

Ha a potenciál egy , akkor nyugodtan , ha különbözik , akkor nem kéne.

Az autóban a vezérlők közös föld ponton vannak és a tápjuk is közös.

Sziasztok
A problémám a következő lenne. Van egy RCN210es rádió, ebben a rádióban a kulcs és a gomb világítás nem analóg hanem can buson megy. Ehhez van is egy kis emulátor amire csatlakozik a világítás és a kulcs jele azokat can üzenetként küldi a rádiónak. Ezt az emulátort összekötve a rádióval működik is.
Nos egy ilyen emulátort szeretnék csinálni arduinoval, van hozzá egy can bus modul (mcp2515, tja1051).
Első körben egy can üzenet loggert töltöttem fel az fogadja is szépen az adatokat a can emulátorrol, így látom hogy az miket küld a rádiónak. sebesség 100kb/s, ismétlés 200ms üzenetenként.
a gomb világítás ID 635 60, 60, 0, 0
AC key ID 575 7, 0, 0, 0
Ezeket az adatokat egy exelből is ellenőriztem amibe össze vannak gyüjtve, stimmelnek.
Ha már tudom hogy mit kell kiküldeni a rádiónak töltöttem az arduinora egy küldő progit, összeköt a rádióval, de semmi a gombok továbbra is sötétek.
Ami érdekes hogy mértem feszültségeket, a rádió canH 0,3V körül a canL 4,7V érdekes hogy miért fordítva van az alacsony a magasabb, az emulátro szintén hasonló feszültségeket mutat, a can modul viszont más canL 1,7V canH 3,3V, próbáltam 120ohm lezáró ellenállásal, anélkül de úgy sem jó.
Valakinek valami ötlet mi lehet a gond?

Nekem régebben egy tanfolyamon azt mondták, hogy a CAN HI és a CAN LO között minimum 2V feszültségnek lenni kell különben nem biztos. hogy működni fog minden. Hangsúlyozom ez régen volt és erőgépeknél! ...

Elírtam a can modulban tja1050 van. a rádióban tja1055. mind 2 vezérlőnél a blokkséma alapján a can H egy fettel a + tápra megy, a can L pedig a negatívra, tehát a can L nem tudom hogy a fenébe lehet magas.

Erre a hibára oscilloscoppal lehetne rájönni a legkonyebben.
Ha nincs forgalom a CAN-en, akkor a CAN-H és CAN-L 2,5V-nak kell lennie.
Innen indul el a jel 5V irányába, illetve GND-re.
Szokott lenni CAN-GND és CAN-shield vezeték is.
Jó lenne tudni, hogy a jeleket mihez képest méred és össze vannak-e földelve.
Hogy kell-e a 120 Ohm, az attól függ, hogy hogyan vannak felfűzve az eszközök a busra.
Ha egy működő hállózatra állsz rá, akkor nem kell.
Ha csak két eszköz van össze kötve, akkor mindkettőre kell.
Az általad küldött CAN jelet szintén vissza ellenőrizted azzal a monitorozó eszközöddel?
Amit küldesz az decimális adatnak néz ki. Lehet az eszköz pedig hexben küldi. Ez is lehet az oka, hogy nem működik.