CAN Webinar - Presented by Dave Gallop of DEWESoft USA

At the 1984 Society of Automotive Engineers congress, Robert Bosch introduced a serial bus system aptly named Controller Area Network. Many years later, our industry is now taking full advantage of this breakthrough and the years of improvement that have ensued.

Many manufacturers of data acquisition systems have either partnered with companies or developed their own means of interfacing with CAN and similar controller protocols. DEWESoft has strived to become one of the leaders in combining CAN and analog DAQ technology and has made it easy to take advantage of the immense amounts of data provided by Vehicle Networks.

This webinar with Dave Gallop of DEWESoft USA will provide an overview of all aspects of controller networking from the chronology of development to model standards and operation. It will also show how DEWESoft products can easily retrieve this information and combine it in the time domain, synchronized with analog and digital sensor data.

Transcript

00:00:00 [Music] hello and welcome to this webinar presented by dsoft USA we always mention this at the beginning of all of our webinars if there is a subject matter that is of interest to you please do not hesitate to let us know we can certainly tailor existing webinars and of course we are always interested to know what subject

00:04:22 matter is of interest to our users that said let's get started as with many subject for which we have a passion we like to begin with a little bit of background this helps to understand just what we are dealing with as well as making some aspects of it easier to appreciate then we will look at the structure of can keeping in mind that

00:04:44 understanding the actual composition of a protocol will often help make sense of certain aspects that may appear less than obvious we will try not to get into too much detail and some images may appear for a very brief period this is because we don't want to totally lose the plot we will then take a moment to quickly review the different formats of can can

00:05:04 itself can FD xcp CCP and so on although some of this will be relevant when we get to the last part which is actually interfacing with the various formats how they function and how to make them work including a look at how the additional features available in X3 can help you even when you do not have a database for example we always like to get things in perspective before getting into the real

00:05:29 nitty gritty and in the case of can that is achieved by simply showing an image representing the Empire State Building and stating that a lot of people refer to can as vehicle networks well the Empire State Building has a can fire detection system and we personally wouldn't refer to the Empire State Building as a vehicle the actual system uses can open which is a de facto

00:05:51 standard for many sensors that offer can now again we won't dwell too much on the prean history but worth noting is that most communication protocols exist because of folks like Alexander Gran Bell he of course is extremely well known and recognized as the father of the modern telephone but one person is worthy of note that was a major in the in the US Army gerge o Squire who coined

00:06:16 the phrase multiplexing due to the fact that he basically invented it and of course it is that fundamental technology that provides us with the ability to deal with many of the primary communication protocols that we use today the signals Illustrated represent what early Multiplex and a clock-based state changes may have amounted to the example

00:06:36 Illustrated introduces a number of useful aspects of communication protocols the state binary hexadecimal and time period relationships and we'll cover these later if it were simply binary it could be the 01 011 and so on seen below the signal however if the groups of binary represented a hex value it could be be 4 e CA or decimal 4 12 and 10 Sorry 4 14

00:07:06 12 and 10 or these could be the entire hex equivalent of 4 ECA which is 2,170 in decimal or to introduce a complexity that we will review later the endianness which could imply a value of now jumping ahead because we don't have the time for an extensive history lesson the first introduction of Cam was at the SE well Congress in 1984 in Detroit it was announced by Robert Bosch and they

00:07:41 have to this day remained the Helmsman of the can ship it's worth noting that K as a standard utilizes the N pin DC connector the same as was used in the rs232 serial Communications a coincidence H possibly there are actually only two pins and a reference needed in Ken whereas rs232 uses all nine if you count the ground which actually leads to a very important

00:08:03 aspect regarding can that is that pins are shared whereas in rs232 there were RX and TX dedicated connections perhaps that is another reason that can was preferred over rs232 which leads us to this slide some people believe the reason can became so prevalent and popular was because it could ultimately reduce the amount of copper that was being used in many

00:08:27 vehicles now the y-axis represents yards of meters of copper I suspect that while there may be a very small grain of two to this it should be considered a modern day myth although some large vehicle manufacturers are actually using the frame as the conductor in a single wire can this animation is to emphasize the fact that can is a controller based Network hence controller area network

