van canbus naar modbus

Wat hardware betreft is het eenvoudig. Er zijn vele (goedkope) microcontrollers die een CAN bus aan kunnen sturen, en MODBUS (RTU variant) draait over een standaard seriele poort, en vrijwel elke microcontroller heeft dat wel aan boord. Zo'n IC kost een paar kwartjes, maar er moet nog wel wat "standaard" spul omheen om het werkend te krijgen. Denk aan bij elkaar iets aan EUR 5 aan onderdeel kosten. Een degelijk (maritiem / waterdicht?) kastje om het in te stoppen kost al meer.

Software is lastiger. De manier waarop apparaten geadresseerd worden is bij CAN heel anders dan bij MODBUS, en ook hoe data geinterpreteerd moet worden tijdens de vertaalslag kan erg vaag zijn. Vooral als je niet eens van te voren weet wat voor apparatuur en van welke fabrikanten je aan elkaar wilt koppelen.

En dan zijn er bijkomende problemen. In een CAN pakket kan geloof ik maximum 8 bytes aan data zitten, maar in MODBUS kan dat veel meer zijn. Dus hoe ga je dan een groot pakket van MODBUS in stukjes hakken voor CAN?

Zolang je aan de ene kant een CAN bus (apparaat) hebt, die data over MODBUS wilt versturen, en dan weer terug vertalen naar CAN, dan is dat vermoedelijk nog wel redelijk eenvoudig. Dit wordt "tunnelen" genoemd. Dit tunnelen wordt veel gebruikt. B.v. een PC programma wat een seriele poort probeert aan te sturen. Dat wordt dan afgevangen door je OS, die verstuurt het over USB, en aan de USB kabel zit een chipje dat er dan weer een serieel signaal van maakt. (Een VPN doet ook zoiets, maar dan met "internet" data).

Dit vertalen levert wel extra vertragingen op, en dat kan een probleem zijn.

Als je meerdere CAN bussen hebt die je met (b.v. een enkel) MODBUS netwerk aan elkaar wilt koppelen, komt ook het adresserings probleem weer om de hoek kijken. Een simplistische aanpak stuurt een via modbus binnen gekomen pakket altijd door naar de CAN bus, (nivo van "hub") terwijl een slimmer apparaat alleen het pakket doorstuurt als het weet dat er op het betreffende stukje van de CAN bus een apparaat zit wat iets met die data kan doen. (Begint op een "switch" te lijken).

En al zulke details bij elkaar opgeteld maakt het ingewikkelder, dus software ontwikkelen kost meer tijd / geld. Maar het is ook goed mogenlijk dat iemand anders het al gedaan heeft en 95% van zo'n project gewoon openbaar op github (of aanverwanten) staat tegenwoordig.

Een advies: als je geen elektronica- of computertechniek opleiding, en geen ervaring en apparatuur (scope, logic analyzer) hebt, laat het dan vooral aan een specialist over. Ik heb veel goede "allround" techneuten hierop zien nat gaan, met allerlei vage, moeilijke, storingen bij systemen in het veld als gevolg. Doe vooral waar je goed in bent.

Er zijn wel meerdere belangrijke verschillen tussen CAN en Modbus. Laat ik er 1 uitpikken. Bij Modbus stuurt een randapparaat nooit op eigen initiatief data op. Dit gebeurt alleen op verzoek van de host. Hierdoor wordt 'door elkaar praten' op de bus voorkomen.
Bij CAN daarentegen, kan elk apparaat op eigen initiatief data op de bus zetten. De host, EN andere nodes kunnen daarnaar luisteren en zonder tussenkomst van de host erop reageren. Er is een mechanisme dat de voorrang regelt, en bij het 'door elkaar praten', het gesprek weer op gang helpt. Responsetijden van CAN kunnen op deze manier sneller zijn dan van Modbus. En apparaten zijn minder afhankelijk van de host software.

Elke converter tussen die twee protocollen moet hierop een list verzinnen. Als gebruiker van zo'n converter moet je vervolgens testen of deze list werkt met alle randapparatuur, onder alle gebruiksscenarios. Veel plezier ermee...

Ik ontwikkel veel electronica en software voor schepen (vooral kleinere), en mijn ervaring is juist dat alles en iedereen NMEA2000 praat, met nog wat J1939 als uitzondering.

Zie je MODBUS RTU of MODBUS TCP opkomen? Die laatste zou ik nog enigzins logisch vinden, vooral voor apparaten die veel data moeten verzenden en ontvangen.

Op woensdag 8 april 2026 13:36:09 schreef SparkyGSX:
Ik ontwikkel veel electronica en software voor schepen (vooral kleinere), en mijn ervaring is juist dat alles en iedereen NMEA2000 praat, met nog wat J1939 als uitzondering.

