Can Messages needed to get the rear outlander inverter to work - WIKI?

[Zapatero]

I went through the threads and found some infos and one Video that explains it mostly. But is there a definite list of someone that had success spinning the rear outlander motor with the inverter? I would like to add it to the Wiki!

[aot93]

I've posted full working and tested code (daily driver) here:

https://github.com/aot93/Mini-E-VCU

These are the CAN messages required with x287 needing to be sent at 50ms.
inverterFunction needs to be 0x03 to enable drive, 0x00 will disable the inverter

Note- if you have the OEM charger on the same CAN bus as the inverter you might hit problems as it also sends messages on some of those id's.

Code: Select all

    torqueLoByte = lowByte(torqueRequest);
    torqueHibyte = highByte(torqueRequest);
    msg.id = 0x287;
    msg.len = 8;
    msg.buf[0] = 0;
    msg.buf[1] = 0;
    msg.buf[2] = torqueHibyte;
    msg.buf[3] = torqueLoByte;
    msg.buf[4] = 0;
    msg.buf[5] = 0;
    msg.buf[6] = inverterFunction;
    msg.buf[7] = 0;
    Can2.write(msg);
    torqueRequest = 0;
  }

  if (timer100_1.check() == 1)
  {
    msg.id = 0x371;
    msg.len = 8;
    msg.buf[0] = 48;
    msg.buf[1] = 0;
    msg.buf[2] = 0;
    msg.buf[3] = 0;
    msg.buf[4] = 0;
    msg.buf[5] = 0;
    msg.buf[6] = 0;
    msg.buf[7] = 0;
    Can2.write(msg);
    delay(1);
    msg.id = 0x285;
    msg.len = 8;
    msg.buf[0] = 0;
    msg.buf[1] = 0;
    msg.buf[2] = 20;
    msg.buf[3] = 57;
    msg.buf[4] = 143;
    msg.buf[5] = 254;
    msg.buf[6] = 12;
    msg.buf[7] = 16;
    Can2.write(msg);
    delay(1);

    msg.id = 0x286;
    msg.len = 8;
    msg.buf[0] = 0;
    msg.buf[1] = 0;
    msg.buf[2] = 0;
    msg.buf[3] = 61;
    msg.buf[4] = 0;
    msg.buf[5] = 0;
    msg.buf[6] = 33;
    msg.buf[7] = 0;
    Can2.write(msg);

[arber333]

Note- if you have the OEM charger on the same CAN bus as the inverter you might hit problems as it also sends messages on some of those id's.

Can you tell us which MSGs are overlapping? Also by any chance do you see which bytes are clashing together? Could just require tune up of some of the byte values? Thank you.

EDIT:
I see you send this to inverter
msg.id = 0x286;
msg.len = 8;
msg.buf[0] = 0;
msg.buf[1] = 0;
msg.buf[2] = 0;
msg.buf[3] = 61;
msg.buf[4] = 0;
msg.buf[5] = 0;
msg.buf[6] = 33;
msg.buf[7] = 0;
Can2.write(msg);

Charger relevant command
0x286 B0+B1 = voltage setpoint (E74=370.0V, 0,1V/bit)
B2 = current setpoint DC-side (78=12A -> 0,1A/bit)

This would mean you would need to suppress some data from inverter since charger needs B0, B1 and B2 and inverter is sending 0 on the line. Maybe the solution would be to simply cut inverters 12V power...

[tom91]

Is it not that you need to send 0x286 with different values for driving and for charging?

Atleast thats what I pulled together from your code.

[johu]

I have a similar situation with Ampera DC/DC and Leaf BMS. BMS needs some info in the upper bytes and DC/DC in the lower. Luckily they ignore each others data.
Furthermore I'd put charger and inverter on different 12V lines anyway. They'll never run at the same time.

[aot93]

TBH I saw there was a potential conflict and knowing I was going to have charger / BMS on separate CAN bus to inverter I decided not to look further in it.

There is also a conflict with 0x663 and 0x664 if the charger and OEM cells are used with simpBMS.

[arber333]

TBH I saw there was a potential conflict and knowing I was going to have charger / BMS on separate CAN bus to inverter I decided not to look further in it.

There is also a conflict with 0x663 and 0x664 if the charger and OEM cells are used with simpBMS.

My idea is to get motor-inverter-charger-heater-AC compressor connected all together on single VCU.
Battery i intend to use non OEM (or rather different OEM) JK BMS with CAN bus at 250kbps which i intend to translate to 500kbps and 0x285 msg that comes from Outlander battery. I will report on any anomalies...

[OutlandishPanda]

Note- if you have the OEM charger on the same CAN bus as the inverter you might hit problems as it also sends messages on some of those id's.

Can you tell us which MSGs are overlapping? Also by any chance do you see which bytes are clashing together? Could just require tune up of some of the byte values? Thank you.

EDIT:
I see you send this to inverter
msg.id = 0x286;
msg.len = 8;
msg.buf[0] = 0;
msg.buf[1] = 0;
msg.buf[2] = 0;
msg.buf[3] = 61;
msg.buf[4] = 0;
msg.buf[5] = 0;
msg.buf[6] = 33;
msg.buf[7] = 0;
Can2.write(msg);

Charger relevant command
0x286 B0+B1 = voltage setpoint (E74=370.0V, 0,1V/bit)
B2 = current setpoint DC-side (78=12A -> 0,1A/bit)

This would mean you would need to suppress some data from inverter since charger needs B0, B1 and B2 and inverter is sending 0 on the line. Maybe the solution would be to simply cut inverters 12V power...

Hmm, that is interesting - Mitsubishi have all of these units on the same bus as we know:

http://mmc-manuals.ru/manuals/outlander ... C00ENG.pdf

I'm just at the stage of connecting the front OEM inverter to the same CAN bus as the OEM charger/DC-DC and my BMS.

So we know torque control is on 0x287 for the front and rear motors (hence posting this message here):

https://github.com/damienmaguire/Outlan ... m_dump.pdf

The charger commands are on 0x285 and 0x286

But the inverter is also expecting to receive 285 and 286 (bytes 3 and 6) and 371 (from Damien's work). Is it just wanting to know something about the charger state, i.e. not charging (don't move when charging) and maybe that the DC/DC is on? So rather than commands (which would be very odd to share commands for different controllers on the same IDs), its just looking for system state information to confirm appropriate to move?

Just trying to make sense of it all. Hoping to get to get my front motor turning very soon, having been looking at it for the last two years sulking under the bench...

Has anyone tried powering the inverter HV with a safer 30V 5V (the most I've got) just to get started with de-bugging CAN? Will it turn at that voltage? Thanks.

[johu]

Added your code to ZombieVerter: https://github.com/damienmaguire/Stm32- ... verter.cpp

Can test it when Zapatero is up and running.

Just 1 axle for now, will need to introduce 4WD mode to ZombieVerter at some point.

[celeron55]

But the inverter is also expecting to receive 285 and 286 (bytes 3 and 6) and 371 (from Damien's work). Is it just wanting to know something about the charger state, i.e. not charging (don't move when charging) and maybe that the DC/DC is on? So rather than commands (which would be very odd to share commands for different controllers on the same IDs), its just looking for system state information to confirm appropriate to move?

The way CAN communication is designed isn't as "commands to certain module", but rather what happens is different modules publish data, and any other module can use the data if they wish.

So, something we call "inverter command" is definitely in reality just data published by some module in the system, without any regard to who reads it. Most likely something like "VCU torque request" (the VCU doesn't make torque - it just publishes what it would like to happen), and "charger status" (the charger definitely doesn't command the inverter - but it publishes stuff that the inverter just happens to want to check).

So in any CAN system the messages almost certainly will overlap, if you think of them as commands. But they aren't commands, they're just published data.

Some systems do layer a command protocol on top of CAN, but it's not commonly done in automotive applications, aside from diagnostics.