00:08:51 that implies that the devices are as effective or sorry they are as active as they are passive they can provide almost real time Dynamic augmentation of some systems after all for the older of us remember when you could rotate a distributor to adjust the timing these can perform that same process a thousand times in less than the time it took us to wonder where we left that special

00:09:12 wrench to loosen the distributor clamp there are a slew of acronyms out there and can is a Minefield for anyone new to the arena so I've added a few key ones that you may encounter or hear from time to time don't worry there will be a lot of these before the webinar is over U which as you can see is universal asynchronous receive and transmit is a good one because it does to some degree

00:09:36 bring the whole thing into perspective it is the basis for almost all serial communication systems as well as having an important clue in its name asynchronous as in not synchronous a couple others here are the buzz ones such as xyre which is basically autonomous vehicle-based protocols with redundancy or a collection of others such as GM land

00:09:57 flexray and so on and one that isn't really an acronym ethernet this is really important now because many of the younger guys know it so well they are basically replacing mostly the others with it ironically xcp is a variant of can that sits on Ethernet or I should mention all can or even USB this is really just to illustrate the evolution of some of the protocols

00:10:19 keep in mind that ones like vpw and pwm were really the forerunners of today's can anyway they just didn't have the broad take up that can had and were dedicated to specific manufacturers these were almost fated to Fall by the wayside as they would have been supported by dedicated groups within each manufacturer the worst possible thing was that they really didn't want

00:10:39 to share now this is really just a review of some of the historical implementations of networks as it also includes vpw and pwm and it also suggests individual names as users of specific protocols but the reality is that there are almost likely a massive users of each of the more modern variant each protocol has its own

00:11:02 characteristics one of them is of course the speed the rate at which the information is being passed around the network ironically some of the earlier ones such as sboss were significantly faster than those of today the problem is that speed isn't always related to the bandwidth going fast is only useful if you can get a whole lot of information on it the implementations of

00:11:23 kfd are designed to accommodate those needs flexray kind of does but it is more or less a bone that combines different buses as opposed to a full out protocol some of these have become all but invisible as they have been encapsulated into other systems often via a backbone which is another name for a universal hub to a large degree many of these have either disappeared or have

00:11:45 been incorporated into more conventional descriptive and naming conventions now as we previously mentioned some devices are placed on the backbone flexray utilizes a backbone but really it is the backbone it is is intended to somewhat simplify the combinations of various Communications present and in use today the clue is in the image there is a hardware component

00:12:08 this indicates that it is not just a protocol there is more to it there are a lot of variants of can as well as ISO standard protocols these are to some degree inclusive to one another and so if you see ISO 11898 chances are you were also seeing SE 2411 or a variant therein some of the variants are really intended to simplify things such as sensor interfacing can open describes

00:12:37 the procedure for setting addressing and initializing the communications in a way that just doesn't apply to sj1 1939 for example the electrical type as you will see later the physical layer is important if you need to know how many wires you're going to need to and from devices and controllers some networks will take advantage of the ability to have both two wire and single wire

00:12:59 devices so there is a need to at least have an appreciation for this as we get into the interfaces highspeed can such as kfd is covered in SE 29622 the list of transceivers is growing rapidly there are way too many controllers used in can today or sorry connectors used in can today there are

00:13:23 too many controllers as well this is really to show some common types of connectors the nice thing is that these a pretty standard connector so readily available unfortunately the pin assignments don't follow for example pin 7even for can high on a duub becomes pin six on a j1962 ob2 connector C on a 9 pin Doge and a on a three pin Doge luckily there are usually only two

00:13:48 critical connections so it should be relatively straightforward the potential stumbling block is that there may need to be termination in this interpretation now let's have a look at the structure of can it may not ever influence what you're planning to do on your device but

00:14:06 it is worth noting that can is event driven whereas Flex Ray is time driven it may not matter but in the event that you don't see what you expected to it may be because the event that would have driven you seeing it simply may not have happened there are specific timing requirements for can as you'll see in a moment but for the most part messages will only happen if they were allowed to