Dat hangt dan van je werkgebied af, want ik kom weer CANopen en J1939 tegen. Gebruik zelf een 18F46K60 als interface naar de CANBUS.

Het hangt ook af of je van een SLAVE modbus naar CAN wilt of andersom (ik neem aan MODBUS->CANBUS). Dat is een levensgroot verschil.

En wat gebruiken je devices aan de CAN zijde en wat aan de MODBUS zijde? Is dan CANopen of iets anders?
(Devicenet of zo?).

Heb je CAN slaves (CANopen) die je vanuit MODBUS (RTU) wil aansturen zul je zelf een CANopen master moeten implementeren. Is allemaal wel te doen maar echt geen simpel klusje als je niet ervaren bent in dit soort dingen.

Airco en HVAC systemen gebruiken bijvoorbeeld weer veel BACNET.

Als je zelf iets wilt ontwikkelen tegen normale SW engineering uur prijzen zit je minimaal op 25k+ euro aan kosten.

Een andere optie zou kunnen zijn om een HMS protcol converter in te zetten. Die maken allerlei converters (moet je ook wat aan programmeren trouwens).

Andersom van CANopen (bijvoorbeeld) naar modbus is technisch wat makkelijker te maken.

Ik heb zelf ook nog eens de behoefte gehad om zoiets te maken voor een ander doel, maar ben er nog niet aan toe gekomen.

Met een gemiddelde HMI kan je gewoon tegelijkertijd zowel CAN bus als ModbusTCP apparaten gebruiken. En diezelfde HMI kan dan ook als "brug" tussen alle aangesloten apparaten dienen. Misschien niet de mooiste oplossing, wel de gemakkelijkste.
Een HMI heeft altijd wel meerdere poorten voorhanden, er is een ruime keuze uit een of meerdere RS232, RS485, CAN, MPi of ethernet aansluitingen, waar diverse protocollen over kunnen lopen.

Ik doe dagelijks heel veel met elektro op bootjes (24/7 24h als het aan mijn baas ligt)

qua nautische apparatuur zijn er 2 bussen:
NMEA 0183/serial
NMEA 2000.

NMEA 0183 is een serieel protocol, gebaseerd op RS422, wat weer compatible kan zijn met RS485, waarmee het lijkt op MODbus RTU (draait ook op RS485) lijkt. Het is echter geen MODbus.

Daarnaast is er NMEA 2000 wat inderdaad CAN draait.

Professioneel zie ik echter heel weinig NMEA 2000, alles werkt nog gewoon op NMEA serial, zelfs bootjes van 2 jaar oud. RS485 of 422 is gewoon super stabiel, wat ik van CAN niet kan zeggen. Wel is het zo dat NMEA 0183 op 4800 baid draait wat zeker met een AIS al heel snel volloopt. Door het NMEA serial te noemen kon de baudrate omhoog. Bericht opbouw is hetzelfde.

Voordeel is dat het een ASCII based protocol is en dus meteen leesbaar in elke terminal.

Super handig dus.

Als je dus gaat converteren moet je die baudrates wel weten.
Ze zijn kant en klaar te koop:
https://www.svb24.nl/nl/actisense-ngx-1-iso-nmea-2000-naar-nmea-0183-a…

