Introduction CAN STD: Difference between revisions
Jump to navigation
Jump to search
(Created page with "This is an attempt to get all openinverter hardware to follow a standard on their CAN bus communication. Since there is priority in the CAN bus data, it's important to have a...") |
No edit summary |
||
Line 1: | Line 1: | ||
This is an attempt to get all openinverter hardware to follow a standard on their CAN bus communication. Since there is priority in the CAN bus data, it's important to have a standard. | This is an attempt to get all openinverter hardware to follow a standard on their CAN bus communication. Since there is priority in the CAN bus data, it's important to have a standard. | ||
The goal for this CAN table, is also to have a central computer/microcontroller with CAN (several CAN), wifi (ESP), maybe a display. Then all CAN based modules can be monitored/configured, from one ESP web server or display. | |||
So I am encouraging all openiverter engineers to include CAN configuration and CAN messages in their design. If not we end up in having a lot of wifi modules and terminals programs scattered all over...... | |||
Products: | Products: |
Revision as of 12:37, 20 February 2020
This is an attempt to get all openinverter hardware to follow a standard on their CAN bus communication. Since there is priority in the CAN bus data, it's important to have a standard.
The goal for this CAN table, is also to have a central computer/microcontroller with CAN (several CAN), wifi (ESP), maybe a display. Then all CAN based modules can be monitored/configured, from one ESP web server or display.
So I am encouraging all openiverter engineers to include CAN configuration and CAN messages in their design. If not we end up in having a lot of wifi modules and terminals programs scattered all over......
Products:
- Openinverter
- Simp BMS
- Tesla Charger (only with CAN)
- Isolation monitor
- CAN display
- HV voltage sensor/current sensor
- Misc button, gear shift, menu selector, joystick
- Brake and accelerator