Extract j1939 Can signals with cRIO-9025 and NI9853

[tokar]

I havent tried GredW:s example yet, but im on it.

I have attached my code with U32 Raw data example in probe.

I also put my FPGA code just to highlight that i will lose information if messages comes faster than i read.

But that is not important for me. Just wanna illustrate the comlete picture.

[GerdW]

Hi tokar,

---

@tokar wrote:

I havent tried GredW:s example yet, but im on it.

I have attached my code with U32 Raw data example in probe.

---

These are your values shown in hex:

When my memory is correct then element #2 is the ArbID ( 0x0CFFE909 + additional config bit), element #3 contains the data/payload length and element #4 & #5 contain the payload of your CAN message…

(Element #0 & #1 contain the timestamp when the message was received.)

Another suggestion: Get rid of additional bits in the ArbID by AND with 0x01FF'FFFF (clear the upper 3 bits of this U32 element). Then try the FrameConversion function from XNet…

[ZYOng]

If bit 29 (20000000 hexadecimal) is clear, this ID uses the standard format (11-bit). If bit 29 is set, this ID uses extended format (29-bit).

Reference: CAN Output

However, NI-XNET uses the same definition. I can convert your data without any problem. 

[tokar]

Thanx for your reply,

I have started to look into how the frames are build to be able to divide them to parts.

But im a little confused.

I have found some code here that i used to divide a message into parts.

https://forums.ni.com/t5/Example-Code/J1939-Transport-Protocol-Reference-Example/ta-p/3984291

With this i have looked at the message ID.

I have tried looked at some incoming messages when running my code and serched for them in my dbc file but im not able to find them...

So i still think there are something in the ID that is not correct to use it in "Xnet Convert (Frame to signal)"

Maybe my extraction of ID is wrong?

I have lookded at message TRF1 in my .dbc file, in a text editor and compared it with Xnet database editor.

I found that the editor says TRF1 har ID: 2566846718 and database editor says ID: 419363070.

If i remove the last 3 bits i get the the same result for both, 419363070.

Looks lite the Xnet database editor removes the last 3 bits.

When i make a Xnet session i use the dbc file so maybe the message ID must be without the last 3 bits.

After looking at a random message ID i removed the 3 last bits.

But in my program bit #29 is set. In my example above bit #31 is set.

Explanation of probe:

29: Incoming ID

30: Convert ID to boolean

31: ID convert sets last 3 bits to False with the OR function

32: Outcoming message without 3 last bits in decimal form.

Im thinking that the incoming messages or perhaps parts of the Array of U32 are coming in reverse order..

At least something isnt right here and i cant find out whats wrong.

Maybe my conversion is wrong when i put the message apart?

I have tried to search for the message ID in my .dbc file after removing the last 3 bits but im still not able to find them. So the ID must be wrong in some way. But i dont understand how.

[ZYOng]

Let's handle this one-by-one.

For the U32 data you shared earlier, the arbID is 0x0CFFE909. Are you able to find this frame in your DBC? Were you able to use XNET Convert Frame to Signal for this ID?

[tokar]

Im not able to use Xnet convert Frame to Signal for that ID. Not 0x0CFFE909 and neither 0x2CFFE909.

And i cant find the the ID in my .dbc file. Im really confused.

As an example i mark what i revere as the message ID in one of my messages in .dbc.

Please correct me if im wrong.

[tokar]

What .dbc file did your use for conversion?

0x2CFFE909 = 00101100111111111110100100001001 that is 32 bits.

If i understand correct bit 30 is the one thats deciding if its an extended 29 bit message or not.

In the example here its a extended message.

If i remove the extended bit i get this, 29 bits

0x0CFFE909 = 01100111111111110100100001001

Still i cant get any match in my .dbc file regarding message ID.

Maybe i have misunderstanding something and need an explanation 🙂

[ZYOng]

It is a test DBC I created using NI-XNET Database Editor.

The ID is 0d2365581577 or 0x8CFFE909. So basically, DBC will set bit 31 to 1 and XNET will set bit 29 to 1 for extended ID.

Since you can't find that ID in your DBC, I suspect that you are not using the correct or the latest version of DBC.

[tokar]

I have tested to log can signals with NI9862 with cDAQ and Flexlogger software.

Then it works with the same .dbc file.

But then i used Labview 2022. 

So the dbc file should be ok i think.

[GerdW]

Hi tokar,

---

@tokar wrote:

Im not able to use Xnet convert Frame to Signal for that ID. Not 0x0CFFE909 and neither 0x2CFFE909.

And i cant find the the ID in my .dbc file. Im really confused.

As an example i mark what i revere as the message ID in one of my messages in .dbc.

Please correct me if im wrong.

---

The ArbID 2566846718 is 0x98FEF8FE (or 0x18FEF8FE as 29bit value), which is apparently NOT 0x0CFFE909 nor 0x2CFFE909.

When your message is not defined in your DBC file then you cannot convert its payload data…