Arduino's laten communiceren via can bus shields

[pascalboy]

Beste Tweakers

Ik probeer al geruime tijd 2 Arduino’s met elkaar te laten communiceren via een can bus shield, helaas alleen nog zonder succes. Ik heb hiervoor al diverse librarys geprobeerd waaronder deze:
https://github.com/Seeed-Studio/CAN_BUS_Shield

Op de eerste Arduino heb ik de example send/send_blink geupload en op de 2de Arduino heb ik de receive/ receive_blink geüpload. Helaas alleen zonder resultaat. De init gaat goed maar ik ontvang geen data. Op beide Arduino’s knipperen de TX/RX niet alleen branden deze heel zacht, terwijl de power van de shield wel vol brandt.

Ook weet ik inmiddels dat mijn cs pin 10 is, dus deze heb ik daar ook naar toe veranderd.

Heeft iemand nog enig idee hoe ik dit werkend zou kunnen krijgen?
Mijn uiteindelijke doel is om een aangepaste verzie van Railuino te kunnen gebruiken, want deze werkt nu niet met mijn com shield..


Relevante software en hardware die ik gebruik:
2x Arduino uno
2x SunFlower Can Shield V22
1x Serial Cable

[itcouldbeanyone]

Zit er wel een canbus termination op ?
Ofwel wanneer je systeem uit staat hoeveel Ohm meet ke tussen can Hi en can Low , dit zou 120ohm bijvoorbeeld moeten zijn.
Verder heb je ze op dezelfde baudrate staan ?

Vaak scheelt het ook als je de min van bijde arduinos ook met elkaar door verbind, de chip op de shield heeft naar mijn ervaring vaak moeite als er geen min is doorverbonden

[MewBie]

Controleer of je kabel geschikt is voor canbus,of je afsluitweerstanden hebt of aan staan, etc. Ik heb tijdens testen met plc's en canbus kleppen de meest rare dingen gezien en meestal kwam het door verkeerde instellingen, afsluitweerstanden of de kabel zelf.

[pascalboy]

Goedemorgen,

Als de arduino aan staat zonder enig script is de termination ongeveer 55ohm, voor de baudrate heb ik op bijde examples de 500KBPS gebruikt.

Hoe verbind ik precies de min van de arduino's? (welke min)


Voor de kabel heb ik een icidu kabel liggen, maar ik heb ook al geprobeert om de can_h can_l direct met een kabeltje te doen. Helaas werkte dat ook niet.

Bij deze nog een foto van de shield, mocht dat helpen:

[Lennyz]

Je geeft aan dat je de CS pin naar #10 hebt veranderd. Je hebt daar dus een hardware matige aanpassing aan gedaan? Want volgens de wiki site van Seedstudio is het veranderen van de CS pin in de software niet voldoende. Niet goed gelezen, dat is alleen voor als je de connector gebruikt.

Het is ook overbodig om te doen. Voor de CS pin maakt het niet uit of je pin #9 of pin #10 gebruikt. Die pin kan je vrij kiezen.

Probeer eens de modules op deze manier te connecten. Upload dan de standaard send/receive code en kijk of er iets gebeurd.



Hier is de wiki site:

http://wiki.seeed.cc/CAN-BUS_Shield_V1.2/

Met de min wordt de ground van de Arduino bedoelt. Je kunt dus even een jumper cable tussen een ground van de ene en de ground van de andere Arduino plaatsen.

[ Voor 16% gewijzigd door Lennyz op 28-05-2017 10:00 ]

[pascalboy]

Oke ik heb de kabels op die manier aangesloten, ook met en zonder ground. Maar helaas nog steeds ontvangt de 2de arduino niks van de ander. Bij de arduino die verstuurd brand de TX, RX, NT en bij de ontvanger brand de RX.

Als ik de CS pin op 9 zet inplaats van 10 faalt het script met initialiseren van de shield.

Tevens is de wiki die je doorstuurt van een compleet andere shield, ik weet niet of dit heel erg uit maakt.

