PCLink - CAN Setup Confusion - Multiple CAN ID's

[Goingnowherefast]

Hey guys,

I've got a quick question that I haven't been able to find a resolution to in the help manual. Obviously CAN messages have a unique hexadecimal identifier which is used for arbitration. I am very confused as to how the CAN Setup has two ID's for a single message. Let me give an example:

 

I have a example "Transmit User Stream 1" which has a message ID of 0x242 (578 in decimal). In that message, I am trying to send Engine RPM in Bytes 2 & 3. Thus, I select ID (decimal) of 578 on the "mode" page of the CAN Setup.

Now, changing tabs to "Streams" I create my stream with a single 8 byte frame under Stream 1. But now, I have another ID (decimal) option. Do I put 578 there as well? Does this mean I need a singular "User Stream X" for each individual CAN message?

This is confusing as CAN messages will only have one ID as seen here:

 

Can someone shed some light on what this means? Which CAN ID is the "real" one?

 

Thanks in advance!

 

[Vaughan]

52 minutes ago, Goingnowherefast said:

This is the CAN message ID, note it is entered as a decimal not a hexidecimal value here.

53 minutes ago, Goingnowherefast said:

This is the Frame ID, if you are sending multiple frames of different data on the same CAN ID then you need some way to differentiate them, you would give each frame in the stream a different Frame ID and that Frame ID is stored in of the data bytes. Have a look at the generic dash stream spec in the help manual if you want to see an example of multiple frames on one CAN ID

[Goingnowherefast]

25 minutes ago, Vaughan said:

This is the CAN message ID, note it is entered as a decimal not a hexidecimal value here.

This is the Frame ID, if you are sending multiple frames of different data on the same CAN ID then you need some way to differentiate them, you would give each frame in the stream a different Frame ID and that Frame ID is stored in of the data bytes. Have a look at the generic dash stream spec in the help manual if you want to see an example of multiple frames on one CAN ID

Ah, okay so it's effectively multiplexing no? Fitting multiple signals into a single (or multiple) data byte within one message. Two questions from there:

 

1. What's the reason for this? The "Generic Dash" has so few messages it doesn't make too much sense to use multiplexing instead of simply having 3-4 CAN messages. Many aftermarket controllers don't have the ability to utilize multiplexing.

2. So from that, is there anyway to fit multiple messages (for instance 0x101 and 0x102) into one "User Transmit Stream"? Or does it have to be separate?

 

It's super interesting to me - I always laugh when there's a language/semantics barrier. The first time Adam told me he was "snowed in" I was like... uh, it snows there? We don't use that expression because you can actually get snowed in lol (it's quite common).

[Vaughan]

15 minutes ago, Goingnowherefast said:

Ah, okay so it's effectively multiplexing no? Fitting multiple signals into a single (or multiple) data byte within one message. Two questions from there:

Like another address in addition to the CAN ID yes

15 minutes ago, Goingnowherefast said:

What's the reason for this? The "Generic Dash" has so few messages it doesn't make too much sense to use multiplexing instead of simply having 3-4 CAN messages. Many aftermarket controllers don't have the ability to utilize multiplexing.

Generic dash has 14 frames and so would need a similar number of CAN IDs.

One reason would be that using fewer IDs reduces the chance of collisions with other devices that can't be configured, especially when using one ID instead of forcing several consecutive IDs (which you have to do if you want to define a setup in a single channel while having the IDs not hardcoded).

