Invalid Index

[Grant_LECO]

I have rebuilt my test station from win2000 up and I'm still experiencing the following issue. I've quarantined the problem though down to the following description.

I install all the NI software and then the NI hardware and everything goes good. I create an NIProject from the Ni App Wizard under VC6.0 and drop a CWDIO Control and a button in my dialog. I then call the CWDIO member variable m_digital and give my button an OnButton message to handle. Then I have the following code there.

(OnButton Function name and params)
{
static bool toggle;

if(toggle == 1)
{
m_digital.GetPorts().Item(CNiVariant(0)).GetLines().Item(CNiVariant(0)).SetValue(true);
toggle = 0;
}
else
{
m_digital.GetPorts().Item(CNiVariant(0)).GetLines().Item(CNiVariant(0)).SetValue (false);
toggle = 1;
}
}

I compile the program (let's call it DAQTest) and run it and everything works great. I then turn off the power to the computer and the PXI station. When I come back to windows I create a shortcut to DAQTest.exe in it's Release folder and place it on the desktop calling it "DAQ Test". If I run DAQ Test everything works fine. If, however, I load DAQTest.dsw and then go back to my shortcut and run DAQ Test from the desktop I get "Invalid Index" when I press the only button in my dialog.

Okay, I think that isolates the problem quite well.
I was wondering if the following might be of importance.

On my working test station I have 4 NI-DAQ devices. On my new fixture which is struggling I only have three. Well, check this out.

Working Fixture:
Device 1 -- PXI6704
Device 2 -- PXI6508
Device 3 -- PCI6110
Device 4 -- PCI6503

Non-Working Fixture:
Device 1 -- PXI6704
Device 2 -- PXI6508
Device 3 -- PCI6503
Device 4 -- Not present.

I thought it would be a lot easier to make my PCI6503 Device 4 so that I wouldn't have to change anything when I brought code over from the working fixture. Of course tests that require the PCI6110 can only be done on the working fixture. Anyway, so I change my devices as follows.

Non-Working Fixture:
Device 1 -- PXI6704
Device 2 -- PXI6508
Device 3 -- Not present.
Device 4 -- PCI6503.

This has always been the first thing I've done once everything is installed. It seems to work great and from within VC++ the devices show up just fine.

My question then is, are there any known issues involving changing of the default device number given by NI-DAQ? I really don't have to change it but you made it so easy that I did. After all, it does save me a step each code transfer. This is the kind of thing that could slip by you when you are trying to test out your code. I mean how many people are going to mess with this stuff? It seems pretty rare to me. Again everything seems to work fine except for the "Invalid Index" issue which results in me not being able to communicate with my devices. Once I remove my devices from windows device manager and restart and win2000 reinstalls my devices everything works again in the same order. I can run the shortcut DAQ Test but if I load DAQTest.dsw and run DAQ Test from the desktop I get "Invalid Index" when I press the only button in my dialog.

I'd like to have more information about what exactly occurs when I load a workspace file. As far as NI-DAQ goes anyway. Are the instrument connections set up again through MAX? It just seems strange that loading the file messes things up. I thought it was when I recompiled but that's not the case.

Thanks,

Grant

[Chris Matthews]

Well, you've done a good job of isolating it, but you aren't debugging the problem so I'm not sure what is happening. It could be a device config problem, it could be a NI-DAQ loading problem, I'm not sure.

So, to be clear, what you are saying is if you have VC++ open with your workspace loaded, then run the Release EXE, you get the problem. If the workspace is NOT open then you don't get the problem. Is that correct? Does this also happen with the debug executable? Does it execute fine from within VC++?

Best Regards,

Chris Matthews
National Instruments

[Grant_LECO]

Chris you're the man. Really. You hit it on the nose. I didn't try closing the workspace before. It works fine with the workspace closed. It being running the actual .exe. So,

yes it works before loading the workspace.
no it doesn't work when the workspace is opened.
yes it works again once the workspace is closed.

I haven't found any difference between Debug and Release versions of the same code. Neither version (release or debug) works when the workspace is open.

Sounds like you are on to something.

Grant

[Chris Matthews]

Again, I'm not sure exactly what the cause would be since you aren't doing error checking. It could be that the NI-DAQ DLLs are loading properly if they are being used in VC++. It could be you are getting a device in use error in the EXE and VC++ is reserving the device for some reason. I'm just not sure.

We can try to reproduce the problem here, but I'm not sure we will be able to. I would suggest adding error checking into your code. Also, using the CWAI control to try and Configure the board (see if you can talk to DAQ at all). What OS are you using? We've seen some NI-DAQ DLL loading issues on Windows 2000 with Visual C++.

Chris

[Grant_LECO]

Hey Chris. I'm using win2000 and VC++ 6.0. I've got an idencital system running right next to it though. Maybe I'll try installing that exact version of VC and MS.

When you say I'm not doing error checking do you mean I'm not doing exception handling? I usually just use a nonzero return value to generate an error in an if block. Since DAQ functions often don't return anything I use try {} and catch(CNiException * err) {} like in the following:

void CNiDAQTest2Dlg::OnButton1()
{
try
{
m_digital24.GetPorts().Item(CNiVaraint(0)).GetLines().Item(CNiVariant(0)).SetValue(true);
}

catch(CNiException * err)
{
err->ReportError();
err->Delete();
}
}

Right now I can't get any exception
to go to my catch block. I get "Invalid Index" in the try block and jump out of the program. I have captured the exception before however and the ReportError() returned "Invalid Index".

This seems like an issue that needs addressing. Were you able to solve those NI-DAQ loading issues under Win2000 and Visual C++? I'd be willing to try anything. In the meantime I'll probably just keep tearing my system down and rebuilding it and hope to get lucky.

Grant

[Chris Matthews]

First thing to try would be to install the update for NI-DAQ 6.9.1. This update includes a fix for the NI-DAQ Dll loading problem we have seen on some Windows 2000 machines. You can get that patch here.

Let me know if that helps the problem.

Chris

[Grant_LECO]

Hey Chris. Thanks for the patch. I think I'll quit smoking now. Ha ha. Anyway, it worked great. I only have one DAQ board installed right now, PCI-6503, but it was giving me the exact same issue until I ran your patch. The computer restarted and it works great now inside and outside of Visual C++. I have just a few more questions:

1.) Should I risk changing Device Numbers Under MAX? I don't really have to but it would be nice.

2.) Should I uprage to SP5 on Visual C++?

3.) Should I update my Windows 2000 to SP2?

4.) Any other updates or fixes you recommend?

I won't do any of these unless you think it's okay. I don't want to waste more of your time then I already have.

Thanks again f
or the patch and I'll let you know if there are any more issues once I put the PXI chassis back in the system and add a couple more DAQ boards.

Grant

[Chris Matthews]

Well, I can't really be an advisor on Microsoft updates as that I'm not an expert. As for changing the device number, yes, it should be fine to change them however you like. I've been using VC6 SP5 for a long time with no problems so I would recommend that. Operating system service packs are usually a good idea as well, and very rarely have any impact on our products.

Glad you are working now, good luck in your development.

Chris