[itcouldbeanyone]

stuur eens een paar foto's van je setup.

[pascalboy]

Bij deze de foto's,

De arduino met blauwe usb kabel heeft de send code, de zwarte de receive code.

[Vuikie]

CAN-bus is een differentieel signaal, daarbij heb je geen 0/gnd nodig, zoals bij rs232.

Ik denk toch dat het een software probleem is. De reden waarom ik dat zeg is, omdat de rx en tx tegelijk branden. Heb je de CAN-id's wel goed staan? Die mogen namelijk niet hetzelfde zijn. Ook zou ik controleren of je wel de juiste library gebruikt hebt.

[pascalboy]

Vuikie, heb jij misschien nog een library die er goed uit ziet?
Ik heb er al best veel geprobeerd met hetzelfde resultaat, alleen kan ik deze niet meer terug vinden aangezien ik dit al een paar maanden dit werkend probeer te krijgen.

Tevens was de ground genoemd in een eerder bericht, deze had ik ook eerst niet, met hetzelfde resultaat.

[Lennyz]

pascalboy schreef op zondag 28 mei 2017 @ 14:40:
Vuikie, heb jij misschien nog een library die er goed uit ziet?
Ik heb er al best veel geprobeerd met hetzelfde resultaat, alleen kan ik deze niet meer terug vinden aangezien ik dit al een paar maanden dit werkend probeer te krijgen.

Tevens was de ground genoemd in een eerder bericht, deze had ik ook eerst niet, met hetzelfde resultaat.

Die library van Seeed-studio is prima voor dit shield. Het is een clone van de Seeed-studio.

Welke examples gebruik je? "Send" en "Receive check"?

Hier is trouwens nog iemand die hetzelfde shield gebruikt en het niet werkend kreeg zonder hardwarematige aanpassingen:

http://osmar.gonzal.us/sunflower-can-shield-v2-issues/

[ Voor 12% gewijzigd door Lennyz op 28-05-2017 16:18 ]

[pascalboy]

Thanks voor de link! Eigenlijk wel vreemd dat deze maar 8.000 zijn, ik had een vorige van ebay die goedkoper was maar die wel 16.000 is. (heb ik een draaidje op laten vallen en toen arduino en shield doorgebrand )


Ik heb zojuist de 16.000 kristal besteld en zal dinsdag binnenkomen. Dus dinsdag meer...

[itcouldbeanyone]

Vuikie schreef op zondag 28 mei 2017 @ 14:28:
CAN-bus is een differentieel signaal, daarbij heb je geen 0/gnd nodig, zoals bij rs232.

Ik denk toch dat het een software probleem is. De reden waarom ik dat zeg is, omdat de rx en tx tegelijk branden. Heb je de CAN-id's wel goed staan? Die mogen namelijk niet hetzelfde zijn. Ook zou ik controleren of je wel de juiste library gebruikt hebt.

gnd doorverbinden is een veelvoorkomende probleem, en zeker bij de MCP2515 die hier op de shield gebruikt word.
tuurlijk het kan werken zonder, maar onder gunstige omstandigheden.

CAN-ids hetzelfde ? dat maakt helemaal niks uit. je kunt alleen moeilijk achterhalen wie er nog praat.

[Vuikie]

itcouldbeanyone schreef op zondag 28 mei 2017 @ 22:14:
[...]


gnd doorverbinden is een veelvoorkomende probleem, en zeker bij de MCP2515 die hier op de shield gebruikt word.
tuurlijk het kan werken zonder, maar onder gunstige omstandigheden.

Ehm, nee zoals ik al zei/schreef CAN-bus loopt over een differentieel signaal. Dit is speciaal ontworpen zodat je geen potentiaal nodig hebt. Terminatie van een CAN-bus gebeurt met 100ohm op lage snelheden en 120ohm op hoge snelheden. Deze 120ohm zorgt voor het differentieel. Dus gunstige omstandigheden of niet, de 0/gnd is gewoonweg niet nodig, net zo min als bij ethernet(Wat ook een differentieel signaal is )

