CAN Bus Communications Decoded: Step Four: Cause a Variable You Are Looking For to Change
Watch This Course
$199 USD
-OR-
Or
8 easy payments of only $24.88
Instant access. Easy checkout. No fees.
Step Four: Cause a Variable You Are Looking For to Change
05.27
| 00:00 | Now we know we've got our traffic being displayed correctly, I can make some physical inputs to the device and try and see if our data is going to change on the bus so this is step 4 of our process. |
| 00:14 | So I'm simply going to press our start/stop button and I am seeing absolutely nothing happen on the bus traffic there. |
| 00:23 | Now when you strike this situation don't be disheartened, probably just means we need to do a little bit more research and if I pop over to the documentation for our keypad here and this is from Blink Marine. |
| 00:37 | Can actually scroll through this and it tells us that the device is using a communication protocol that sits on top of the CAN protocol called CAN open. |
| 00:48 | Now getting into those higher level communication protocols that are sometimes used is a pretty in depth topic and it's outside the scope of this course but if we read through this document, it's actually going to tell us the individual messages that we need to send to our device here to actually interface with it and enable it to get its output back onto the bus. |
| 01:11 | So having a look here, we can see, scrolling through we've got a few different messages that we can send it. |
| 01:17 | One of these is called start CAN open node. |
| 01:22 | So that's telling me that in order to receive a reply from a button press on this device, I first have to send it a message to enable it or essentially turn it on to allow it to then send its output back onto the bus. |
| 01:37 | There is another message that we can send it which is the reset CAN open node message. |
| 01:43 | By sending this, it's actually going to reset the device and return it to its default power on state. |
| 01:49 | Now in this instance I'm actually going to send that reset message first because you'll remember when we first powered this on, it did a little introduction for us, flashing its lights so I would expect it to do the same thing if I command it to reset via the CAN bus. |
| 02:06 | So looking at what we have to send here, we're going to have an identifier of 00, byte 1 is going to be 81, sorry byte 0 is going to be 81 in hex. |
| 02:18 | Byte 1 is going to be XX in hex which is going to be the ID of the keypad. |
| 02:23 | But if I just make that 00, that's going to reset all the keypads that are connected to the bus. |
| 02:30 | We've only got one there at the moment so just for this testing that's the command I'm going to send and bytes 2 to 7 are not used. |
| 02:39 | So it gives us a wee example down the bottom here as well just to really spell that out. |
| 02:44 | Direction to keypad, identifier 0, format standard, message 81 15. |
| 02:51 | I think 15 is the default ID for most of these keypads as they're configured out of the box. |
| 02:56 | I'm just going to send 00 'cause that would cover every keypad that was on the bus. |
| 03:02 | So if we pop back to our software here, transmit new and we'll just create that message so we've got ID 0, it was a length of 2 bytes, I want to send 81 in hex and 00. |
| 03:16 | I'm not going to give it a transmission period because that would wait for that period and then transmit the message again and it would just continue to do that. |
| 03:25 | By not specifying that at all, I can actually just double click the byte here and it will send it. |
| 03:33 | So just once, so we'll go ahead and do that now. |
| 03:36 | You can see we're going through our startup process here again so I know that the keypad has received that message correctly and has responded as I expect. |
| 03:44 | I also saw the traffic light blink on our Sysworxx CAN analyser there so I know that traffic was being sent down the bus. |
| 03:53 | The last part of our 4th step of this process is going to be enabling the keypad. |
| 03:59 | So as we press a button on it, it will actually reply back onto the bus. |
| 04:03 | So heading back to our documentation quickly. |
| 04:07 | If I scroll up to our start CAN open message I can see that I need to send it a message with identifier 00, byte 0 of 01 and then byte 1 I'm going to make 00 as well because that's going to cover all the keypads we could possibly have on the bus. |
| 04:27 | Bytes 2-7 again are not needed so we won't be sending those so we can just see the clarification of this message down the bottom here. |
| 04:36 | So transmit new, 00, length of 2 and we want it 01, whoops, 01 for the open command and then 00 to cover all devices. |
| 04:53 | So I can send that and I should see my transmit traffic green LED there blink. |
| 04:59 | Which we have and now if I press a button on our keypad here we should see some traffic coming back down the bus. |
| 05:07 | Which we do. |
| 05:09 | We've got our message here on PID 195 in hex, a length of 5 and then some data bytes here which because we're viewing in persistent mode as I press the buttons on our keypad we can see changing. |
