I recently updated to LabView 2015. When I connected to my cDAQ chassis with a 9862 in one of the slots, NI Max required a firmware update of the 9862. After updating, data coming from that module was very wrong and unstable in many ways. When I downgraded and used a computer running LabView 2013, the data came across as expected. The new firmware version is 14112110 while the old version is 11030415. Does anyone know if there is something wrong with this new firmware? I did not reboot the chassis after updating or downgrading the module - is that an issue? Is there something wrong with LV 2015?
Solved! Go to Solution.
When you say wrong and unstable in many ways. can you elaborate?
I would recommend rebooting the chassis after changing the firmware or software.
Did you update your driver versions when you upgraded to LabVIEW 2015?
This morning I pushed a firmware update and rebooted the chassis. Rebooting did not help. I also pushed the firmware update again and rebooted - did not help.
All my drivers are updated.
I have 15 channels configured in a xNet session. When probing the data line coming directly out of the XNET read vi, some data was stable and as expected while other data was changing values unexpectedly and maybe even chaning positions in the output array.
I attached a video of the jumping signals. I am suspecting a firmware issue.
Does your 9862 device sucessfully pass a self test in MAX?
Also, can you sucessfully run the CAN Loopback Test shipping example? If not, what errors do you see? Does the input read match the output?
The 9862 does pass the self test.
When running the Loop back test, I get the following error.
Error -1074384886 occurred at XNET Read (Frame CAN).vi:4320002
NI-XNET: (Hex 0xBFF6300A) The operation timed out. Solution: specify a timeout long enough to complete the operation, or change the operation in a way that it can get completed in less time (e.g. read less data).
I increased the time but that did not help. I also turned on termination even though it is properly terminated to see if that helped. It did not.
Does this test require that two 9862s be connected together? I do not have that ability.
The loop back is designed to work with two distinct CAN ports so we would require two 9862 devices to execute the test.
What about using the XNET bus monitor to isolate the issue as being in the application or the hardware? We can configure the BM to read signals via the CAN Database and if we are seeing a hardware issue we would expect the signals to jump around in the BM exactly like the applicaiton demonstrates.
What type of XNET sessions does your application use? Is any manipulation done to the data before it is output to the UI?
I set up the bus monitor and recorded a video of LV 2015 and LV 2013. The 2015 drivers and hardware firmware shows the same jumping (unsteady) data while the 2013 drivers and firmware video shows solid data. I accomplished this by using two separate computers. When I load LV 2013 on the computer which has LV 2015 installed, the data continues to jump. This is pointing to either drivers loaded with 2015 or the 9862 firmware update required with 2015.
Looking into the dbc file, the maximum value for Wheel Based Vehicle Speed is 255.996, Cruise Ctrl Set Speed is 250, Eng Percent Load At Current Speed is 250, and Cruise Ctrl States is 7.
In both cases the engine was not running and therefore maximum values is expected. What is not expected is the jumping from maximum values to 0 and 85 in LV 2015 case.