CAN-ids hetzelfde ? dat maakt helemaal niks uit. je kunt alleen moeilijk achterhalen wie er nog praat.

Dit is reinste onzin. Het maakt in dit geval misschien niet uit(Ik heb even naar de voorbeelden gekeken) maar het meegeven van je CAN-ID is heel belangrijk binnen een CAN-bus (CAN = Controller Area Network) want het CAN-ID wordt gebruikt voor arbitrage voor welke node er een message op de bus mag zetten. CAN werkt ook door middel van het message passing principe. Normaliter laat je je applicatie luisteren naar de ID's waar jij naar wil luisteren. Dus als ID #1 iets op de bus zet en jij wil weten wat wat ID #1 te zeggen heeft, moet je wel zeker weten wat er op de bus staat ook echt van het apparaat komt waar jij naar wil luisteren.
Als je meerdere ID's #1 op de bus hebt, heb je dus kans dat ze tegelijk iets op de bus zetten en data verminking krijgt. En als dit al niet gebeurt dan is nog steeds niet gegarandeerd dat het bericht wat je op pikt de juiste is.

Ik raad dan ook aan om de wiki over CAN te lezen: Wikipedia: CAN bus
Misschien beter nog, de Bosch CAN specificatie 2.0: http://www.bosch-semicond...canliteratur/can2spec.pdf

@pascalboy Als je de controller te laag klokt dan heb je kans dat het niet goed gaat
Ik hoop voor je dat het omzetten naar 16MHZ het probleem verhelpt. In essentie is dit dus een software probleem(Uitgaand van 16MHZ ipv. 8MHZ)
Ik zie ook dat je J3 moet doorverbinden om gebruikt te kunnen maken van de interne 10ohm(???, ik vermoed 100/120ohm) zodat je de shield goed kan gebruiken.
Een gevalletje Chinese kwaliteit?

[ Voor 9% gewijzigd door Vuikie op 29-05-2017 09:28 ]

[carbidsjitter]

Vuikie schreef op maandag 29 mei 2017 @ 09:18:
[...]

Ehm, nee zoals ik al zei/schreef CAN-bus loopt over een differentieel signaal. Dit is speciaal ontworpen zodat je geen potentiaal nodig hebt. Terminatie van een CAN-bus gebeurt met 100ohm op lage snelheden en 120ohm op hoge snelheden. Deze 120ohm zorgt voor het differentieel. Dus gunstige omstandigheden of niet, de 0/gnd is gewoonweg niet nodig, net zo min als bij ethernet(Wat ook een differentieel signaal is )

Dat is niet zo zwart/wit als jij zegt, als het potentiaal verschil boven de maximum van de tranceiver chip uit komt, krijg je mooi rookwolkjes......

De 120 ohm zorgt ervoor dat het signaal wordt 'opgevreten' anders weerkaatst het weer de canbus op. Even voor de goede orde, je hebt aan het begin van de bus en op het einde van de bus een terminatie weerstand, als je dus gaat meten op de CANH en CANL lijn moet je dus 60 ohm meten. (Al werkt een weerstand in 9 van de 10 gevallen ook)

[itcouldbeanyone]

Vuikie schreef op maandag 29 mei 2017 @ 09:18:
[...]

Ehm, nee zoals ik al zei/schreef CAN-bus loopt over een differentieel signaal. Dit is speciaal ontworpen zodat je geen potentiaal nodig hebt. Terminatie van een CAN-bus gebeurt met 100ohm op lage snelheden en 120ohm op hoge snelheden. Deze 120ohm zorgt voor het differentieel. Dus gunstige omstandigheden of niet, de 0/gnd is gewoonweg niet nodig, net zo min als bij ethernet(Wat ook een differentieel signaal is )


[...]

