NI 8473 failing after after 30 mins

[Captain_Julz]

Has anyone had the following problem or can anyone help:

I'm using

-labVIEW 8.5.1

-Ni-can 17

-Windows 10

When I start my application up the can bus is working fine I can set outputs and read inputs but then after a variable time I can no longer set outputs ( I can still read the inputs tough!!)

This is software I've inherited so am unclear about what they have written or is NI / third part etc but an error in the send outputs is:

BFF62008

NI-CAN write can network interface object ncWriteNet.vi

We also run this application (for our bigger systems ) on identical PCs etc but using the NI PCI-8512 card and have no issues

[GerdW · Accepted solution]

Hi Julz,

according to this and this you are running an unsupported combination of LabVIEW version, NI-CAN version and OS version…

You might think about using a supported combination of all three software parts!

(That might not be the solution to your problem, but will grant you NI support…)

[Captain_Julz]

Hi,

Yes I know this, but unfortunately I have to use windows 10 now as XP is obsolete. People before me have tried to use more up-to-date versions of labVIEW but with no success. I may have to force this issue with my company. (I have only just recently taken over this project!!)

As we have no issues with the PCI Board my company see's it as acceptable to stick with the current setup.

Was hoping someone may have seen a similar issue and could point me in the right direction - I'm currently experimenting with closing and opening the link to the CAN  API when I see the error - but this may not be an acceptable solution.

The option is to use the PCI board but  I think that adds about 2K to the job!!

Thanks for your reply - it gives me some fuel to move onto the latest version of labVIEW 😉  I'll download the evaluation version of LabVIEW 2017 and have a go.

[Captain_Julz]

Just to update in case anyone else has this problem!

I have got round this by looking for the specific error (BFF6 2008) in the set output part of our code. If this error is seen I exit the loop and close the connection. I then reconnect and execute the loop again. It's a horrible fix as it can cause short delays in the inputs acting and also you loose the outputs for a moment too, but in our application its better than loosing the outputs altogether as they are sounding warning alarms!!

(sorry I can't post the code - I don't have permission to do so)

I'm currently looking at updating our labVIEW to 2017 and hopefully this will fix it properly.