5411 arb card seems to hang on niFgen = niFgen_CreataArbWaveform() call; Upgraded PCI Chassis from Win2K to XP

[MKrause]

Sorry to come accross as brain-dead, but what about NI-DAQ 7.4.4, will I need to remove 6703 cards and install in set order to get correct physical mapping of cards/connected cables so that our application can reference each respective card correctly.  In our system, the Condor ARINC 429 cards and IP Cards are mapped as Dev0, Dev1, Dev2, and Dev3, but the NI products don't have any such designation as viewed by Device Mngr.  Did the install or NI-DAQ and NI-FGEN already establish that and the upgrade to 7.4.4 & 2.9 will preserve that assignment?  One last question; can I use the Standard Download of NI-FGEN 2.9? 

[kirsch]

Sorry to come accross as brain-dead,

You don't. Our drivers aren't exactly simple and how they interact with each other is not obvious. 

but what about NI-DAQ 7.4.4

NI-DAQ and NI-DAQmx will get upgraded by NI-FGEN. NI-FGEN uses DAQ and DAQmx internally and bundles the necessary version.

will I need to remove 6703 cards and install in set order to get correct physical mapping of cards/connected cables so that our application can reference each respective card correctly.

No, you should not need to remove the 6703 cards.

In our system, the Condor ARINC 429 cards and IP Cards are mapped as Dev0, Dev1, Dev2, and Dev3, but the NI products don't have any such designation as viewed by Device Mngr.

Correct. The device naming is not an Operating System thing. It's a National Instruments thing. The mapping can be seen and modified in an application called Measurements and Automation Explorer (MAX). It is installed in your system by the NI drivers.

Did the install or NI-DAQ and NI-FGEN already establish that and the upgrade to 7.4.4 & 2.9 will preserve that assignment?

Yes, device names should survive a driver upgrade. If they don't (but they should), open MAX and rename the devices to what your application requires.

One last question; can I use the Standard Download of NI-FGEN 2.9?

Yes. It's a large download, hope you have a fast connection!

[MKrause]

We did the update to NI-FGEN 2.9 (after it requested that we remove the old NI-DAC and NI-FGEN) and all that went well and we got 5 instances of New Device found/driver updates for the qty 3 6703 cards and qty 2 5411 cards.  Went into MAX and saw that the Dev # and S/N mappings were the same as before update.  Even ran the NI-FGEN softpanel app and got the two DEV4 and DEV5 5411 cards to show up.  Still when I run my App at the point where I'm trying to load the first waveform into the 5411 it hangs on the call;

niFgen_CreateArbWaveform()...

Wherre do I go from here?

[kirsch]

Wow, sorry to hear that. This sounds like an issue with your specific chassis and/or chipset. I was hoping that some fix that went in between the version of the driver you had and the latest would fix/workaround it.

Are you running the latest Windows XP service pack?

Can you try the board on a different computer, maybe a more standard desktop PC, so that we can rule out a broken device?

Also, what kind of computer are you using? And what kind of PCI-PCI bridge? Does your chassis have more PCI bridges internally (some larger ones do). If so, something as simple as moving the PCI card to a slot on a PCI segment closer to the host machine may do the trick.

[MKrause]

I ran through the Arb card init function with the debugger and got all expected return values and I used the return minimum waveform size = 256 as the new target size vs 16000 for the Composite VOR and 1800 for theLOC signal waveforms that I am trying to load into the ArbCard.  With this reduced size, the loading of the desired number of waveforms (truncated of course) all load.  What in the system could limit the size or bandwidth of trying to load the larger full length waveforms?

[MKrause]

More data....  I did a poor man's binary serach on the size of waveforms that will load correctly...  256 - 1023 work, if I try to load 1024, it hangs forever.

[kirsch]

Does the Soft Front Panel work? Can you run the examples that come with the driver?

Did you try moving the card?

At this point I may need to let the support people for NI-FGEN take over since I don't have access to a NI-5411 where I am.

[MKrause]

I did run Soft Front Panel and it seemed to let me choose either Dev4 or Dev5, I did not hook up a scope to see if the waveform/freq I chose was being actually generated as output.  I did not move the card as I don't want to un-cable rack and pull chassis unless I really need to.  Is there something magical about the perceived hard limit of 1023 vs. 1024 datapoints in the size of transferred waveform?  If you can connect me with 5411 tech support people so I can talk with them directly that would really help.  This board has been really helpful thus far, but I need to expedite this process.

[MKrause]

I re-ran Soft Front Panel on Dev4 and went into Arbitary mode and loaded a file from disk and ran that and verified via an O'scope that the generate waveform matched the selected Arb datafile.  So it seems that at least the card works as desired.  Now the question is this; is there an API call that has changed somewhat such that my 10yr old src code that needs to be modified?  I also ran my truncated waveforms that I can load and verified that they come out on the O'scope.  I just can load the desired 16,000 or 1,800 samples per waveform.

[kirsch]

Ok. That's good news, you validated that the 5411 and the driver work, and that you can download a large waveform and generate it.

I am wondering if your program uses a different function that was obsoleted and broken (by accident!) at some point. You said that you don't have the source code to your program, correct?

You can still see what NI-FGEN functions are being called by using a utility called NI IO Trace (formerly known as NI Spy). It's already installed in your system. Open IO Trace, Start logging, then run your program. If you want to verify that IO Trace works right, you can run it while trying out an example or even the Soft Front Panel.

We can then compare the IO Trace capture and see if your program is doing anything odd.