Dit is reinste onzin. Het maakt in dit geval misschien niet uit(Ik heb even naar de voorbeelden gekeken) maar het meegeven van je CAN-ID is heel belangrijk binnen een CAN-bus (CAN = Controller Area Network) want het CAN-ID wordt gebruikt voor arbitrage voor welke node er een message op de bus mag zetten. CAN werkt ook door middel van het message passing principe. Normaliter laat je je applicatie luisteren naar de ID's waar jij naar wil luisteren. Dus als ID #1 iets op de bus zet en jij wil weten wat wat ID #1 te zeggen heeft, moet je wel zeker weten wat er op de bus staat ook echt van het apparaat komt waar jij naar wil luisteren.
Als je meerdere ID's #1 op de bus hebt, heb je dus kans dat ze tegelijk iets op de bus zetten en data verminking krijgt. En als dit al niet gebeurt dan is nog steeds niet gegarandeerd dat het bericht wat je op pikt de juiste is.

Ik raad dan ook aan om de wiki over CAN te lezen: Wikipedia: CAN bus
Misschien beter nog, de Bosch CAN specificatie 2.0: http://www.bosch-semicond...canliteratur/can2spec.pdf

@pascalboy Als je de controller te laag klokt dan heb je kans dat het niet goed gaat
Ik hoop voor je dat het omzetten naar 16MHZ het probleem verhelpt. In essentie is dit dus een software probleem(Uitgaand van 16MHZ ipv. 8MHZ)
Ik zie ook dat je J3 moet doorverbinden om gebruikt te kunnen maken van de interne 10ohm(???, ik vermoed 100/120ohm) zodat je de shield goed kan gebruiken.
Een gevalletje Chinese kwaliteit?

In de praktijk zul je merken dat ground wel belangrijk is. Ik ontwerp al jaren hardware op basis van can.
Zonder ground is can gewoonweg met de meeste controllers ruis gevoelig, een extra referentie zorgt ervoor dat je 2.5V niet te veel gaat schommelen


Data verminking op je can ? Explain?
Het gene wat als eerste bitje een 0 heeft heeft voorang, andere nodes die hier een 1 van willen maken , maar dit uitleest als een nul zullen automatisch wachten , net zolang totdat het een 1 word, dus zelfs met 100 dezelfde ids zul je op can geen data verminking krijgen.

Dat is dus ook de voornaamste redenen waarom masters vaak een lagere id gebruiken omdat dit het eerste packet is wat er verstuurd word en dan meer voorang heeft op hogere Ids
En dan komen we weer bij hey punt van de ground,
Zodra die 2.5 v door ruis het bitje 0 word zullen alles wat er aan CAN verbonden is still blijven. Omdat ze dan denken dat er aan iemand anders voorang verleend is.
Het scrijven van een nul over je bus heeft altijd voorang.

Het werken met ids is daarnaast puur software ,en heeft helemaal niks te maken met hardware.
In canOpen komt het bijvoorbeeld veel voor dat meerdere nodes op het zelfde COB ID werken, omdat slaves maar naar geselecteerde IDs luisteren.
Een dashboard van een renaulth twizy heeft bijvoorbeeld het zelfde id als de IXAAt dongle waar je de regelaar mee aftemd

[ Voor 3% gewijzigd door itcouldbeanyone op 29-05-2017 12:23 ]

[Vuikie]

itcouldbeanyone schreef op maandag 29 mei 2017 @ 12:17:
[...]


In de praktijk zul je merken dat ground wel belangrijk is. Ik ontwerp al jaren hardware op basis van can.
Zonder ground is can gewoonweg met de meeste controllers ruis gevoelig, een extra referentie zorgt ervoor dat je 2.5V niet te veel gaat schommelen

Ik werk en programmeer al jaren CAN-bussen in de industriële-automatisering en daar heb ik CAN-bussen van 20 á 100 meter tussen verschillende machines waar we soms potentiaal verschillen hebben van 10-tallen volts(Ja dit is gemeten, het personeel voelden tintelen als ze tussen 2 machines door liepen en vast pakten, is opgelost met een extra aarddraad tussen de 2 machines) maar de CAN-bus tussen die 2 machines bleef altijd werken. Als jou claim waar is, dan zou de CAN-bus niet meer werken en zou er schade zijn aan de PLC's.

