Setting up Dual Driven Wheel Speed with CAN?

[TylerC]

Hi guys,

First things first - I'm using an M150 with a Development License.

Short version -

What's the best way to receive wheel speeds from an OE ABS unit? Is there an advantage to using the 'Dual Driven Wheel Speed with CAN' class versus just writing a Scheduled Function that uses CanComms.RxMessage() to receive the values I want?

Long Version -

The help section for the 'Dual Driven Wheel Speed with CAN' class says that I need to set up a CAN Bus class and a CAN Block Receive class to make this thing work. The GPR files don't utilize the CAN feature of the wheel speed class, so I don't have an example to work with.

The ABS unit in the car sends out wheel speed info over CAN, however the CAN Block Receive class help says that it doesn't work well with OE CAN. That said, the 'CanBlock Get16 Slot Enumeration' has 16 OE slots that one would use with the CAN Block Receive class (I think...?). If I'm supposed to use one of these slots, how/where do I define what CAN ID and offset the OE slot actually represents?

Or do I even bother trying to get the 'Dual Driven Wheel Speed with CAN' class working and just spend my time building my own Wheel Speed group with scheduled functions to receive the CAN messages and generate slip percentages? I'm already very familiar with using the CanComms library functions, so I don't think this would be all that difficult.

Thanks!

Tyler

[Ben-S]

I believe all the packages already allow for this? I have GPRP, DI packages, and a bunch of OE/Custom stuff. All have CAN Slots for the wheel speed inputs already. I have used them to receive ABS data without issue.

What ABS unit are you using? Most modern units have physical output pins that you could wire in directly. This is the better connection method as the update rate is much faster. If you're just using CAN Data as backup by all means that is good practice.

Taking your question out of context though and assuming you just want to receive the specified data, I would do it from scratch. In most instances if you know what you're doing you will have a neater more efficient project writing your own groups. MoTeC has to build those modules not knowing exactly what the end user is going to do, and in most cases that has to include a lot of wasted resources on sections of the module you aren't utilizing anyway. In general creating your own group makes it easier on you later on in your development as well.

[TylerC]

You're right, they do allow for it. I just can't figure out how to set it up. The GPR package doesn't actually utilize the CAN capability, and I can't figure out from what's included how to make it work. Maybe I'm just missing something, I do still occasionally get confused when figuring out what needs to be set up in M1 Build versus what needs to be set up in M1 Tune.

So you say that 'all have CAN slots for the wheel speed inputs already' - which ones are they? How do I determine (or define) which slots those are?

This is in an E46 M3, it's the stock Ate DSC3-ES unit. The CAN updates on approximately 7ms intervals, and the stock DME only uses the CAN to monitor wheel speeds. Right now I don't think we're planning to wire in the actual wheel speed signals, but we will if we find that it's necessary.

Writing our own groups was our plan for the most part. We figure it will be more time consuming on the front end, but it should make the package a lot easier to use in M1 Tune later.

We do want to receive the wheel speed data, but we'd also like to utilize it to implement traction control the same way that the stock DME did. I just don't want to make more work for myself if the 'Dual Driven Wheel Speed with CAN' class will do exactly what I want, assuming I can get it set up correctly.

[Ben-S]

How do I determine (or define) which slots those are?

The ""ECU Receive CAN ID Base" is the base CAN address as a decimal (convert to Hex for most uses)

The "CAN Slot" is more or less a base address modifier ie Base 1280 message 12 would be like saying CAN ID 1292. "Offset" is the offset in bytes. I could give you a specific example if you know your CAN parameters.

I'm sure you already know this but here's a short visual in case you aren't familiar with the above.
https://youtu.be/2m34nQ4i6KQ?t=540

This is in an E46 M3, it's the stock Ate DSC3-ES unit. The CAN updates on approximately 7ms intervals.

I believe that would be 10 updates per revolution at 60mph, that's a far cry from the 60 updates per revolution you get on the actual sensor. That will have a huge effect on traction control algorithms and that's only at 60mph, it would get worse from there.

Writing our own groups was our plan for the most part. We figure it will be more time consuming on the front end, but it should make the package a lot easier to use in M1 Tune later.

We do want to receive the wheel speed data, but we'd also like to utilize it to implement traction control the same way that the stock DME did. I just don't want to make more work for myself if the 'Dual Driven Wheel Speed with CAN' class will do exactly what I want, assuming I can get it set up correctly.

The built in classes will do what you want without modification and as long as you aren't hurting for processor power or need the data in other advanced calcs then there is nothing wrong with using them as supplied.

[TylerC]

The ""ECU Receive CAN ID Base" is the base CAN address as a decimal (convert to Hex for most uses)

The "CAN Slot" is more or less a base address modifier ie Base 1280 message 12 would be like saying CAN ID 1292. "Offset" is the offset in bytes. I could give you a specific example if you know your CAN parameters.

