PDM Installation & Configuration: CAN Inputs
Watch This Course
$149 USD
-OR-
Or
8 easy payments of only $18.63
Instant access. Easy checkout. No fees.
Learn more
CAN Inputs
11.56
| 00:00 | - In this course module we're going to look at using CAN bus inputs to the PMU for our device configuration. |
| 00:06 | This topic is closely related to the module on using CAN bus enabled keypads however we decided to break the two apart because using a CAN bus keypad with your PMU will usually mean using pre determined communication profiles and a more integrated setup system. |
| 00:22 | But it's also possible to use general purpose CAN enabled devices to get data to the PMU. |
| 00:27 | Once again we won't do a deep dive into the technical specifics of a CAN system as this is a pretty in depth topic and we have another whole course dedicated to the subject. |
| 00:35 | But we will assume some familiarity with how the CAN protocol works. |
| 00:39 | There are 2 main ways integrating CAN with your PMU installation can be really helpful. |
| 00:43 | Flexibility in configuration and wiring simplicity. |
| 00:47 | This flexibility has been a continuing theme throughout the course and using CAN here really adds to it. |
| 00:54 | Specifically it lets the PMU get access to sensor signals and other pieces of data without the need for any physical wiring changes. |
| 01:01 | This is where the wiring simplicity benefit is as the PMU can get access to a huge array of signals from around the vehicle using only 2 wires, CAN high and CAN low. |
| 01:12 | To demonstrate this, we'll have a look at an example of configuring our Ecumaster PMU16 to communicate with a race car steering wheel that has various buttons and dials which are read and communicated via a CAN switchboard. |
| 01:25 | The wiring simplicity benefit here is a pretty big deal as getting signals to and from a part of the car like the steering wheel which rotates in relation to the rest of the wiring and typically has a quick disconnect coupling can be a little problematic. |
| 01:41 | One solution to this is to use a flexible curly cord, either attached directly to the wheel itself or to the steering column further down with a quick disconnect coupling that includes a passthrough connector, then connecting the column to the wheel. |
| 01:55 | Either way, if we move away from having every button or dial on the wheel needing its own wire and instead have the switch and dial states read on the wheel and sent out via CAN, we now only need to make 4 wire connections, power ground, CAN high and CAN low. |
| 02:13 | This will be more reliable and cheaper. |
| 02:16 | Going to show an example here of getting our CAN enabled steering wheel here talking to our Ecumaster PMU16, in particular reading the state of these buttons here and the position of these rotary knobs. |
| 02:29 | So we'll just get our power supply switched on again and get our enable power sent to our PMU, you can see we've got our LED on there, showing that we've got power and I've got a connection on our software. |
| 02:44 | Now I've set up one of the output channels on our PMU here as always on. |
| 02:49 | You can see it's output 10 and that is actually providing power down to this connection which is power and ground to the steering wheel electronics and we've got our CAN high and our CAN low connection in there as well. |
| 03:02 | They're connecting back to the CAN 1 channel on the PMU16 here. |
| 03:06 | Now the CAN setup is going to be different for every software on the market. |
| 03:10 | But we'll get stuck in with our PMU16 here and show how it's done for this iteration. |
| 03:17 | So the first thing I need to do is set up a CAN bus message object and this is the way that you set up the Ecumaster suite of devices to talk to a particular CAN bus. |
| 03:30 | Then you go down the path of specifying particular messages that you want to pull out of that message object and defining those to be different variables or different values and have scaling. |
| 03:42 | So we're going to leave the name here as default, just being message object 1, the CAN bus we're connected to though is going to be CAN 1. |
| 03:49 | Now the base ID I know that the electronics on the steering wheel here are communicating with CAN 1 at 1 MB per second and the base ID is OX700 and that's in hex so we are in OX, if I put 700 in here, it's a standard ID not extended. |
| 04:11 | You can see I've got some data coming through already, this is quite a nice feature of the Ecumaster software that it gives you a live readout, that's actually really useful when you're setting stuff up 'cause it's nice to get that instant feedback when that setting is correct. |
| 04:25 | However I know that this steering wheel actually spits out 3 frames of data, there's not 3 being an option here so we'll choose 4 and you can see we've got data coming in here now. |
| 04:37 | Quick sanity check I'm going to perform at this stage is I'm just going to look at some of this data. |
| 04:43 | Now the format that it is output from the CAN switchpad is actually available from the documentation which is excellent because we're going to need to know that when we're setting up the particular variables in the software but looking at the raw CAN datastream here I can still get an idea and make sure things are making sense. |
| 05:01 | So I know in our first message that's coming through here, this first frame on OX700, these first 2 bytes of data form a 16 bit big endian value, that's from that documentation and they are the millivolts that are being seen from our rotary position switches here. |
| 05:26 | Now these rotary position switches are nothing more than an adjustable resitor divider. |
| 05:33 | Each position of the switch hooking the output to a different point in that resistor divider which is going to give a different voltage reading. |
| 05:39 | So the number we're seeing here is just going to be the hexadecimal representation of that voltage in millivolts. |
| 05:46 | So if I take one of our knobs here and I switch it, we can see on OX700 here, we've got that first byte of data is changing. |
| 05:57 | So good sanity check to perform at this stage to absolutely make sure that data is coming through. |
| 06:04 | So I can select OK and we're going to accept this CAN bus message object as being correct and now I can set up a CAN bus input and what this is going to do is it's going to take the raw data that's going into that message object and it's going to segment it out, allow us to select particular bytes of data, configure them how they should be reconstructed, little or big endian and apply any scaling that we need to to those as well. |
| 06:32 | So this variable here, I'm going to call it C because it's a CAN bus input and I'm going to call it rotary pot 1. |
| 06:43 | And the message object we're going to link that to is going to be the message object we've just created and we know that the information around that rotary pot position is in the first message that's being sent out, so that's on the base CAN address, so we do want 700 in here. |
| 07:02 | The data format though is not 8 bit unsigned, it's 16 bit unsigned and it's big endian. |
| 07:10 | Byte offset is 0 because that data is at the very front of that CAN message and looking at this here you can also get this from the documentation for that CAN keypad but there's actually no scaling applied to that value. |
| 07:24 | What we're seeing here, if this is our data in hexadecimal, it's got our result down here, that's simply that hexadecimal turned back into decimal form which we'll be more comfortable reading. |
| 07:36 | So currently the output from this rotary potentiometer, this resistor divider bridge, back to our CAN switchpad on the steering wheel here is, we'll call it 490 millivolts. |
| 07:49 | And if I go through different positions, we can see we get to 960 millivolts, 1400 millivolts, 1800 millivolts and call it 2250 millivolts. |
| 08:02 | So those are our 4 different positions there sent as 4 discrete voltage levels. |
| 08:08 | So our potentiometer here is definitely being read as an analog voltage level. |
| 08:14 | Even though it has discrete steps that it's set at, they are still not 0 or 5 volts, they do vary in between there so it's still an analog voltage. |
| 08:26 | So I can accept that as being correct and then we'll get our other rotary potentiometer being read there as well. |
| 08:34 | So once again I'll select this and I'll use our duplicate feature. |
| 08:38 | And it's already named this correctly for me as rotary pot 2. |
| 08:43 | But now actually I want to increase the byte offset because it's not bytes 0 and 1, it's bytes 2 and 3 that I want to read so if I increase that to 1, that would give us bytes 1 and 2 which wouldn't make much sense. |
| 08:56 | If I increase that to 2, now it's reading bytes 2 and 3 and all the other settings are correct. |
| 09:01 | So watching our result value down here, If I turn our other potentiometer, we can see we cycle through those values in a very similar way. |
| 09:12 | We can accept that and now inside our PMU software we've got our variables inspector, we can see we can set those to different values and we would be able to set up functions or tables inside the PMU software referencing those values. |
| 09:31 | It would be a really similar scenario for setting up any of the digital button presses on our steering wheel here or in fact even the gear shift request signals from the switches on the back of the wheel here too. |
| 09:44 | Now you will have noticed that we read an analog signal with the PDM in that example, being the different voltage levels corresponding to different switched positions. |
| 09:53 | This is an excellent facility as it lets us get almost any sensor signal we can think of into the PMU via CAN and configure the PMU to respond accordingly. |
| 10:04 | Another common use case for this could be transmitting engine coolant temperature data to the PMU and then having the PMU determine when to switch on or off radiator cooling fans. |
| 10:14 | The other way this could be done is to have the ECU determine the switching temperatures of the fans and communicate this to the PMU as simple switch on or off commands that the PMU obeys. |
| 10:26 | This leads to the question of how to determine which device we configure to be responsible for that control logic. |
| 10:33 | Now there isn't a simple single answer to this question as either approach will get us to an acceptable end result. |
| 10:40 | As a general guide though, I try to think of a part of the system like this as a chain. |
| 10:45 | It begins with the engine coolant temperature sensor which would be read by an ECU and then communicated to the PMU which then controls the fans. |
| 10:55 | In a chain like this, I try and have the last configurable element in the chain perform the control logic. |
| 11:01 | So in this situation, that would be our PMU. |
| 11:04 | The reason for this is all about maintenance and further modification of the system in the future. |
| 11:10 | By adopting this approach, I'm able to come back to this at a later date and know where the control for the fans would be programmed without needing to go looking for it. |
| 11:18 | There isn't a 1 size fits all solution for every scenario but if you try and stick to a pattern, build your own routine around this, it will make future modification much easier. |
| 11:28 | In this module, we've looked further at CAN inputs to the PMU and in particular, how we can program the PMU to read data from other devices and use these values to drive that PMU programming. |
| 11:40 | Using CAN communications dramatically increase the flexibility of the system as well as simplifying the physical wiring. |
| 11:47 | Being able to read data from the CAN bus in a vehicle makes future changes and modifications much simpler. |