Data verminking op je can ? Explain?
Het gene wat als eerste bitje een 0 heeft heeft voorang, andere nodes die hier een 1 van willen maken , maar dit uitleest als een nul zullen automatisch wachten , net zolang totdat het een 1 word, dus zelfs met 100 dezelfde ids zul je op can geen data verminking krijgen.

Sorry, maar ik pak toch even Wikipedia erbij. Als je wil zal ik van de week, als ik tijd heb, de CAN-spec. van Bosch doorspitten.

Wikipedia
ID allocation

Message IDs must be unique on a single CAN bus, otherwise two nodes would continue transmission beyond the end of the arbitration field (ID) causing an error.

In the early 1990s, the choice of IDs for messages was done simply on the basis of identifying the type of data and the sending node; however, as the ID is also used as the message priority, this led to poor real-time performance. In those scenarios, a low CAN bus utilization of circa 30% was commonly required to ensure that all messages would meet their deadlines. However, if IDs are instead determined based on the deadline of the message, the lower the numerical ID and hence the higher the message priority, then bus utilizations of 70 to 80% can typically be achieved before any message deadlines are missed.

Dat is dus ook de voornaamste redenen waarom masters vaak een lagere id gebruiken omdat dit het eerste packet is wat er verstuurd word en dan meer voorang heeft op hogere Ids
En dan komen we weer bij hey punt van de ground,
Zodra die 2.5 v door ruis het bitje 0 word zullen alles wat er aan CAN verbonden is still blijven. Omdat ze dan denken dat er aan iemand anders voorang verleend is.
Het scrijven van een nul over je bus heeft altijd voorang.

Dit is alleen tijdens arbitrage, niet tijdens de rest van een frame. Daarom mag een node-ID 1 keer op de CAN voorkomen.

Het werken met ids is daarnaast puur software ,en heeft helemaal niks te maken met hardware.
In canOpen komt het bijvoorbeeld veel voor dat meerdere nodes op het zelfde COB ID werken, omdat slaves maar naar geselecteerde IDs luisteren.
Een dashboard van een renaulth twizy heeft bijvoorbeeld het zelfde id als de IXAAt dongle waar je de regelaar mee aftemd

COB-ID != node-ID! Dat het werkt met de Renault is meer een misbruikt van de CAN-structuur dan daadwerkelijk het juist implementeren van de CAN-specificatie. Een node-ID is misschien niet de laagste(hardware) level, maar wel een lagere level dan de COB-ID.

Maar goed, misschien moet deze thread weer teruggeven worden aan de TS. Ik ben benieuwd of het veranderen van de xtal van 8 naar 16MHZ soelaas bied. Probeer anders eerst 125Kbit/s ipv. 500Kbit/s en kijk of je daarmee wel communicatie hebt.

[pascalboy]

Ik heb het eindelijk werkend!

Ik heb de 500Kbit/s naar 125Kbit/s veranderd en ik kan nu dingen versturen en ontvangen. Dit heeft zeker te maken met de 8MHZ en de 16MHZ wat hij kan afhandelen?

Helaas werkt het nu alleen via de CAN_H en CAN_L poort, dus via de serial kabel nog niet. Ik vraag morgen om kantoor wel even of ik een kabeltje mag lenen. Anders zou het mogelijk kunnen zijn om de vcc en gnd van de com kabel aan te sluiten om de gnd en 5v van de arduino zelf? zodat ik de arduino einde de com poort niet hoef te gebruiken?

Is het nu nog slim op morgen de 16MHZ kristallen erop te solderen?

[ Voor 17% gewijzigd door pascalboy op 29-05-2017 22:05 . Reden: vraag toegevoegd ]

[itcouldbeanyone]

Vuikie schreef op maandag 29 mei 2017 @ 21:14:
[...]


