Deze volledig doornemen aub    =>    https://www.canopen.

nl/can

Leg uit :

 Welke “hogere” protocollen zijn op het CAN-protocol gebaseerd ?

CANopen, DeviceNet en SAE J1939.

 Noem 4 voordelen gelinkt aan CAN-bus.

1. Lage kosten

2. Niet storingsgevoelig

3. Hoge betrouwbaarheid

4. Gestandaardiseerde communicatie die real-time is.

 Verschil tussen fysieke adressering <–> functionele adressering

Fysieke adressering = berichten voorzien van een afleveradres

Functionele adressering = berichten voorzien met een ondubbelzinnige berichtenidentificatie

 Verschil tussen 11-bit en 29-bits identifier ? (nee ik bedoel niet het cijfer 18 ;o), waarom bestaat
dit ?

11 bits à 2048 verschillende soorten berichten kunnen binnen een systeem worden
gedefinieerd.

29 bits à meer dan 512 miljoen verschillende soorten berichten kunnen binnen een systeem
worden gedefinieerd.

 Acceptatiefilters ?    waarom zijn die geïntegreerd in de chip ?

Hiermee kan een node relevante berichten uit de berichtenstroom op de bus filteren.
Acceptatiefilters worden vooral gebruikt om kleine (8-bit) microcontrollersystemen met
beperkte verwerkingsmogelijkheden niet te belasten met te veel onnodige berichten.

 Leg het arbitrageprocess uit. Wat betekent Recessive bit en Dominant bit ?

 Hoe wordt de prioriteit van een “bericht” op de bus verzekerd ?

 Hoe wordt belet dat CAN-berichten de bus kunnen bezetten met prioritaire berichten ?

 Leg uit wat men met “bit quantum” bedoeld. Hoeveel kan die bedragen en wat wordt er mee
bereikt ?

 Verklaar “Bitstuffing” ?
 CAN-logica maakt gebruik van flanken om de datastroom te synchroniseren. Hierbij is het wel
noodzakelijk dat er voldoende flanken in de stroom voor komen. Om die reden zal de CAN-
controller na vijf opeenvolgende dezelfde ‘0’-en of ‘1’-en automatisch een tegengestelde bit
aan de datastroom toevoegen. De ontvangende CAN-controllers weten dat en zullen dus na vijf
dezelfde bits het volgende bit weer uit de stroom verwijderen. Dit mechanisme wordt
bitstuffing genoemd. De gebruiker merkt hier verder niets van, maar bitstuffing heeft wel een
kleine invloed op de datasnelheid.

 Hoe groter de buslengte, hoe trager de can-bussnelheid kan zijn. Leg uit.

 Welke is de maximale en minimale snelheid in CAN 2.0. Welke zijn hun respectievelijke maximale
afstanden voor de buslengte ?

 Leg CRC uit.

 Waarvoor wordt een “errorframe” gebruikt ? Hoe is dit samengesteld ?

 Waarom is CAN zo betrouwbaar ? leg uit aan de hand van een voorbeeld.

 Leg de functie van de “foutenteller” in een “node” uit.

 Wat is het verband tussen het DLC-veld en het data-veld in een bericht ? Waarom is dit 4 bits
breed ?

 Leg het volledige standaard CAN2.0 frame veld per veld uit.

 Geef de verschil(len) tov een extended bericht.

 Leg het “remote-request frame” uit.

 Hoe werkt een CAN-bus driverchip ?

 Can bus werkt meestal met een twisted pair. Hoe creer je de perfecte can-bus op fysiek niveau ?
Verklaar ook de storingsongevoeligheid. Hoe wordt die bewerkstelligd ? noem 2 manieren die
veelvuldig worden toegepast.

 Bespreek de noodzaak van een galvanische scheiding.

 Geef de belangrijkste verschillen en/of gelijkenissen tussen CAN tov met CAN-FD .
(snelheid/protocol/datagrootte/

Can-bus

https://www.youtube.com/watch?v=FqLDpHsxvf8    intro (geschiedenis)

https://www.youtube.com/watch?v=cxBz_dvLeT8    intro - oud maar goed

https://www.youtube.com/watch?v=v_y65h68z3U

https://www.youtube.com/watch?v=ledYMrZRuL8 hardware
https://www.youtube.com/watch?v=XdtdBUHEdOI hardware

https://www.canopen.nl/can

rs485

https://www.youtube.com/watch?v=VhzjYecxiSg

https://www.youtube.com/watch?v=bt9Px51eP6s

Loxone Link (in the past also called the "LoxBUS") is using a standard CAN 2.0B bus,
clocked at 125kHz (which allows up to 500m of cable length). The Miniserver has a build-
in 120Ω resistor, so the Miniserver has to be at one end of the bus. It doesn't use
automatic retransmission and uses a sample point of 68.75% (1-10-5 time quantum) with
a prescaler of 4 (at 8MHz clock rate), I do not expect this to be critical.

The Loxone Tree Extension uses two additional CAN 2.0B busses (driven by two
MCP2515 CAN controllers), but are clocked at 50kHz (which allows up to 1km of cable
length) via a prescaler of 10. There is also a minimal change in the address of Tree
devices vs. extensions, but the protocol is otherwise identical. The Tree Extension has to
be at the end of the Tree busses as well.

Packages are always using the extended frame format, therefore the object identifier is
29-bit (0x00000000…0x1FFFFFFF). The data packages are always 8 bytes long. Only the data
frame is used. Any CAN bus monitor hardware will work just fine with the Loxone Link
bus and the Tree Bus as well.
The Loxone Link bus is a strict server-client bus. The Miniserver sends data to the
extensions, the extensions send data to the bus. Extensions never talk to each other (with
the obvious exception of device bridges, like the Tree Extension and the Air Base
Extension – but even in this case: the bridge is almost 100% transparent between the
device and the server). The Miniserver can either multicast to all extensions of a specific
type (used in the update case) or to one extension via direct commands.

For the first years Loxone stored the serial number and extensions type in the CAN
object identifier. This is now called the "legacy protocol". With more extensions arriving
and also extensions with devices behind them, Loxone ran out of space and flexibility
with that scheme. The newly introduced NAT protocol does not interfere with existing
extensions, but required a server update for support. Besides the Miniserver having to
able to deal with both protocols, they are completely different. An extension either
implements the legacy protocol or the new one, never both. All Tree devices are always
using the newer NAT protocol. The Air Base extension and other gateway extensions are
still using the legacy protocol to forward packages to Miniserver. The Air devices are
using a special container format for their packages.

The 8 byte package contains a single byte, which is either a command (in the legacy
protocol) or a device NAT (in the NAT protocol) plus a 7 byte payload. The only
exception of this rule is the firmware update case for legacy extension. There are also
fragmented packages possible, which allow transmitting more than 7 bytes to/from a
device. This is used to configure extensions and heavily by the Air Base Extension to send
messages to Air devices.

Extensions can send data to the bus at any time to inform the server. This is important
for sensors or keypads to report their updated status.

While Loxone doesn't do it, it is easily possible to have a device on the Loxone Link bus,
which acts as several extensions at once.
https://github.com/sarnau/Inside-The-Loxone-Miniserver/blob/master/NAT/LoxoneLinkNATProtocol.md

https://www.mikrocontroller.net/attachment/376521/Reverse_Engineering_Loxone_Link.pdf

http://sarnau.info/category/loxone/