Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Issue when updating NI-9862 firmware

Solved!
Go to solution

Can you post your database file or perhaps a obfuscated copy that reproduces the issue on your end?

 

Jeff L
National Instruments
0 Kudos
Message 11 of 25
(2,940 Views)

I now believe it is not linked to the database file.  I do not see any pattern to the signals that are being dropped.  I have further monitorted data from a GPS antenna using a Frame In Stream session (rather than a Signal In Single-point as in my other setup and wihout the use of a dbc file) and a Frame CAN read vi (rather than a Signal Single-point).  A complete different setup with a NI-9171 (rather than the 9178) and a different NI-9862 and all separate code.  In this raw published data from the antenna there are also signals being lost periodically.

 

My next step is to downsave this new code to LV2013 and load it to a computer with LV2013 to monitor the antenna output.  If it is stable, that will point again to the drivers and firmware. At least I think it will.

 

Thanks,

 

Steve

0 Kudos
Message 12 of 25
(2,936 Views)

Here isthe latest.  I have completely rebuilt one laptop with LabView 2013 and downsaved my code to 2013 from 2015.  I also downgraded the firmware in the 9862 so that the 2013 version will function.  As a result, the measured data is stable in my code as shown in the bus monitor. 

 

I then connected the laptop loaded with LV 2015, upgraded the 9862 firmware, rebooted the chassis, removed and reloaded the instrument in MAX, and ran the 2015 version of my code.  The measured data is unstable as before and as shown in the 2015 bus monitor.  In previous troubleshooting, I ran LV2013 in the laptop loaded with LV2015 and had the same unstable data. 

 

Videos of the data can be seen in the attachment.

0 Kudos
Message 13 of 25
(2,887 Views)

Hi VPEA,

First, help us to make sure we understand the entire test setup so we can try to reproduce it on our end. We are working with a old software stack that works and a new stack that is showing the anomaly. 

 

New software stack: LabVIEW 2015, DAQmx 15.0, XNET 15.0.

 

Old software stack: LabVIEW 2013, DAQmx 14.5 or earlier?, XNET 1.8-14.5? (let us know the exact versions so we can more acurately reproduce the issue)

 

As I understand it, the GPS device we are interfacing with sends out a continuous stream of frames whose payloads (and thus signals) remain constant. 

 

  1. Can we verify that the GPS device is sending out a continuous stream of frames with a constant payload?
  2. Can we eliminate the LabVIEW software component? You have shown that LabVIEW 2013 plus an older version of XNET works as expected. What happens when you install XNET 15.0 with LabVIEW 2013? Does the problem still show up?
  3. Can you send us a copy of your database so we can try to reproduce the issue?
  4. Can you use the bus monitor to log all CAN traffic? Set the Run Mode to subordinate, check both the "Log Transmitted Frames" and "Bus Error Frames" options.

Thank you.

Jeff L
National Instruments
0 Kudos
Message 14 of 25
(2,876 Views)

Also VPEA,

Does your GPS device communicate using the J1939 protocol? XNET 15.0 introduced support for J1939.

Jeff L
National Instruments
0 Kudos
Message 15 of 25
(2,874 Views)

Hello Jeff L,

 

Yes it is based on J1939.  I talked directly with NI support and we believe this is key to the issue.  NI is currently looking into what might be occurring.

 

Steve

0 Kudos
Message 16 of 25
(2,870 Views)

Looking closer at your BM video, J1939 support is most likely the cause of our problem here.

 

Before XNET 15.0, the driver would ignore the flag in the database for J1939 support. We no longer ignore that flag in XNET 15.0.

 

When you select a database alias in the bus monitor, it will automatically use the "Application Protocol" that is specified in the database. In this case, we suspect the application protocol flag is set in the database. It used to be ignored and thus would show steady data in the bus monitor. In XNET 15.0 it is no longer ignored and the bus monitor tries to interpret the J1939 frames causing the data to appear as unstable.

 

What is the Application Protocol used by your database? Is it set to "None' or "J1939"?

Jeff L
National Instruments
0 Kudos
Message 17 of 25
(2,869 Views)

It is set to "SAE J1939".

 

Steve

0 Kudos
Message 18 of 25
(2,867 Views)

If you change your database to have the application protocol set to "None", I would expect your application to behave the same as it did before.

 

You can also set a property in your application to "Ignore Application Protocol".

Jeff L
National Instruments
0 Kudos
Message 19 of 25
(2,865 Views)

That does it!  I was able to resolve and recreate the issue by setting the protocol to None and J1939. 

 

How do I set the property in my application while it's running? 

 

Thanks,

 

Steve

0 Kudos
Message 20 of 25
(2,849 Views)