Ik werk en programmeer al jaren CAN-bussen in de industriële-automatisering en daar heb ik CAN-bussen van 20 á 100 meter tussen verschillende machines waar we soms potentiaal verschillen hebben van 10-tallen volts(Ja dit is gemeten, het personeel voelden tintelen als ze tussen 2 machines door liepen en vast pakten, is opgelost met een extra aarddraad tussen de 2 machines) maar de CAN-bus tussen die 2 machines bleef altijd werken. Als jou claim waar is, dan zou de CAN-bus niet meer werken en zou er schade zijn aan de PLC's.

[...]

Sorry, maar ik pak toch even Wikipedia erbij. Als je wil zal ik van de week, als ik tijd heb, de CAN-spec. van Bosch doorspitten.

[...]


[...]

Dit is alleen tijdens arbitrage, niet tijdens de rest van een frame. Daarom mag een node-ID 1 keer op de CAN voorkomen.


[...]


COB-ID != node-ID! Dat het werkt met de Renault is meer een misbruikt van de CAN-structuur dan daadwerkelijk het juist implementeren van de CAN-specificatie. Een node-ID is misschien niet de laagste(hardware) level, maar wel een lagere level dan de COB-ID.

Maar goed, misschien moet deze thread weer teruggeven worden aan de TS. Ik ben benieuwd of het veranderen van de xtal van 8 naar 16MHZ soelaas bied. Probeer anders eerst 125Kbit/s ipv. 500Kbit/s en kijk of je daarmee wel communicatie hebt.

Waar heb ik gezegd dat de plc stuk zou zijn ?
Je 2.5 volt word nul door ruis of je nul word een 1, dus je voorang regel word verstoord
Maar je eigen ervaring is dus daar ook dat dat de oplossing was

Ik kom systemen tegen met 700Volt electrische scheepsvaart

Prima je ervaring met PLCs , waar denk je dat die PLCs weg komen?
Er zit voor jouw dus nog een layer tussen.
Ik ontwerp ECUs en Gateways voor de CAnBus op hardware en software nivea,
Een id word in feite niet eens vertuurd , dat is weer een software layer boven je hardware ,
Bij Canopen word bijvoorbeeld je Id uit je laatste cijfers van je COBid Gehaalt.
Dat je met een PLC last van zult hebben met devices en het zelfde id , dat zit hem in de software van de PLC, heeft niets met de hardware te maken.
En dat je die renaulth misbruik noemt? Das Can
Met CanOpen protocol en dat ga je nog veel meer tegen komen inde toekomst.

Een can controller zal altijd proberen data op je bus te gooien, in het gehele packet, dit is juist omdat er geen errors mogen komen, zodra je hier niet het hele packet in mee neemt, zou je canbus erg inzakken omdat er te veel correcties moeten worden aangemaakt.

maar goed wij zullen het denk ik niet eens worden.
En het voegt niks toe aan de TS ,


Ontopic, ik zal eens kijken of ik nog ergens een libary heb liggen die ik toen gebruikte op arduino

[pascalboy]

Oke een kleine update, ik heb de 8.000 kirstals vervangen door de 16.000 en de J3 gesoldeerd. Nu werkt 500Kbit/s !! Alleen helaas nog steeds niks via de serial kabel.. Ik ga later (morgen) kijken of ik de setup werkend krijg hoe mijn bedoeling was. (andere serial kabel naar 10 pin mini din)

---

EDIT:

Oke dus na wat proberen en aansluiten is het me eindelijk gelukt met wat ik wou berijken met mijn shield!
De oplossing was dus de 8.000 kristal vervangen door een 16.000, de J3 solderen en uiteindelijk inplaats van een serial cable de can_h en can_l poort te gebruiken. De enigste vraag die achter blijft is waarom ik dan de andere poort niet kan gebruiken...?

Maar bij deze het resultaat

[ Voor 65% gewijzigd door pascalboy op 30-05-2017 21:16 ]