Maar let dus wel op dat je hier wellicht baudrates problemen mee kunt krijgen. (Ze claimen NMEA 0183, maar als ze dan de echte 0183 op 4800 baid bedoelen en jij spuugt sneller uit, dan wordt het heel vervelend.

Of ik dit zou willen op de scheepjes die ik beheer? NEE!!!

Dubieuze apparatuur zonder wheelmark en in geval van nautisch spul moet het zelfs door klasse goedgekeurd zijn. Ik MAG het niet eens gebruiken.

Je geeft niet aan in welke sector je zit, maar in de beroepsvaart is dit een nogo.

Overigens is het ook helemaal niet handig om al je NMEA signalen aan elkaar te knopen. Levert een shitload aan data op die je niet nodig hebt op alle plekken en redundantie is 0

Een GPS NMEA gaat naar veel plekken, maar die combineren met AIS is vaak niet nodig. AIS is alleen interessant op je ECDIS en Radar.
Vaak heeft nautische apparatuur meerdere seriële poorten om dit netjes te scheiden.

Gebruik dan ook NMEA distributie modules zodat je bus niet meteen plat gaat als 1 component of kabel defect gaat.

Zie hier meteen de reden dat NMEA 2000 niet van de grond komt: is gewoon niet een handig protocol.

[Bericht gewijzigd door High met Henk op woensdag 8 april 2026 19:59:30 (21%)]

CAN niet stabiel? Dan deugt er iets niet aan je bekabeling, terminators, of je hebt één of meer apparaten die zich niet aan de regels houden. Ik heb, vroeger in de industrie, CAN bussen gehad die een tiental centimeter langs de boog van een enorme plasmasnijder liep (200+kW), en dat werkte zonder problemen. Een USB toetsenbord 20m verderop aan een andere machine stopte er wel mee.

Ik zie juist heel veel NMEA 2000, in de pleziervaart dan, maar daar is redundantie ook niet echt een ding.

Precies. Can KAN niet minder stabiel zijn dan RS485: het /is/ RS485, maar dan met wat extra beperkingen voor de hardware. (groter common mode spanning toegestaan tussen signaal en GND) (en software: een specifiek protocol is afgesproken).

Wat wel kan meespelen is dat de baudrate van invloed is. Bij CAN is dat geloof ik 1 of 2 mbps. 0.0048 mbps kan (zeker met onjuiste termination) dan stabieler zijn.

Op donderdag 9 april 2026 14:48:18 schreef rew:
Wat wel kan meespelen is dat de baudrate van invloed is. Bij CAN is dat geloof ik 1 of 2 mbps. 0.0048 mbps kan (zeker met onjuiste termination) dan stabieler zijn.

In mijn toepassing 250k, en dat is geen vrienelijke omgeving, maar je kan omlaag tot minder dan 50k. Problemen wordt vaak veroorzaakt door een foutieve termination.

Op donderdag 9 april 2026 13:34:26 schreef SparkyGSX:
CAN niet stabiel? Dan deugt er iets niet aan je bekabeling, terminators, of je hebt één of meer apparaten die zich niet aan de regels houden. ....

Je hebt mijn verhaal niet begrepen of niet gelezen.

We hebben meerdere nmea bussen met rs485. Als er 1 device down gaat op die bus trekt hij in het ergste geval 1 bus down. Bijvoorbeeld de gyro. Heb je geen heading, maar de gps bus met locatie loopt door. En als je beetje geluk hebt heeft je magnetisch kompas ook nmea, dus heb je redundant nog heading.

Zoals gezegd. Vrij veel spul heeft meerdere seriele nmea bussen.

Nmea2000 is 1 bus waar alles opstaat. Gaat die down door een defect heb je niets meer!
Zoekt ook verdomd lastig een storing.

Ik ken geen apparaten met meer dan 2 nmea 2000 bussen en vraag me dan zelfs af of die meerdere transceivers hebben of alleen doorgelust worden intern.

@rew: terminatie van deze rs485 is 180 ohm trouwens waar can altijs 120 ohm is...

Rs485 is ook standaard 120 ohm, 180 heb ik nooit ergens gezien.

Een goed aangelegde CAN bus gaat niet plat. En rs485 ook niet als je goede hardware assisted protocol hebt.

En als een device stuk gaat is CAN robuster als een rs485 buffer die de bus omlaag trekt, op hier en daar wat uitzonderingen na.

Ik heb eerder profibus storingen gezien, ook met perfect aangelegde bekabeling, waarschijnlijk sw fouten in de devices.

Daar gaat het hier niet om, de TS wil weten wat er voor mogelijkheden zijn om de boel te koppelen. Niet een discussie over de bussen zelf.

Op donderdag 9 april 2026 14:48:18 schreef rew:
Wat wel kan meespelen is dat de baudrate van invloed is. Bij CAN is dat geloof ik 1 of 2 mbps.

CAN 2.0 gaat tot 1Mbps, NMEA 2000 is altijd 250kbps. Met CAN-FD kun je in het data segment tot 8Mbps, en kan er 64 bytes in één bericht (gewoonlijk maar 8), maar hoewel de standaard al heel lang bestaat heb ik het nog nooit in het wild gezien.

Op donderdag 9 april 2026 19:34:45 schreef henri62:
Rs485 is ook standaard 120 ohm, 180 heb ik nooit ergens gezien.

Leesvoer:

https://ecostruxure-building-help.se.com/bms/topics/show.castle?id=102…

Een goed aangelegde CAN bus gaat niet plat. En rs485 ook niet als je goede hardware assisted protocol hebt.

En als een device stuk gaat is CAN robuster als een rs485 buffer die de bus omlaag trekt, op hier en daar wat uit onderingen na.

J1939 heb ik bij Cat(erpillar) anders flink ellende mee dan vallen alle dashboards uit

Vacon drives met CAN bus was ook al geen succes; heeft een grote productiekraan weken op plat gelegen.

Met RS-485 heb ik ook wel ellende gehad idd profibus. Echter met NMEA zelden tot niet op een kapotte NMEA repeater na...

Maar TS laat niets meer van zich horen en zoals gezegd in de beroepsvaart gelden nogal wat regels en dan zijn de meeste van die converters niet toegestaan.

Die 180 Ohm waar ze het daar over hebben is met extra bias weerstanden en op 3V3, de effectieve (differential) impedantie dus wat lager (156 Ohm).