00:14:27 happen the tip of this slide is to introduce a concept used in Canam that we will cover later on that is how to deal with things that are really are all happening at at once the Volkswagen fat was one of the most advanced vehicles on the road this image was a tremendous in its day this image was a tremendous way to bring home the nature of the intelligence

00:14:51 incorporated into its design as you can see the model looks surprisingly similar to a human anatomical model I'm pretty sure this was deliberate we won't dwell on these next Pages these are really here to at least show some of the time the timing works on what is an event driven Network these are really just to show some Buzz acronyms that you may hear for

00:15:16 example here TS and of course the phase sigs believe me this is really for the transceiver designer level again quick flash for a moment just to get a couple of other keywords into the conversation synchronization and propagation the fact is that there is nothing on the deck side that should ever infer synchronization this is literally only for the transceiver level however it

00:15:39 introduces a key aspect of can arbitration this is critical for any system that has many devices trying to communicate at the same time again a quick flash here but there is one key phrase in this and that is that the network is passive and only can become active at any one time and this is why candy so fault tolerant and we can explain that later in a more

00:16:02 detailed webinar do you see the similarities of the DB9 serial connection communication connection pins now this illustrates the transceiver voltage characteristics although you may never have to concern yourself with this level of information it is important in an event where you may need to troubleshoot an issue electrical signals are great tell tals

00:16:24 of course more so when something is missing this is really to illustrate a very important difference in single wire can to the more common dual wire one other very important facet is that it introduce series of multi-p speed capabilities of can on the subject of single y can as you can see here the single y can is actually the odd man in the bunch almost

00:16:44 all other implementations a jaw wire and it to some degree makes a little bit of resolve bit of the resolving a little bit easier the state of two wires can be compared with a single wire only one has to be relied on it doesn't mean that it isn't as reliable and that it is actually an important thing to keep in mind there are basically two mechanisms

00:17:07 for defining State these are based on both period and initial State they are respectively known as The nrz non- Return To Zero and the Manchester methods as you can see the timing and no this isn't a contradiction to the earli statement about Cam being an event driven protocol plays a large part in deciphering the equivalent value at any given point and you might want to note

00:17:26 that nrz is the most commonly used format now this image has its uses in this example we're just trying to demonstrate a couple of important features of most networks there are things that need to happen relatively quickly and there are those that do not as you can see from the animation the brake lights are slower than those of the sensors report

00:17:45 in the status of the ABS sensor we have highlighted a couple of things in this image because the concept of sharing information is very important it's also a potential issue when we get information from a deck perspective it just might be that it has been passed around to a number of controllers and devices before we even see it and it may not be exactly the same value as it was

00:18:08 when it originated from its device now this animation is to illustrate a very very important feature of can only one device can speak at a time well actually it really means that only one device can be listened to at a time and if you know on this particular animation that the device 0000 is doing a more than any of the other devices and that's in that's actually deliberate

00:18:34 it's because 0000 in sj1 1939 Doctrine is usually the eec1 the ECU and therefore it will probably have the most frequent and the most required pieces of information that it needs to share with other devices on controllers on the network now the purpose of this set an set of animations is to illustrate the basic functions of the application layer at least to some degree as other layers

00:18:56 can instruct the application layer as to what it should do based on some event under normal circumstances any and all devices on the network can communicate in one form or another this may be just a heartbeat to say that it's still present when you add a deck it also has to have an address a a common and to some degree reserved in SJ 1939 for example is FB the DC then becomes part

00:19:21 of the network any node can request from any node or device that has been allowed to join the network if a device on the network shows an error it can be switched off effectively booted off the network now keep that in mind because if your deck happens to be the device in error the deck could be kicked off the

00:19:39 network and now emphasizing one aspect of Canen that is extremely important to understand is that can is event driven not time driven now sadly we have to accept that there has to be an allpurpose model upon which can as a protocol as well as a system is built on in this case it is the OSI the open standards for interconnects you know it as you

