09-30-2015 11:17 AM
Can you post your database file or perhaps a obfuscated copy that reproduces the issue on your end?
09-30-2015 11:39 AM
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
10-02-2015 07:46 AM
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.
10-02-2015 10:39 AM
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.
Thank you.
10-02-2015 11:01 AM
Also VPEA,
Does your GPS device communicate using the J1939 protocol? XNET 15.0 introduced support for J1939.
10-02-2015 11:17 AM
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
10-02-2015 11:18 AM
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"?
10-02-2015 11:24 AM
It is set to "SAE J1939".
Steve
10-02-2015 11:27 AM
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".
10-02-2015 12:11 PM
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