LabVIEW Error 1006

[sacraig1]

I am using some particularly crappy third party drivers (for the GFT 9404 that can be purchased through NI but is actually a third party hardware). I've squashed a number of bugs after great effort, but I am now finding that I keep receiving the following error:

Error 1006: FPDCO on connector pane thinks it is constant. 

Is anyone familiar with this error? I am not even sure what FPDCO is and extensive searching has led to nothing useful. The best I have found is that there is a fpdco.cpp that exists somewhere in the LabVIEW source code but nothing about what it does or what that says about this error.

Any help would be greatly appreciated.

[AlexAlligator]

Hi sacraig1,

Like you've said there doesn't seem to be much public documentation on that error or file. Which version of LabVIEW are you using? Is there a specific set of steps that can reproduce this error?

[sacraig1]

I am using LabVIEW 15.0.1f1 (32-bit) on a 64-bit version of Windows 7. All of the equipment is hooked up to a PXIe-1085.

The steps I am doing involve trying to read the settings off of the GFT 9404 card using one of the provided VIs that talks to the card through the provided driver. If anyone just so happens to be familiar with these awful cards (I honestly think NI should stop officially supplying them because they are garbage), the specific VI in question is "GFT9404_Read Channel Settings.vi", and within that, the sub-VI is "GFT9404_Get Pulse Amplitude.vi", which in turn talks directly to the driver.

The error thrown is the one above and the card has poor documentation and no indication of what is actually causing the problem. Trying to contact the manufacturer has proved fruitless so far, so I was hoping someone here know something about the FPDCO error (or even what the heck FPDCO is in the first place) so that I could track the issue down myself.

Thanks.

[tst]

I have no idea what the error means, but I would guess it's probably irrelevant and most likely whoever wrote the code simply decided to throw error 1006 when X happens and LV simply shows you the description it has for error 1006. Usually, drivers should install error files so that their error descriptions will also be visible when looking at the error code details, but since you say it's not very good, it would not seem unlikely that it would not install these files properly.

If the code is open, I would suggest looking to see what causes the 1006 error. If not (e.g. if it's a call to a DLL which returns that error), then I guess you're stuck with getting replies from the supplier.

[sacraig1]

Yeah I traced the error all the way down to the call to the DLL, so I think I am pretty much hosed I've got a call in to NI's support line and they now have an engineer looking into it, but at the end of the day, it's still technically a third-party piece of hardware with garbage drivers. I told they guys at NI that they ought to stop selling these cards directly because their quality reflects poorly on NI.

In the meantime, I did manage to find a workaround using lower-level functions provided by that company. It just means I have to use several VIs to accomplish my tasks where previously it would have required only one if their software wasn't rubbish.

[Ben]

Kudoes to you for speaking your mind and reminding me of Slim Pickens riding the A-Bomb.

Could you briefly outline what you did to help the next poor sole that has to follow in your foot -steps?

Ben

[sacraig1]

Basically the VIs that Greenfield provides to operate their products don't necessarily work for the 4 auxiliary channels on the card. If you dig into the sub-VIs, it seems that it throws errors when you try to read off the status of properties from channels where those properties are fixed. Despite this, the company only provides one set of VIs and their documentation falsely implies that they work for all channels.

Instead, I followed the VIs down and figured out which low-level VIs were throwing errors and on which channels, and that led me to this solution. I essentailly just made alternative mid-level VIs that cut out the error-prone ones from the suppied set that would work with the auxiliary channels. It wan't difficult, but it took a while to trace the problem and is far less ideal than just getting a set of working VIs from the manufacturer in the first place.