00:20:01 probably use it on a regular basis it is what the internet is built on the good thing about it is that there is a wealth of documentation on it as well if you really want to get into it we recommend a quick review on the very place it lives your browser now unfortunately much of the OSI is abstraction so it needs a little lateral thinking to make sense of it

00:20:23 however as a brief review the proceeding screens provide something of a broad overview of it the physical layer we'll take a moment on this Slide the rest will pass through very quickly with just the title as an explanation the reason for that is because this is the layer that you will interact with the most this is where you will physically connect to the bus as

00:20:44 well as ADD sensors controllers and so on the data link layer is responsible for segmentation and frame manipulation and keep the word frame in mind it gets used a lot the network layer is the equ of your home router traffic management system the transport layer is really the first aid station in the model it checks that Transmissions are

00:21:09 healthy the session layer the point at which devices are checked on the network this comes into play if you need an act and you forget to set it this layer then refuses you entry onto the network in effect as we mentioned before when a deck becomes part of the network it must be allowed to St on the network and it may require that it has an act in order to remain there

00:21:30 the present the presentation layer this makes sense of incoming information and basically ensures that the format is conducive with the system that you are trying to use it on and then finally the application layer if there was such a thing as an app portion of the model this would be it this is where important things such as acknowledgements and decisions on

00:21:48 priority are made now the active passive AK dominant and recessive components are the critical fit factors in can activity that determines what Communications are taking place at what point and which will ultimately be made available on the bus or as it's often referred to get control of the bus now we've alluded to it but not

00:22:12 elaborated on the outcome of the dominant and recessive Parts as well as how ultimately we get the information that is made available sadly to get to this we have to to the rabbit hole and take a look at some key factors such as hex and binary now it's worth being aware that can has a system in place that allows for messages of Greater importance to

00:22:31 get control as we mentioned before of the bus this is important because it implies that some messages may not get through when you expected them to again something we mentioned before therefore an absolutely important facet of can is its ability to deal with the level of importance attached to Communications this is achieved using prioritization and arbitration now note that flexray

00:22:53 has no arbitration as it's time driven in this example we see four compet sets of information trying to get heard and only one can be now this you can see that one message is effectively one arbitration It ultimately will make it through to the rest of the network including you if you're attached however at this point it is worth getting familiar with binary as

00:23:16 it demonstrates much clearer the mechanism that allowed the message to get through now unfortunately we need to appreciate the binary the hex and the decimal for a moment just just to appreciate that troubleshooting can may be a matter of checking bit values and locations or at least hexadecimal values this example is actually the sa1 1939

00:23:38 parameter for engine data the one that comes from the eec1 we mentioned earlier now the PGN the parameter group number is 61444 as defined by the so-called Blue Book this is of course f004 INX and in binary it's one of the easiest because f is all ones zero is all zeros and four is 100 or 0 1 0 0 now let's look at the formats involved

00:24:05 and figure out how we get to a piece of data based on the information that was allowed on the bus now there used to be one then two and now there are basically three formats of can they are can standard can extended and now can FD however the basics construction of a frame has remained to a large degree consistent this shows the outline of a frame it's

00:24:27 almost the same a can FD this illustrates the structure of a can standard and can extended there is a specific number of bits allocated to each component of the frame these vary based on the CRC requirement as well a bigger identifier typically implies there will need to be a bigger CRC to check it and a CRC is the cyclic redundancy check for those who are nonf

00:24:49 familiar with this now as you can see the payload with FD has been significantly increased along ironically with the speed at which the frames can be made available I guess newer Technologies faster better and all that the flex R flame frame is decidely more complex but the payload is a huge Factor bigger even the can FD now you'll notice as mentioned before that the data

00:25:17 portion has grown and so the crc's the cyc Rundy checks have increased dramatically as well the CYCC redundancy checks are basically the check sums if you will to make sure that the message is not corrupted I guess now this is really to emphasize that xcp is actually a protocol that can reside on Ken Ethernet or even USB now because it is a protocol it cires

00:25:40 interpretation as opposed to Dedicated Hardware unlike Flex Ray now in this illustration I have missed a critical player in this but only because this is more like more to illustrate development on a user level and they are inclined to the hardware and primary communication protocols who actually remembers the old PC 104 development platform Illustrated in the

