J1939 Add-on Feedback

[DCatz]

Great help thanks. Back in with customer today and checked the arb id in the database which was set to a generic 00 source address, whilst message being received was from a specific (not 00!!) source. After modifying database to define correct source address, the SPN indicator sprang into life. Awesome. Great work and thanks again.

[jarm.woo]

yes , i meant the address in j1939 custom devcie as following:

how to set this address? the customer don't know what it stands for.

[Daniel_E]

Hey,

That address is part of how J1939 works.  It is a number between 0 and 255.  Set it to something not already taken on the J1939 bus (similar to IP addresses, you don't want conflicts).  Does that help?

[jarm.woo]

so, the custom just set this address to any value between 0 and 255 which matches the sender'address, right?

but the customer use the CANoe as a sender, and he find no address to be set in CANoe.

is it this reason why he cannot see the DTCs table couldn't display any data?

[Daniel_E]

I apologize but I don't understand what you mean by matches the sender's address?  They should be different.  So, if the third party software is working like a real J1939 device, it should have an address.  That address must be different than the J1939 add-on.  Otherwise, it will cause issues.  I don't know how the third party software works so I can't help there.

Now, if you are saying you want to send a message addressed to the add-on, that is part of the arbitration ID of a J1939 message.  Read this to see if it helps (http://www.ni.com/example/31215/en/).  The big point is that the destination address is typically part of the arbitration ID and that is what you set to match the J1939 add-on address.  This is ussually done by modifying the database accordingly.  As an example, if the third party software is sending a message to the J1939 add-on, and if that message PGN is x00FF00, and if that third party software has an address of xF8 and the J1939 addon has an address of xF9, I believe the end Arb ID would be x 00 FF F9 F8.  I believe I am missing a priority flag at the front but that should illistruate the point.

[jarm.woo]

perfect explanation，which is what i want. in the case you just refferred to, so is the address of VS j1939 add-on set to be 249 which is xF9, right?

[jarm.woo]

Daniel, sorry to bother you again.

     the customer still get the issue. We describe the isse with more detail as attachment and post the J1939 dbc file and VS projec we used.

     please note that the project as attached is no frame imported in J1939 custom devcie. because the customer have tried  adding frame in incoming

session of this add-on and it still get no DTC signal . he insists that there is no need to configure the incoming frame in the case of receiveing the DTC.

    I am not sure whether what he said is right due to no CANoe or any other J1939 device to reprocude the issue.

    so would you please take time to check what is  the reason we cannot receive the DTC signal from CANoe in VS.

    thank you

[Daniel_E]

Hey,

Thank you for putting all that information together. 

I took your customer's database.  I actually imported everything into VeriStand both for generation and acquisition (I essentially created a loopback).  When I did this, I was actually able to get everything working.  So, I made the generation device address 254 because that is what the DM1 has as the source address.  Then, I made the acquisition device address 249.  This address shouldn't matter because DM1 is a public message.  I then set the DM1 message to be periodically generated every 2 seconds.  This caused it to show up in my DTC display.  As discussed before, this only works if the third party software responds to a request for its address.  If it doesn't, the address will not show up in the DTC display and won't get DTCs into that display.  So, if the customer wants it to work in this way, they need to review the J1939 spec and add support for address claiming. 

I then changed the address to not match the DM1 message (so generation was from 250 but the DM1 still said 254).  I then added the DM1 to my acquisition address (249) incoming and it did work on my system.  I was able to write to the DM1 on the generation port and get it to show up on the acquisition port.  Without an address claim, this is really the only way to make it work.  Now, the difference between what I see in your customer's setup and mine is I am generating the DM1 message as defined in the database.  I am generating all the configured DTCs (DTC 1 through 5).  The picture from your customer is only generating DTC1 and removing the rest.  I am guessing this is actually how it should work.  The message should scale dynamically based on how many DTCs are actually in the system.  That doesn't work in VeriStand.  So, the customer needs to generate all DTCs and just have the value be 0.  Again, this problem actually goes away if they get the third party software to respond to an address claim.  So, I would be willing to bet that adding DM1 to incoming and generating all the DTCs defined in the CAN frame would work.

So, to summarize, the customer needs to either:

1. Add address claim support to third party software

2. Add DM1 to incoming and generate the expect frame that is in the DBC file

I hope this helps.

[jarm.woo]

hey,thanks for your reply.

how do you make this loopback woork?  I add two seperate j1939 custom device in VS system definition file,one for generation with address 254, another for acquisition with 249 , and add 8513 in PXI rt target with one port for generation and another for acquisition. however, I get an error as below when running project

and there is no any info in the above control to display. am I missing something?

or need i run j1939 custom device for acuiqition on another PXI rt target?

[Daniel_E]

So, to be clear, you deployed everything successfully?  The workspace is just giving you an error?  Did you try reselecting the custom device?