Yes not all aftermarket controllers have the ability to utilise Frame IDs but you can choose whether or not to use them and so can support both (Set the Frame ID Position to None if you don't want a frame ID in the message).

15 minutes ago, Goingnowherefast said:

So from that, is there anyway to fit multiple messages (for instance 0x101 and 0x102) into one "User Transmit Stream"? Or does it have to be separate?

When using custom streams each CAN ID needs it's own channel, if you're running a bit short on channels you could use the CAN File setup in addition to the normal custom CAN setup.

[Goingnowherefast]

On 12/30/2024 at 6:47 PM, Vaughan said:

Like another address in addition to the CAN ID yes

Generic dash has 14 frames and so would need a similar number of CAN IDs.

One reason would be that using fewer IDs reduces the chance of collisions with other devices that can't be configured, especially when using one ID instead of forcing several consecutive IDs (which you have to do if you want to define a setup in a single channel while having the IDs not hardcoded).

Yes not all aftermarket controllers have the ability to utilise Frame IDs but you can choose whether or not to use them and so can support both (Set the Frame ID Position to None if you don't want a frame ID in the message).

When using custom streams each CAN ID needs it's own channel, if you're running a bit short on channels you could use the CAN File setup in addition to the normal custom CAN setup.

Gotcha, yeah I definitely get that reasoning. From that, I have two questions as I have complete control of what I need to send/receive to our controller.

1. I believe using the Custom CAN File may enable me to do what I'd like. I've created two streams within the Custom CAN File - 0x3E8 (Transmit) and 0x3E9 (receive). Within these I have enabled a few parameters (0x3E8 has Engine Speed, ECT, & CEL Status) and (0x3E9 has wheel speeds from Chassis). I am unable to save this setup because of the following error code (pictured). I have uploaded the CAN streams if you'd like to take a look.

2. I'm fairly confused about the CAN scaling methodology after reading the CAN help. Unless I'm missing something it seems needlessly confusing - normal controllers and industry standard programs like VECTOR hardware uses a simple scalar factor & an offset to provide the physical to hex conversion. Link uses a multiplier, divider, and an offset. What I don't understand is how something such as ECT works. For instance, if you select the "Generic Dash" in CAN Modes, you guys have ECT as a 16 bit signal, intel, no scalar, unsigned, with an offset as +50. For instance, a physical value of 0°C gives you a raw output value of +50. What is the purpose of having such low resolution on a 16 bit signal with a positive offset?

 

 

Nick_E46_Stream_1.lcs Nick_E46_Stream_2.lcs

[Vaughan]

3 hours ago, Goingnowherefast said:

I believe using the Custom CAN File may enable me to do what I'd like. I've created two streams within the Custom CAN File - 0x3E8 (Transmit) and 0x3E9 (receive). Within these I have enabled a few parameters (0x3E8 has Engine Speed, ECT, & CEL Status) and (0x3E9 has wheel speeds from Chassis). I am unable to save this setup because of the following error code (pictured). I have uploaded the CAN streams if you'd like to take a look.

You have a CAN ID of 0 for stream 1, CAN Files contain both the stream and channel data in the file.

You can do the same CAN functionality with CAN Files and normal user defined CAN, CAN Files just enable you to password lock the CAN information, if you don't need that functionality then just use the normal user defined stuff, I only mentioned CAN Files as a way to get more than 10 CAN Channels (more than 10 CAN IDs).

You also have Stream 1 set as a receive and I assume in stream 2 you are trying to write directly to the Wheel Speed runtimes instead of writing to CAN DI Frequency runtimes and then using those as the wheel speed inputs.

3 hours ago, Goingnowherefast said:

I'm fairly confused about the CAN scaling methodology after reading the CAN help. Unless I'm missing something it seems needlessly confusing - normal controllers and industry standard programs like VECTOR hardware uses a simple scalar factor & an offset to provide the physical to hex conversion. Link uses a multiplier, divider, and an offset. What I don't understand is how something such as ECT works. For instance, if you select the "Generic Dash" in CAN Modes, you guys have ECT as a 16 bit signal, intel, no scalar, unsigned, with an offset as +50. For instance, a physical value of 0°C gives you a raw output value of +50. What is the purpose of having such low resolution on a 16 bit signal with a positive offset?

The Link multi, divider and offset work like a scalar and an offset but instead of having a decimal capable scalar you effectively have a fraction that you are multiplying it by.

The Generic dash CAN Stream is something that has existed in pretty much the same form since at least Link G4 (3 generations of ECUs ago) and hasn't changed other than extra frames being added to it so that everything is backwards compatible, I can't speak to as the exact reasoning for all the scalars and offsets it uses but I assume it was something to do with how the runtimes were stored in memory in the earlier generations of the ECUs and having a consistent layout shape.