J1939 Add-on Feedback

[Daniel_E]

A model would be up to 2 ticks of the PCL rate for a delay.  So, if you are running at 1kHz, that would be 2 ms.  This is in comparison to the J1939 custom device approach.

[swbpnole]

Daniel,

I would like to add an option to the configuration page(s) for this J1939 addon. In what VI do I do this? I know a generic custom device created with the Custom Device Template VI it is a VI called "Main Page" or something to that extent.

[swbpnole]

Nevermind, I found it.

[swbpnole]

Daniel,

Is there a way to obtain the current values for a subset of input channels?

From earlier, I expressed a desire to modify the J1939 Custom Device to response automatically to custom messages. I want my custom logic to read data values from select input channels for packaging into CAN frames/data based on received data from custom messages.

[Daniel_E]

Hey,

There is no API call for doing this that already exists.  If you want a subset of signals, you need to create a lookup table that allows you to look up the signal's position in the data array by signal name.  Then, you need to use that array index to pull the current value.  I do something similar in the addon but it is all based at the frame level.  I keep track of frame position (offset and length) in the data array by arbitration ID.  So, I can pass the function a desired arb ID and it returns the offset and length of that frame in the data array, which I then use to get or set all the signal values contained within the frame.

I hope that helps.

Thanks!

[TJ_VeriStand_Te]

Hi Dan,   I'm trying to implement Calibrations using Veristand, which requires sending DM7s and receiving DM30s. DM30 is an extended data frame ( More than 8 bytes) hence it is supposed use peer to peer TP. The J1939 add-on does support the peer to peer and responds with necessary TP_CMs and TP_EofM. The issue is that the TP_DTs are not get assembled, hence all the channel values of DM30 are set to zero. I did some digging, turns out the XNET only supports signals with a length of 52bit or less and on the other hand TP_DT has the signal (packet data) with a  length of 56bits.   I have done a workaround using raw frame signal, however, I still have some more issues to deal with. I'm wondering do you already have an updated J1939 add-on, that uses raw frames to assemble the data?  I'm currently using Veristand 2013.   Regards, TJ

[Daniel_E]

Hey,

I didn't know that some of the signals where over 52 bit in the J1939 protocol.  That is good to know.  There is no update for handling the data in RAW form.  I purposely tried to avoid this because of the difficulty of big endian, little endian at random bit locations, etc.  I just use the built in XNET scaling functions so I don't have to worry about that part.  I am glad you found a work around!

Another workaround you could do is to break the signal up into smaller byte signals in your database.  So, you would have the 56 bit signal be one 4 byte signal + a 3 byte signal.  Then, you would have a model (simple LabVIEW code) that did the combination of those two bytes.  This would make it so you don't have to modify the J1939 addon at all.  I do realize that means changing your database, which isn't a great option either.

I will send the feedback in to R&D about a larger bit size for J1939, though this won't be implemented for a year at least.

Dan

[TJ_VeriStand_Te]

Dan,

Thanks for the suggestion. I think you may have misunderstood, what I was trying to say. The DM30, does not have any signals longer than 52 bits. DM30 it self is longer than 8 bytes. My concern is that, the add-on device responds to RTS message. However it fails to assemble the data obtained from the TPDT messages. Its odd, because in my system DM1 is received fine. That means the assembly for the BAM works fine, on the other hand for Peer to Peer does not work properly.

I wonder how does add-on process the data from TPDT to reconstruct the actual J939 messages? I thought, it might not have  been working due to the fact that in each TPDT message, the signal Packet Data has a length of 56 bits. And we know that XNET has a cap of 52 bits. Well, that's not the case as DM1s are processed without any problem.

Best Regards,

TJ

[Daniel_E]

Hey TJ,

The peer to peer messages (rts cts) have always worked in the past. The 2013 version hasn't been updated in a while so I am guessing nothing broke from an update.  Therefore, my guess is something is wrong in your database. I definitely could be wrong but this is working for a lot of other customers. Would you post some screenshots of the message in the XNET database editor?

[TJ_VeriStand_Te]

Hi Dan,

You are right, DM30 is set to have a payload length of 8 bytes, as opposed to 11 bytes. This is a DBC file, hence I can't edit via XNET. I'll sort it out and get back to you.

Thank you for the suggestion.

Best Regards,

TJ