ISSUES with building DIO_EX1 DDK EXAMPLE

[Raminta]

Hello !

I am trying to compile,link and execute the DIO_EX1 program that is part of the device driver kit. I am using Visual C++ 6.0 as my compiler, developing on WINDOWS XP, and want to run the program to access the registers on the installed AT-DIO-32HS card. Looking through the documentation, I am a bit confused over the files I need to include.

Currently I include osibus.h, ositypes.h, tdio.h, and tstatus.h.   I get LINK errors saying it is unable to resolve the functions "releaseBoard()" and "acquireBoard()"  ( + a couple others).   I see several osiXXX.cpp files, and I am unsure which one to include in project. In addition, do I need to #define osiVISA ? 

Hopefully this will be easy to resolve.

Thanks !

[Tom_W_[DE]]

Hi Raminta-

the acquireBoard() and releaseBoard() functions are included in osiUserCode.cpp.  You will indeed need to define the appropriate OS environment variable- the three valid entries are declared in ./OSInterface/osiUserCode.cpp and are used to conditionally include the proper implementations of the OS interface functions.

Another problem I forsee is that the ISA device may appear differently to VISA than a PCI device (as the examples and OSInterface assume).  This might require some changes to the osiUserCode implementations, but I haven't tested it.  Perhaps a better question is this- your device is supported on the Windows platform by the Traditional NI-DAQ driver.  Is there a particular reason you need to use the MHDDK?

Thanks-

Message Edited by Tom W [DE] on 08-10-2007 01:53 PM

[Raminta]

I am not using the NI-DAQ driver because after extensive testing and communication with another NI engineer, it was concluded that I could not meet my application's timing requirements with the driver of the AT-DIO-32HS card, or with any NI CARD, for that matter. So I thought I would try RLP programming to see if I could achieve better timing than I experienced with the driver. The protocol between the application and the peripheral is pretty simple. The application simply outputs a continuous series of sets of 32 bit values to the peripheral until a user terminates this via the GUI. So...

1. User starts program

2. Program waits for a REQUEST signal to go high from peripheral to indicate the peripheral  is ready to receive data

3. Program raises an ACK line to tell the peripheral it is ready to send data

4. Program places a value on data lines, and pulses another SIGNAL high to indicate to the peripheral that data is valid on data lines

5. Repeat step 4 about 500 times

6. Program LOWERS THE ACK line to indicate it is complete with this set of values

7. Goto step #2

The original programmer of this application used the AT-DIO-32F card, but did not use its' driver. Instead, he used a software library created by ZEALSOFT to DIRECTLY access the registers of the 32F card. He was able to implement the above protocol and meet the timing requirements simply by programming the registers.

Well, the problem is that the 32F card is now obsolete. I had hoped that I could update to the 32HS card and still use the same original application (that uses the ZEALSOFT library). But it did not work. I compared the actual registers of the 32F to the registers of the 32HS and found it much different, and I would not have a clue how to program the 32HS registers at the lowest level without LOTS of help. So I thought I would attempt RLP programming using the NI DDK.  But it seems now I am running into the problem that the current DDK examples will not work on an AT-based card.

Soooo... I have the following options:

1. Implement another iBus object  for the 32HS AT interface/card and use RLP programming

2. Upgrade to a PCI-based card and use RLP programming

3. Try to directly program the 32HS registers using the ZEALSOFT library. But the 32HS card has about 117 registers compared to the 20 or so on the 32F card.  Probably not a good idea (which is why I attempted to use the RLP DDK classes)

4. Scrap trying to use a NI card and instead try an FPGA -based solution.

Any ideas ?   Anything would be helpful.

Thanks so much !

[Raminta]

the attached document might help make the protocol  I have to implement make more sense. The last statement refers to a "buffer/ray", and a buffer consists of a set of 519 or 520 32-bit values.

[Tom_W_[DE]]

Hello Raminta-

Thanks for posting that document- given the protocol as I understand it, you should be able to easily accomplish this using the Traditional NI-DAQ driver.  Please let me know if I understand the protocol correctly:

1.  The DIO board waits for a hardware trigger (IN2).  When the trigger is received,

2.  A digital waveform of 519 or 520 points is clocked out of the DIO board.  The duration of the generation may vary, corresponding to a clocked data rate of somewhere between {1 / (1sec / 520 samples)} = 520Hz and {1 / (0.333msec / 520 samples)} = ~1.56MHz.  At the same time, a single digital line (Out1) should be held high for the duration of the generation.

3.  Repeat (?)  How often?

Can you please elaborate on the specific challenges that you ran into with timing?  If my understanding of the protocol is correct then there should be a number of NI hardware options (including your DIO-32HS device) to make this work.

Thanks-

[Raminta]

ok, I hope I answer your questions...

1. It seems your understanding of the protocol is correct. Let me clarify that the timing between 2 consecutive  hardware triggers (IN2) from a peripheral can be as small as .333milliseconds.  THat is, a second peripheral data request can follow the first within .333ms, and our software needs to be able to send out the buffer of 519 or 520 samples within that time period.

2. It is repeated forever (or until a user ends the data transfer via the GUI). This answers your question #3.

3. I discussed my options with another NI engineer via email support about how I could use the 32HS driver (or any other NI card driver) to accomplish the protocol. Reference#7161644 is the # of the support case I had. We specifically tried to see if we could get the BURST TRANSFER PROTOCOL to work...however, we concluded we could not get consecutive buffers of data loaded onto the card within .333ms. ARE there other driver-level options that you had in mind ?

4. For your information, I am also attaching a document that dissects the code that the previous developer wrote to implement this protocol using the 32F and the ZEALSOFT library. It really is not that much...initialization, followed by the output of the data. 

I look forward to your ideas !!! Let me know anything else I can answer for you.

[Tom_W_[DE]]

Hello Raminta-

Thanks for the additional information.  I just spoke with Matt (the AE you worked with previously) about some ideas of how to implement your protocol.  We agreed that it would likely be possible but that we might need a bit more info.  Matt will contact you directly to see what we can come up with.

Thanks-

[Raminta]

I guess my question right now is why would it not work if I used RLP on a PCI-based card ? (I do not have to use an AT based card). It seems like it should since I would be eliminating the overhead of the NIDAQ driver.

I will wait for Matt and then get back with you via this forum. ok ?

THANK YOU so much !

[Tom_W_[DE]]

Hi Raminta-

I'm hoping that you could achieve this operation using the NI-DAQmx driver and some of the more powerful hardware features of a PCI M Series device.  It's good to know that using a newer PCI device is an option- please keep me posted if you still need help with register-level programming.

Thanks-

[Raminta]

Hi again !

It looks like I will have to pursuse RLP programming because my final option with the NIDAQ driver won't be possible.

I believe you said that the current RLP API does not support an AT interface. If I update to a PCI card, which PCI card do you recommend ?

Thanks !