00:26:02 upper left now as you can probably see from this image GM land is fundamentally can with all three speeds thrown in this means that you can configure most of your incoming information in the same way as all Canam would be with an addition of a protocol signal this is something that may be Multiplex and could spread across multiple frames J

00:26:22 just checks the check the box for multiplexed in X3 now this is very common across all manufacturers by far the most common file format used in can applications is the vector DBC this format is really a structed text file it was probably originally created before XML was taken up on a large scale so it didn't quite make that

00:26:44 structure but it is similar the naming conventions are simple bu for example is the frame identifier Bo is the frame wrapper and so on so the creation editing and other interactions with the DBC shouldn't cause too much confusion as you can see it is identify explain repeat the use of CCP is a significant Step Beyond DBC level can this is

00:27:11 because a DBC fundamentally will describe what it is where it is possibly with a how to ask for it but that is about as far as it goes the CCP and xcp level is where you can get the same stuff as well as tell devices to prepare and send very specific pieces of information as well as providing the ability to write entire memory blocks thus

00:27:36 affecting the that information in the first place and great care should be taken when using these beyond the interrogate level although there are probably many more under normal use the chances are that you may access the network in one of three modes these are cow which is the level that transmission Developers for example may use as it allows them an

00:28:00 opportunity to tweak specific par parameters one at a time Dak our crit our typical place of interest is where we can either periodically request a piece of information that is located in potentially a dedicated memory location on a controller or it may be that we actually instructed the controller to make it available at that location and finally we may have defined a set of

00:28:22 specific parameters to be made available from a specific location and followed on with a command that told it that that set information should be broadcasted periodically and then we merely listen out for it and finally the programmer level where entire controller memory Maps can be deployed this is really intended for the electronics development folks and we should in the deck World

00:28:42 avoid this particular activity as much as as we possibly can remember that we can really mess things up if we aren't completely aware of what we put in where now these are can all be uh encapsulated into a single dll or they may have individual dlls always make sure that you have these dlls available to you now the fact that xcp and CCP can

00:29:04 provide access to a programming level on the network should not be taken lightly have you ever had an opportunity to update the bars on a computer do you remember the warnings that any loss of power or interaction during the process could render the computer unusable I'd keep that in mind when using xcp and CCP at anything other than a Dack level now it's important to note that

00:29:25 way as previously mentioned xcp is capable of dynamically influencing a piece of information it is also important to note that while some folks May intimate that it is real time it isn't with anything that involves serialized Communications there will always be a face GE the really nice thing about protocols such as xcp and CCP is that you can get a lot of

00:29:44 information that simply would not be available on can especially just the legislated can that said in deck mode you may well have access to data much sooner than it may have become broadcast for example as mentioned earlier when we were talking about the uh the availability of messages this also means that you could be seeing something that hasn't been manipulated by the scaling

00:30:06 factors of those other devices and the other ring no offsets and possible algorithms so keep that in mind if the numbers are not quite what you expected to see the a2l format as with the Rog that are used in xcp and CCP are fundamentally programms that is to say that they are akin to the BIOS that you may write to your home PC therefore

00:30:27 since that is their intended purpose they can get pretty large the animation on the right illustrates just how large these files can be we started by scrolling and quickly gave up and started using the scroll wheel so down here if I play this to show you you'll see here we're just scrolling through and you can get an idea of the length of this file by the amount of time that's

00:30:49 remaining in this video and I'm certainly not going to sit here for 5 minutes and 42 45 seconds to show you this entire file it's huge now we can start looking at what we see and what we are interested in when we go to the interfacing we may need to construct the entire anticipated frame this particular PGN is from the original sa Blue Book as you can see

00:31:15 there are some components that are defined in a couple that are potentially and we say potentially because we probably should be prepared for possible changes subject to some change these are the priority and the source theoretically the PGN otherwise would be constant oh by the way by the way this is just so we know what we're looking for at the in the proceeding

