Signals longer than 8 bytes in Database Editor

[Hooovahh]

---

@BLowery wrote:

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

---

It must have been simple multiplexing because it worked for us eventually.

[cool_ranch_doRITAs]

Hi all, 

One thing I discovered is that if you change the Data Type of your signal to IEEE Float, you can get the signal to show up in the example if it's over 52 bits. But with IEEE Float, your choices of signal length are either 32 bits or 64 bits; anything else will be coerced to one of those two values. That's not a great work around of course, but it could be something to think about. 

I'll look into this a bit more.

[Hooovahh]

Thanks for the suggestion but this is not a solution.  I am not in control of the DBC, or have any influence at all in what is in it, or how it is formed.  I am given a DBC and my application needs to take it and allow some form of reading and writing of all signals in it.  This database may change at times that I cannot predict, and updating the software to accommodate the DBC every time it is changed is not much of a solution either.  Sure the majority of the time that we have more than 52 bits we are probably going to use all 64, but the only way I could know that is to read into the database somehow, and at the moment that means manual parsing of the file.

[cool_ranch_doRITAs]

Hi Hooovahh, 

I agree with you; the only thing left to try is to make a parser yourself. I'm sorry I couldn't be of more help, but I will definitely pass this feedback along to the right people to see if this functionality can be changed for the future. 

Thanks for posting on the forums!

[BLowery]

There isn't a way (as far as I can see) to create that parser.  XNET treats that database info as corrupt so it does not give access to it.  That's the fundamental problem.  Just need NI to let that data through...

[Hooovahh]

---

@BLowery wrote:

There isn't a way (as far as I can see) to create that parser. 

---

There is, it involves reading the file as plain text, then understanding the sections, reading the ECUs, Frames, Signals, scaling, etc. of the whole file.  Massive pain, and not something I feel like re-writing for such little benefit.  Thanks for investigating and taking our feedback.

[JefeL]

Thank you for your valuable feedback. I have taken this issue and escalated it to give it some additional visibility. 

[jansiroky]

Hi.

I have the very same problem as guys before me. I will sum up the problem to be sure, we are in the same dark hole. And then i will try to describe my provisional work around.

I need to send a message of 36B length. It contains 2 strings: the first one is 22B long, the second one is 14B long. There is the problem that one signal (in this case both strings) can not overreach limit of 52 bits (6.5B).

Well in my case, the solution is to divide the string in various signals. After that the first string of 176bites is divided in 4 signals: 48b,48b,48b and 32b. After that the signals are concatenated again in Teststand to build the whole string again.