CAN to MPX

Hello Everyone

Thought this would be the ideal place to ask as I'm a complete beginner for CAN and want to setup something that I have wanted to do for ages.

I have access to a third party device that translates CAN to Toyota's BEAN MPX System.

Now to create plug and play patch harnesses I want to be able to create a CAN messages for

Transmit

RPM

Coolant Temp

Alternator Light On/Off

Oil Pressure Switch On/Off

Ambient Temp

Low Oil Level On/Off

Receive

A/C Request

Snow Mode Button On/Off

Now then I realise that if for whatever reason I cannot connect all the items like Alternator Light / Oil Pressure Light / Ambient Temp due to ECU constraints then that is fine.

But is it really a relatively easy task to set these up in

Link

Haltech

ECUMaster

I have had a play with Link and ECUMaster and it at first glance appears that I can relatively easily setup what I want above.

The developer in the past has asked for a DBC File so ideally I would have to learn how to create those.

But am I massively over simplifying it all. Will I run into issues using the same device programmed to receive the data from various ECU's.

Provided I assign the same info to the same bit locations and assign everything the same in the custom CAN Transmit and Receive streams?

Any help greatly appreciated as I am worried I'm at the Peak of the Dunning-Kruger Affect here!

DBC files are created using software from Vector.com - CANdb++ Editor. There may be a free version available, but I will warn you it's complicated and assumes a lot of knowledge to use.

Here is the manual for CANdb++ Editor.

G'day Chris. I need to be a little careful how I respond to messages about Toyota's BEAN network. I did the development work on the system Link use, as AFAIK they still use my hardware design and firmware code in their Altezza plug in ECUs, and It's unethical to spill your client's data out onto the webs :-/.

The way it's setup in the Altezza plug in is that the CAN2 peripheral on the Link main board is routed to the BEAN translator on the second PCB. The CAN2 peripheral is then setup to output a pre-defined datastream, and read a pre-defined datastream (you choose 'Altezza' or similar in PCLink). The translator is hardcoded to receive / transmit these datastreams. I think you can even see how this CAN datasteam is defined in PCLink, but it was nothing complicated / special.

Your approach absolutely sounds like it will work, that's kind of one of the key ideas of CAN, is that a single device can get data from multiple sources. Instead of looking for a particular sender, it just looks at the BUS, for particular PID's. Doesnt care where they come from, aslong as they're valid and formatted correctly. I've not come across a scenario where multiple devices are configured to transmit the same dataframe on the same PID, but it would be possible for sure.

David has given you the good link for creating DBC files. It's been a few years since I've done one, but I remember being able to muddle through. Took some time, but reading the doc made it workable.

I remember reading the whitepapers on the BEAN network and thinking 'man, this is a lot like CAN, but just different enough to need custom hardware and firmware, frustrating!'. If you look at some of the names of the people that developed it, there is some crossover to the initial work on CAN I'm pretty sure.

Also, yes, during development I 100% named the project 'BEANCAN'. I mean, had to, right?

Haltech doesnt have configurable CAN at all, and no CAN receive for things like AC request or snow button, only transmit. So you will have to build the translator to work with their fixed "haltech CAN Protocol V2" which will only give you the basics such as RPM and coolant, but I don't think you will be able to do oil level, ambient temp or alt-light with the standard stream. You could possibly get more info in and out of the ecu by using one of the OEM CAN data sets such as 350Z or whatever - but then that is two cars you will have to reverse engineer...

ECU master is more flexible and should be able to cover most of it with their generic CAN tools but still pretty limited on the parameters or functions that can be received via CAN from memory.

Link can do all of it and already does if you look in the Altezza plug-in map as an example how it is set up with our translator. You could probably set up the Link and ECU master to use a similar stream with a bit of planning.

So of the 3 ecu's you mention, Link and ECU master should be able to work with a similar translator, but it will most likely need to be different for Haltech and it will have minimal functionality.

FYI, Savvycan is a good free software for creating DBC files, with the common visual table layout for bits/bytes etc. Still need a fair idea what you are doing though.