00:31:37 payload now this is to illustrate a slightly different approach by a specific manufacturer and this by the way is why there are things like the OBD2 standard in place that uses a p or or protocol identify in this example you see the vehicle speed being defined as being in message ID 02000 keeping in mind that generally at this level parameters are described by hex almost

00:32:00 always then it describes that it starts at bit Z 16 bits long akr word has a scale of 0.125 no offset and it's signed although there there is no guarantee most 11-bit messages are Motorola based the most 29 bits are Intel based that's basically big Indian and little Indian and don't confuse Indian with bit ended and we would like to wrap this up by starting with a video of some data

00:32:25 then showing you how easy it can be get for to this from your can signal in as fewer clicks and as little eort effort as possible so you see here a video playing which is just actually monitoring engine speed from an sa j1939 and you can see the engine start and you can see it idling and we've just set up a very simple display just to show that and we're going to manipulate

00:32:47 that in just a moment so we uh here we are adding a digital meter in and this digital meter can actually show the heximal values as they're coming through through the bus so we'll move on so always start by making sure that you have your Hardware configured correctly and any extensions that you plan to use added an active it's always a good idea to check that you're in an

00:33:13 acknowledge mode for most Automotive applications and really important at this point check that you have the required termination sorry we only alluded to that earlier but it is very important and it's 120 ohm resistor across can high and can low and that's only if it's required here we are demonstrating the behavior of some Hardware when analog

00:33:34 and can data is collected at the same time it also shows the ease with which a completely new can signal can be extracted if you know where it is and what the effectors are on the signal we start by adding a strin gauge channel to the analog inputs in this example we start from scratch it's a 350 ohm quarter bridge and we can take advantage of the shun to calibrate the channel

00:33:55 quickly and you'll probably notice that we we are compensating for the lead wire resistances we are balancing it and we are making sure that the shunt equivalent represents the anticipated value that was displayed so now we can actually see that our Target was 29 2914 and it actually went to 2915 now I'm just changing the uh the limits on this one manually just so that

00:34:19 I can see the data a little clearer then we have a quick glimpse of the can Source this is actually the same as EC on a truck so we're going to take a quick look at the signal we're getting from the strain gauge first to make sure that that's working okay and we can show you the combination of the two so now we move over to the can and when we move over to the can the first

00:34:43 thing we do with the can is we check to make sure that we're on the right can uh this is a quick glimpse of the uh the can signal generator that we're using which is simulating uh an entire can stream coming from a truck so it's going to replay a startup event as you saw in the previous video and that way we know we're talking the right

00:35:04 language then you'll notice that when we go to the can interface that we're getting a bunch of error messages the reason why we're getting this bunch of error messages is because we're at the wrong Speed Most sj1 1939 implementations run at 250 KOB and here I'm just changing it over so that I can view it as a hexadecimal value as opposed to the binary values

00:35:26 because I personally find the hexadecimal a little bit easier to reference so now I've identified that I'm pretty sure that that f004 that we spoke about before the ec1 message is available so what we do first is we basically make sure that we have selected that message because it's being broadcast since we use the scan option and then we know that engine speed is

00:35:49 located at bit 24 and it's 16 bits long and that the scale factor is 0.125 you can probably remember that from the previous screen show in the blue book so we add those values in and we can see an equivalent down in the lower right hand corner almost immediately now we can start reviewing

00:36:11 the analog and can data visually and all we're going to do here is add the can signal in at the same time as the analog signal and that way we can see the analog signal and the can signal happening together now in this particular case what we're going to do here is put that engine message so that we can see the entire message that we're filtering out if you will and we have a

00:36:33 nice analog display to show the engine speed and as you can see right now when we switch to engine speed we're in the idle mode and if we sit here long enough we can actually watch the engine rev up and uh then we'll see the data coming from the string gauge at the same time so here we're just setting some limits so that we can actually see when the value exceeds a defined

00:36:57 value at this case we're going to say any more than 1250 RPM is a warning limit I'm going to minimize these so that it's a little bit clearer and now we're going to do our strain gauge to show The Strain gauge data so there's our strain data and here is our can data and right now the engine is going to restart so we'll see the engine restart and we'll see the can

