Signals longer than 8 bytes in Database Editor

[BLowery]

With the introduction of J1939, why does the XNET Database Editor force signals to a length of <= 64 bits?  Is there a way to turn this check off?  It doesn't make sense to me since you can make the payload length much larger than 8 bytes (as you expect in J1939), but a single signal can only be 8 bytes.  

I can set the length to >64 bits in the CANdb++ editor, and I see that number when I open XNET's editor, but if I try to change it, it is forced to 64 bits.

The cluster containing all the frames is recognized as SAE J1939 application protocol.

Thanks!

[Hooovahh]

Standard CAN has a payload of 0-8 bytes.  CAN-FD can have up to 64 bytes of payload.  But in XNet no one signal can take up more than 52 bits because the values are returned as floating point doubles.

http://forums.ni.com/t5/Automotive-and-Embedded-Networks/64-Bit-Signal-Error/m-p/3134063#M7457

[BLowery]

Thanks for the reply!  So for signals greater than 52 bits, would you have to write it through a frame session instead of a signal session?

[smithd]

There is no way to do it in the editor, but there is literally a checkbox in the xnet db API. That is how these j1939 libs work:

http://www.ni.com/example/31215/en/

https://decibel.ni.com/content/docs/DOC-21035

(same code, just one is tied into nivs)

You might take a look at how they operate for inspiration....

[Hooovahh]

Okay so I started thinking about this, and I want to find a work around.  I want to be able to give a DBC to a function, then provide a signal name that I want to write, as either a U64, or an array of bytes, and then I want it to write that frame to the ID specified in that DBC.

I realize some code may need to be done to handle offsets, and scaling, along with a few other pieces of information.

But what I think is going to be the hardest part, is simply knowing what IDs are used in signals, with more than 52 bits.  The NI-CAN, NI-XNET, and even MAX, all show errors, or won't include the signals which use more than 52 bits.  So does anyone have any ideas on how to even know what signals use more than 52 bits in a DBC?  And how can I get the information about this signal, like start bit, length, offset, scale, etc?  The only way I thought it might work is to write a DBC parser myself but that seems like a bit much, since NI provides 2 (or possibly 3) already.

Attached is an example DBC that has a 64 bit signal.

[cool_ranch_doRITAs]

Hi Hooovahh, 

Have you seen the Exploring Databse with Tree.vi example? I found it in the 2015 Example Finder under Hardware Input and Output » CAN » NI-XNET » Databases (Editing and Managing). This example populates the front panel with the frame name, ID, Payload Length, etc. of the XNET Database you specify. I tried it out with your "Dabase With 64 Bit Frame" DBC and it gave me back "8" as the Payload length. Is this the kind of functionality you are looking for? 

[Hooovahh]

---

@cool_ranch_doRITAs wrote:

Is this the kind of functionality you are looking for? 

---

Nope.  It would be what I wanted if it actually worked with my signals.

---

@Hooovahh wrote:

But what I think is going to be the hardest part, is simply knowing what IDs are used in signals, with more than 52 bits.

---

When I run that tool on my database it shows no signals under the frames.  As far as I can tell no tool made by NI, which uses a CAN database, can tell me what signals have a bit length greater than 52.  They simply are not shown, because they are in an error state in the XNet Database Editor.  Same with NI-CAN, same with MAX.

EDIT:  Attached is a new database, in it are 3 signals, can you programatically tell me what the bit length is of each signal?

[BLowery]

Yeah, this is still a problem for us.  I float it to Application Engineers every so often and eventually got this answer:

"Signals in XNET are meant to represent a numeric or boolean values. SPNs such as Engine RPM or Vehicle Speed fit into this category nicely.  Items such as a alpha numeric VIN number do not.   The current version of XNET does not claim complete J1939 support and signals based on ASCII data are not included. To interpret ASCII based signals a customer will need to read a raw J1939 frame and parse out the ASCII signal manually."

So it sounds like it just isn't possible in the signal API.  The App Engineer tracked down the XNET devs, so this is straight from the horses' mouth.  Also, just FYI, don't try extended multiplexing.  XNET doesn't support that either.

[Hooovahh]

---

@BLowery wrote:

The current version of XNET does not claim complete J1939 support and signals based on ASCII data are not included. To interpret ASCII based signals a customer will need to read a raw J1939 frame and parse out the ASCII signal manually.

---

Okay I totally get that this isn't a supported feature of XNet, it should be but that doesn't help me at the moment.  The problem I have is with the second half of that statement.  I'd be glad to do my own raw signal parsing, I will take a raw frame, I will read the bit off set, the endianness, bit length, scale, offset, etc. and I can turn those raw frames into scaled signals.  The problem I have is that there is no tool that can give me this meta data in regards to a signal, from a database.  So even if I re-wrote the frame to signal, and signal to frame code, I would also need to re-write the DBC parsing code.  Not only does XNet not provide the functionality I want, it also doesn't provide the tools I need, to make the functionality I want.  This is where my frustration comes from.

I had a need to support multiplexed signals once in LIN.  XNet doesn't support that either, but luckily they do support it in CAN.  In this case XNet didn't provide the functionality I wanted but the tools made it possible to accomplish what I wanted.  Same with a more feature complete Frame and Signal conversion.

[BLowery]

I agree.  Reading a frame is still possible by parsing the frame ID and flags, but the DBC interface mangles the DBC info if it's "wrong" according to XNET.  This is what I was fighting with months ago and still haven't found a solution.  We considered basically creating our own DBC-type data structure in source code (along with a Read interface), bypassing the whole DBC interface.  I consider this the Nuclear Option, but it may become necessary if XNET doesn't get some badly needed updates.  We've arrived at the same dead-end street!

TLDR; I got nothing but solidarity for you. Maybe NI will hear our wailing and gnashing of teeth.

Regarding multiplexing: were you doing extended multiplexing (nested levels) or simple multiplexing with NICAN?  Because XNET does support simple multiplexing.