I get the CAN stuff, but I'm still missing something on the Motec side of things...let's try a specific example.

The ID that contains the wheels speeds is 0x1F0. Signal Wheel 1 is defined to be start bit 0, bit length 12, Intel, and unsigned.

In M1 Tune I would assign 'OE 1' to be the 'Wheel Speed Rear Right CAN Slot', for example. Right now though, 'OE 1' doesn't reference anything, it's an empty variable. How do I define 'OE 1' as 0x1F0, startbit 0, bit length 12?

I believe that would be 10 updates per revolution at 60mph, that's a far cry from the 60 updates per revolution you get on the actual sensor. That will have a huge effect on traction control algorithms and that's only at 60mph, it would get worse from there.

That's a good point. Either way, I'd still like to learn how to set up this class properly. I'm sure this process will be the same for all the other CAN sensors, so I'll have to learn it eventually anyway.

The built in classes will do what you want without modification and as long as you aren't hurting for processor power or need the data in other advanced calcs then there is nothing wrong with using them as supplied.

Yep, as I've gone through everything in the GPR, we ended up using a lot more of it than I thought we would. I've got about half a run file now. I mostly just modified the various groups to pull out all the extra stuff we don't need, rather than completely rewriting them.

We probably could have just used the GPR and added a few things to it, but going through it group by group was also intended to be an exercise in familiarizing myself with everything that the Motec can do.

[Ben-S]

The ID that contains the wheels speeds is 0x1F0. Signal Wheel 1 is defined to be start bit 0, bit length 12, Intel, and unsigned.

In M1 Tune I would assign 'OE 1' to be the 'Wheel Speed Rear Right CAN Slot', for example. Right now though, 'OE 1' doesn't reference anything, it's an empty variable. How do I define 'OE 1' as 0x1F0, startbit 0, bit length 12?

Go to "ECU Receive CAN ID Base" and set that to 496 which is the decimal equivalent of 0x1F0

Set the CAN Slot for "Signal Wheel 1" to "Message 0, Offset 0"

That's not a great example to learn from since 0x1F0 already worked out to a multiple of 16 and you're not using a bit offset but that should get you the data.

[TylerC]

Go to "ECU Receive CAN ID Base" and set that to 496 which is the decimal equivalent of 0x1F0

Set the CAN Slot for "Signal Wheel 1" to "Message 0, Offset 0"

That's not a great example to learn from since 0x1F0 already worked out to a multiple of 16 and you're not using a bit offset but that should get you the data.

Okay. That's the part I was missing. I looked at the CAN Block Receive stuff, but it just didn't seem right, and now I understand why. It seems to be a bit inflexible.

The documentation on "ECU Receive CAN ID Base" says it will receive 16 messages starting with whatever it's set to. So if I set it to 496, it should then read 496, 497, 498, 499,...,510, 511 for a total of 16 messages, correct? That takes up the first 64 slots in the "CanBlock Get16 Slot Enumeration", and I can pull whatever values I want from there. That works fine for some of the IDs I need to receive - 496, 499, 501, and 504.

The problem I see now is that I also need to receive 339, 1087, 1552, 1555, and 1557. Can I somehow utilize more than one "CAN Block Receive" class on the same CAN Bus?

[David Ferguson]

It looks to me like you can just instantiate more CAN Block Receive objects. For example, I was able to drag a CAN Recieve Block (from the Classes tab) onto the "User Defined Comms" group in the object heirarchary, and it created new CAN Block Receives objects, each with their own CAN bus and CAN ID Base Values.

I would think you would rename those as appropriate for your application.

[TylerC]

It looks to me like you can just instantiate more CAN Block Receive objects. For example, I was able to drag a CAN Recieve Block (from the Classes tab) onto the "User Defined Comms" group in the object heirarchary, and it created new CAN Block Receives objects, each with their own CAN bus and CAN ID Base Values.

I would think you would rename those as appropriate for your application.

This is true, I tried the same thing. The problem is that when you go to assign the CAN Slot for a channel in M1 Tune, there's no way to select which CAN Receive Block to read from.

As an example, I have a CAN Receive Block under the "ECU" group, and I have a CAN Receive Block under the "Wheel Speed" Group.

If I set "ECU Receive CAN ID Base" to 1552, and I set "Wheel Speed Receive CAN ID Base" to 496, and I set "Wheel Speed Front Right CAN Slot" to "Message 0, Offset 0", it reads its value from "ECU Receive CAN ID Base" and NOT from "Wheel Speed Receive CAN ID Base".

My guess is that it's just not going to work. The CAN Receive Block stuff seems to be far too limited. I guess it's like it says in the Object Help window, "generally not suitable for OE CAN bus integration".