00:37:21 data change as the engine restarts so it's pretty straightforward to add a can signal and in this case an analog signal into the same test now we could have loaded just simply loaded a database so we load up a DBC file when we load up the DBC file we'll see that particular message if it's available very quickly if it's included in DBC it will automatically

00:37:47 translate that message into meaningful engineering units if you will now the xcp if you want to use xcp or Lin it's a plug-in so these could be you these could be loaded in using the option dialogue once they're added in they become additional icons on the top of the screen and then all you need to do is set the communication parameters such as IP address for XP over ethernet

00:38:09 and then loading your a2l file so it's pretty straightforward to even do something similar to XP or L and so on now kfd um the same sort of process again set your act Behavior once you've set your act Behavior make sure you're speaking at the same speed and then load a database pick your signals and you would have almost instantly noticed the difference

00:38:35 between the can standard can extended and the can FD in so much as you now have 64 bytes of data that you can pass out so it gets pretty big and finally if you want to Simply see and record the OBD2 standard messages add the OBD2 extension and select the respective OBD2 file which may not be required and then select what you want to use and it's a matter of

00:39:01 just telling it whether you want to use it or you want to remain unused a very powerful tool in the developer Arsenal is the ability to broadcast on can this is particularly useful if you are testing the behavior of a sensor which you plan to add to a network it is also a very useful tool if you want to make peripheral data available to devices on the network in

00:39:27 this example we start by adding our sensor as we did before Again The Strain gauge will balance we'll compensate for lead wire we'll apply the shunt to make sure that it's correctly calibrated and then we'll just set our full scale limits to a slightly lower value than before and once we've set our full scale values the channel is ready now for this

00:39:57 example we're going to add a video channel in as well so that you can see the actual event as it's happening so I'll just quickly set up my camera which I have placed over the strain gauge which is on a small piece of brush steel and then we go into the can so we're going to set our can message for TX which is transmit just like all can

00:40:22 messages to have a wrapper or frame and then the component parts in this case I'm going to simply add my strain gauge as is onto bit location one and make it 2 bytes long so I start off by telling it I want to use ff01 set it to 10 milliseconds so that it repeats pretty frequently call it St strin gauge out doesn't really make any difference what

00:40:45 I call it doesn't really matter what units I put on there because I'm just going to be broadcasting this on can and then I'm going to assign it to the Strang gaug Channel and then immediately once I've set it to the correct sign I can see in the lower right hand corner some values as I bend the string GA so I can see the can signal is changing so I'm now going to use the

00:41:05 transmit option and to look at the data just set up my display here so you can see everything once I've set everything up so you can see it all turn the camera off which is a kind of pointless one in the Stream there's my string gauge Channel I'll add in my video and I'm going to place it at the top of the screen here so that there's a little bit

00:41:26 of room to put put in the uh the the device I'm going to use to actually monitor the can signals that are coming from the device so there is my video so I can see it happen and then I'm going to use just testing it out quickly and then I'm going to use a device called the peak device to actually monitor for the can signals and you'll see the can

00:41:49 signals are changing here as I bend the strain gauge it really is that simple so can is fundamentally free data it can extend Way Beyond data when you use protocols such as xcp and CCP and so on but at the end of the day it can provide a wealth of supporting information that is already there in a

00:42:14 matter of minutes a 64 Channel test with loads strains temperatures and so on can be enhanced with peripheral and supporting information from can this could overshadow the analog data by significant amounts but the nice thing about it is all you have to do is add a couple of wires and you were done and the keyword is free so once you have your DSS can or you're serious with can

00:42:37 you are ready to go we'd like to thank you for participating in this presentation and don't for don't forget to keep an eye open for future webinars we'll now open it up for any questions and answers you can type your questions into the chat not that we will read out and answer as many as possible in the time available if you want to ask a question offline or

00:42:57 we run out of time please contact us using the information displayed I will be joined by John Miller and Matt inquest and Mike Davis along with our support team in Ohio so thank you once again we are now open for Q&A