Page 1 of 1
Make CANBus Standard
Posted: Tue Mar 10, 2020 12:40 am
by dima
This page needs help >
https://openinverter.org/wiki/CAN_table_CAN_STD
This will help with "universal" dashboard or any other interface relying on CANBus messages.
Make up a standard
Maybe grouping things logically by functions ...I don't know if "AUX 12volt" belongs together with same CANId as temperature
Re: Make CANBus Standard
Posted: Tue Mar 10, 2020 8:04 am
by joromy
dima wrote: ↑Tue Mar 10, 2020 12:40 am
Maybe grouping things logically by functions ...I don't know if "AUX 12volt" belongs together with same CANId as temperature
Not so important, for now.
Get the numbers down, I can rearrange, if it gets to messy.
It's also a priority issue, I still think the inverter only can send 10 messages....but it should be enough.
Re: Make CANBus Standard
Posted: Tue Mar 10, 2020 2:32 pm
by johu
I wonder if we should poll the more obscure values via CAN SDO instead of mapping everything somewhere?
https://openinverter.org/wiki/CAN_commu ... rs_via_SDO
The way it works: send a request message for the value you want and receive the reply.
If we agree on this I could change the firmware to address values via their unique ID instead of the parameter index. That way it stays constant throughout firmware versions.
Re: Make CANBus Standard
Posted: Tue Mar 10, 2020 3:19 pm
by joromy
johu wrote: ↑Tue Mar 10, 2020 2:32 pm
I wonder if we should poll the more obscure values via CAN SDO instead of mapping everything somewhere?
I would prefer that the different modules send messages by it self.
And have a option to choose what messages to send, by a tick box.
It's easier for dumb displays and other modules to just receive, and less traffic.
You could have the same CAN bus setup (in web interface) with default CAN id and bits filled in.
Then if anyone want to change, they can, like all other parameters.
Edit:
I can put in all values for the inverter in the wiki CAN table, and we can edit at will?
Re: Make CANBus Standard
Posted: Tue Mar 10, 2020 3:51 pm
by dima
johu wrote: ↑Tue Mar 10, 2020 2:32 pm
I wonder if we should poll the more obscure values via CAN SDO instead of mapping everything somewhere?
https://openinverter.org/wiki/CAN_commu ... rs_via_SDO
The way it works: send a request message for the value you want and receive the reply.
If we agree on this I could change the firmware to address values via their unique ID instead of the parameter index. That way it stays constant throughout firmware versions.
I am liking this SDO concept. It makes sense to standardize CAN readings without reinventing new standard. We can keep the flexibility to set your own IDs.
But as of now, does the inverter capable of sending CANOpen SDO frame?
I am guessing there would be an extra command to switch between Standard CAN and CANOpen SDO?
maybe something like:
Re: Make CANBus Standard
Posted: Tue Mar 10, 2020 4:12 pm
by johu
dima wrote: ↑Tue Mar 10, 2020 3:51 pm
But as of now, does the inverter capable of sending CANOpen SDO frame?
I am guessing there would be an extra command to switch between Standard CAN and CANOpen SDO?
Yes it is. So COB Id 0x601 is reserved for SDO request and 0x581 for SDO reply. More precisely, 0x600 and 0x580 are base addresses and 0x1 is the inverter node id. Actually every device on the network needs it's own node id, just like IP address. So that would have to become a parameter.
So try it, send
Code: Select all
0x601 # 0x22 0x00 0x20 0x00 0 0 0 0
and you'll get the value of "boost" scaled with x32
Code: Select all
0x601 # 0x22 0x00 0x20 0x01 0 0 0 0 -> fweak
Likewise you can use
Code: Select all
0x601 # 0x40 0x00 0x20 0x01 0x80 0x0C 0 0
To set fweak to 100Hz
There are more useful concepts in CANopen but most people don't understand them and rather roll their own.
EDIT: there is also an undocumented feature:
Send
Code: Select all
0x601 # 0x40 0xAA 0x31 0x01 0x08 0x10 1 0
And fweak will be send on COB id 0x1AA, start at bit 8, stretch 16 bits, scale by 1
Re: Make CANBus Standard
Posted: Tue Mar 10, 2020 4:33 pm
by johu
Just updated the documentation.
So like said, the only catch here is that the value index in Byte 4 changes between firmware versions and the currently used uids span 16 bits.
Re: Make CANBus Standard
Posted: Tue Mar 10, 2020 8:51 pm
by dima
Wow this is a discovery for me. It existed all this time
No need to do anything, send CAN and get a reply. Just works.
Excellent!
EDIT: Well not 100%, obviously getting "udc" will not work ...because it is out of parameter index.
Re: Make CANBus Standard
Posted: Tue May 05, 2020 6:24 pm
by dowster
The wiki page of can messages, do we need to poll for these values or are they sent on an interval? I'm not sure I'm reading this thread correctly. I'm interested in having a "default" configuration for my instrument cluster project based on this standard. I don't have any EV build started so I'm working on a configurable driver board what you can slap into any car and have some configurable lamp, pulse, and PWM outputs to drive older, non-canbus, instrument clusters. I'd like to be able to setup a test bench using the messages listed on the wiki page.
Re: Make CANBus Standard
Posted: Tue May 05, 2020 7:22 pm
by joromy
dowster wrote: ↑Tue May 05, 2020 6:24 pm
I'm working on a configurable driver board what you can slap into any car and have some configurable lamp, pulse, and PWM outputs to drive older, non-canbus, instrument clusters.
Something like this?
viewtopic.php?f=16&t=433
I send you a board for free, and we can do the programming together, I'm not very good at programming (See the github link)
Re: Make CANBus Standard
Posted: Thu May 07, 2020 6:25 am
by sfk
I'm also developing a custom gauge cluster and thought it would make sense to use CAN as the prime backbone.
Basically I will have an Arduino wired into the factory loom (this is a pre-CAN / pre-OBD2 car) converting these signals, some PWM to CAN to send to a Raspberry PI system to drive the HDMI video for the screen.
I think it would make sense to use CAN as a transport protocol between the gateway and the gauge cluster since there are other industry standard benefits from doing so. I could process the signals directly with the Rasbperry PI but would like to develop a more robust approach that could be applied to other vehicles with or without CAN.
The key difference here is that I'm not tied to driving the original gauge cluster with analogue inputs. Actually my gauge cluster runs on a very early serial coms competitor to CAN... PALMnet. I don't don't want to waste years of my life reverse engineering that dead standard so going with total TFT LCD replacement.
@joromy your breakout/gateway board suddenly looks very interesting.
Re: Make CANBus Standard
Posted: Thu May 07, 2020 8:13 am
by joromy
sfk wrote: ↑Thu May 07, 2020 6:25 am
@joromy your breakout/gateway board suddenly looks very interesting.
I started to like the Teensy boards, when I got the SimpBMS.
It has CAN bus, the Teensy 4 has 3 CAN buses.
This is going a little off topic, maybe make another tread.......
Re: Make CANBus Standard
Posted: Thu May 07, 2020 8:27 am
by sfk
joromy wrote: ↑Thu May 07, 2020 8:13 am
This is going a little off topic, maybe make another tread.......
Perhaps return to my Custom Gauge thread?
viewtopic.php?f=9&t=631