01-25-2016 06:26 AM
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.
01-26-2016 02:36 AM
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
01-26-2016 03:32 AM
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#.
01-26-2016 07:10 AM
Hi Peter,
I take over the Service Request that has been created and we do the troubleshooting from there.
Best regards,
Christoph
08-08-2024 04:14 PM
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.
08-08-2024 11:40 PM
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
Frame
Signal