Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

XNET Database Signal length

Hello Everyone,

 

I came across some strange problems on Friday:

 

First of all, my customer gave me a .dbc file which XNET did not properly recognize. It just listed a bunch of empty frames without names. Since the .dbc is under NDA I can't post it here, but I must say I was a bit disappointed since this means extra work for me.

 

I then tried writing a program which parses the .dbc file as a text file and builds the Database from the information therein. I got everything worked out pretty quickly, but something was off: The Signals, which I define in my program appeared to be out of bounds in the XNET Database editor (appearing with red crosses in the graphic). I then noticed that all the signals were set up as 32-Bit length, even though I told them otherwise. I attached a simplified version of my program with which I could reproduce the issue.

 

Can you reproduce it? What can I do to sort this out?

 

Needless to say, arranging everything by hand is the last thing I want to do since there are over 300 Signals.

 

Any comment or help is greatly appreciated.



Remember Cunningham's Law
0 Kudos
Message 1 of 6
(4,643 Views)

Hi Peter,

 

this looks indeed ackward. I could reproduce that with XNET 15.0.

One way around that I found so far is to "accept" that the signals always have a initial length of 32 bit then save the file, reopen it and edit the length on the seconds try. That works fine. Nethertheless unnveriving behaviour.

 

To implement the workaround one would need a recursive algorithm to automatically open, create a signal, save, reopen, edit the signal, create the next one

I will write a CAR (bug report) for that.

 

Best regards,

Christoph

Staff Applications Engineer
National Instruments
Certified LabVIEW Developer (CLD), Certified LabVIEW Embedded Systems Developer (CLED)


Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved
Message 2 of 6
(4,628 Views)

Hi Christoph,

 

I have contacted NI Support regarding this issue here in Germany. Thanks for your help, maybe we should link the requests. I'll PM you the SRQ#.

 



Remember Cunningham's Law
0 Kudos
Message 3 of 6
(4,625 Views)

Hi Peter,

 

I take over the Service Request that has been created and we do the troubleshooting from there.

 

Best regards,

Christoph

Staff Applications Engineer
National Instruments
Certified LabVIEW Developer (CLD), Certified LabVIEW Embedded Systems Developer (CLED)


Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved
0 Kudos
Message 4 of 6
(4,618 Views)

What happened? Did it get fixed or is there a better work around? I seem to have the same issue where all lengths are 32 bits.

0 Kudos
Message 5 of 6
(254 Views)

I found a SOLUTION. I was getting this error when opening an XNET database in the NI editor "NI-XNET: (Hex 0x3FF63085) A warning occurred when opening this database. The NI-XNET Editor may show additional information." All of my signals had a 32bit length and an error.

It happened to be that I wasn't setting the "DataType" property of the signal after creating the signal in LabVIEW. The help mentions that when the database is created in memory using ":Memory:" as the database object, that the property does not have a default value, which may have been the reason. 

I also had an issue when opening the database when the "ByteOrdr" property of the signal wasn't set. I already had several other properties set.

 

Below are the properties that I set in my VI and it creates a valid XNET database. I'm sure you don't have to set all of them, but this is what worked for me.

 

Cluster

  • BaudRate
  • Comment
  • Protocol

Frame

  • Comment
  • ID
  • PayIdLen
  • CAN.TxTime
  • CAN.TimingType

Signal

  • Comment
  • StartBit
  • NumBits
  • Min
  • Max
  • ScaleOff
  • ScaleFac
  • ByteOrdr
  • DataType

 

0 Kudos
Message 6 of 6
(247 Views)