-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for More Than 255 Devices on CAN #5
Comments
I'm not sure if it's easily possible to physically attach more than 256 devices to one bus as each driver also adds a bit of capacitance to the bus. And if we need gateways and different bus sub-sections anyway, they might also be able to route the packages somehow... But there is another very interesting standard written by the maintainer of the Zephyr CAN subsystem: 6LoCAN, which is basically lightweight IP protocol over CAN. This could be a suitable lower layer for ThingSet aswell instead of the custom protocol with a CAN identifier similar to SAE J1939. The 6LoCAN could even run in parallel to CANopen on the same bus, as CANopen uses standard identifier length and 6LoCAN (like ThingSet) uses the extended identifier. The standard ID has higher priority, so control tasks could be implemented in CANopen, but slower interactions with a user interface using ThingSet via own protocol or 6LoCAN. |
You're right about the physical limit of the can bus. From this Q&A: "However the practical One additional consideration: A single physical transmitter could represent multiple device addresses. For example, a hub that allows for the connection of many devices, or a single device with several somewhat independent units, such as an array of LEDs. |
Also, 6LoCAN looks fantastic! I'm part way through the standard, and will continue reading. Thank you for sharing. With regards for device addressing, it seems that 6LoCAN uses a 14 bit identifier, which allows ~16,000 devices, though some of the identifiers are reserved. 0x3DEF - 0x0100 is the valid range for node ids, which would support 15599 unique ids (calculation). |
(Feature request for consideration)
With an 8 bit identifier, that leaves 256 possible device addresses, minus 1 for the reserved source/destination of 255. For many systems, this is more than sufficient. But for some, this may be a frustrating limit. In fact, the CanOpen documentation for PV applications mentions that "A PV system may consist of much more networked devices than 127". This is especially true in IoT applications, where there can be many, many devices (think: an office building).
Could ThingSet allow (but possibly not require) for more devices? Did you consider any schemes for more devices in the creation of ThingSet? Any other considerations?
The text was updated successfully, but these errors were encountered: