XNet Conversion Crash

[Hooovahh]

I've submitted this to NI through a crash report, but these forums seem to be regularly monitored so I'm posting it here too.  Report ID: 69895837-65fb-44e9-8e3b-6e194035175b.

I have some pretty basic code that does some XNet conversion with an included demo DBC.  All that is needed is to extract the zip, and open the XNet Conversion Crash.vi, then run it again, and again.  After running it a few times LabVIEW 2015 SP1 f3, and LabVIEW 2016 f2 will crash.  The only dependency is the XNet 16.0 is also installed.  I've replaced the XNet conversion with my own method, but I wanted to perform a speed comparison and I need to run the NI method multiple times to get an idea of how long a conversion takes, but it keeps crashing.

Can anyone confirm that it also crashes on their system?  Is there any thing I'm doing wrong that needs to help clean up the conversion session other than calling the clear?  Thanks.

Edit:  Just tested with always copy sprinkled, adding random waits, and replaced the string manipulation with Signal constants linked to the database name and it still crashes.

[JefeL · Accepted solution]

Hi Hooovahh,

There is a known issue with repeatedly calling Signal to Frame Conversion.vi in a loop with different sessions.  If the sessions use varying frame sizes, the signal to frame conversion does not properly adapt to the frame length and ultimately causes a crash. 

The issue will be fixed in the next release of XNET.

[Hooovahh]

Awesome thanks.  With this information in hand I was able to re-write the conversion API and add several features, while also maintaining a speed improvement over NI's implementation with XNet.  The updated API was posted here, with a few graphs in the changelog that show major improvements in the last version, and beating NI's methods in a few conversion types.