Troubleshooting Error Code -200279

[mcduff]

Before reinstalling everything I would do the following: 

1. Shut down and restart the whole system
2. Connect nothing to the DAQ board
3. Try with the Continuous Input once again.

If it works, connect but don't power your DUT, and do the same as before, if it doesn't work then try reinstalling everything

Or if possible try on a different computer before reinstalling

Check here for compatibility (Newest Version will work with 2018)

[BStevenson]

I appreciate the advice. I shut everything down and restarted, and watched the example vi fail pretty quickly again with nothing connected to the end of the DAQ cable. Unfortunately, we don't have any other machines with LabVIEW (I inherited mine from a predecessor who was the only remaining LabVIEW developer). 

I then went into the NI Package Manager and uninstalled everything to try to start fresh. I re-installed LabVIEW 2018 and the supporting software/drivers that were on the install flashdrive, and I updated DAQmx to the latest version. I was pretty happy that afternoon, as -200279 did not make an appearance, but unfortunately that must've just been coincidental, as it came back the following afternoon, and the system is now behaving like it was prior to the error. 

While it will be less efficient, I guess I will try to just implement a bit more detailed error handlers/messages to pop up messages where things go wrong, and then build the program into an installer to run directly on the 8840 embedded controller than will eventually be used to run the program once development is complete, and just go back and forth building out new applications to make the needed edits/fixes. If this error is stemming from communication issues between the laptop and the hardware, I would like to think it will be eliminated when running the program on a device 'closer' to the hardware. 

[Kevin_Price]

Maybe it's worth building an executable from the continuous input example, then just let it run on the embedded controller during times when you're busy working on the real app on your laptop.  That'll put some hours on it to help test your theory/plan about running embedded.

-Kevin P

[mcduff]

Can you try a different computer?

Once I was working with a Thunderbolt to Express Card converter for a Frame Grabber for a camera. Not matter what I did, I kept getting dropped frames that would randomly appear. I switched to another computer and changed nothing in my program and it worked without dropping frames. The previous computer had some issues with Thunderbolt. I wasted a whole weekend trying to fix the problem on a suspect computer, needless to say, I was not happy.

[BStevenson]

Those are both good ideas Kevin and mcduff--I really appreciate your responsiveness/helping out a LabVIEW newbie.

I will build the continuous example input into an executable to run for a while to test the theory of running on the embedded controller. I asked around my division this week, and it appears I'm the only one with a license for LabVIEW, and since it's licensed offline (not through my account), I don't think I could transfer it to another machine. Do you know if I could download a trial/evaluation period of LabVIEW (even if it's only good for a short period, I could still test the theory of a bad Thunderbolt port)? Otherwise, I can try to reach out to other groups to see if they have a laptop with LabVIEW I could borrow. 

[mcduff]

If you can make an EXE with your version of LabVIEW, you can also make an installer. Make an EXE of the example along with an installer. You can use that installer on any computer, no license required.

[mcduff]

One other Thunderbolt thing to try.

I was getting a BSOD whenever I plugged in a TB accessory into a brand new laptop. The solution was to update the TB driver. I know you don't have this issue, BSOD, but updating the TB driver may be a possible fix if there is an update available.

[BStevenson]

Well, I built the example vi into an exe and got it to run without issue running directly on the embedded controller, and on a different laptop with a thunderbolt port. So, it appears the issue lies within the laptop I was using. I had previously tried to update the thunderbolt driver/firmware, and didn't see a difference. But at this point, I'm happy enough if the issue was just running it from that laptop and it works fine running from other machines/on the embedded controller. I've since been able to complete the core functionality of running the test sequence, now I just need to work on modifying the MS Office Report Generator Express vi so I can have more than 17 input bookmarks.

Thanks again mcduff and Kevin for your help and guiding me towards an issue with the machine, not the software design.