How to tell if REQ1 is set active high

[svt4cobra6]

Hi I am using the 6533 PCI-DIO-32HS card in a PC with traditional DAQ, looking at an existing design.  I could not find how to tell if REQ1 is set active high or low, guessing it would be set up in the DIO confg vi.

[Jim_S]

Hello svt4cobra6,

In order to see if the PCI-6533 card is setting REQ1 to active high or low, check to see Digital Mode Config VI, which is called by DIO Config VI is setting the request polarity input to active high or low. For more information on this, please look in the NI 653X User Manual for Traditional NI-DAQ on page 27 of the pdf manual.

[svt4cobra6]

Thanks for the information.  I am looking at an existing design and it looks like it is set up to write out 2 groups of 32 bits of data on the rising edge of REQ1.  Anyhow looking at the output with a logic analyzer I noticed the time that REQ1 stays high (when 2 words are written out on DIOA0-7, DIOB0-7, DIOC0-7 and DIOD0-7) seems to vary a bit, would you know if this is because of the windows operating system not being real time? 

[Jim_S]

Hello sct4cobra6,

Yes you are correct that the Operating System does matter with 6533. On page 56 of the manual in the timing diagram section, it states the following:

Note Your transfer rate is limited by the minimum available bus bandwidth in your
computer system, unless you are using the NI PCI/PXI-6534, which has onboard memory.
Otherwise, you are limited by the number of other devices using the bus and your
application software, both of which can lower your transfer rate. For more information
about transfer rates, refer to Appendix E, Optimizing Your Transfer Rates.

Knowing this, you can reduce the jitter in your system by using a Real-Time system.

[Jim_S]

Hello sct4cobra6,

After reading over your post, I want to clarify a few things about your application to make sure that my suggestion is going to work for your application. What type of handshaking are you using? Depending upon the type of handshaking, the Real-Time system might not be the best option. If you are streaming a lot of data for long periods of time, the Windows environment wouldn't be able to keep up since the PCI-6533 doesn't have a buffer with it. If you are just doing burst, then Windows might be able to keep up and the varying REQ1 line generating.

The jitter you might be seeing in the REQ1 line might also be caused by the amount of time your DUT takes to process the command sent. Is this always constant for the DUT?

[svt4cobra6]

thanks for the response.  I am looking at an existing design as I have upgraded the operating system and software.  It interfaces with additional hardware but I do not have access this hardware at this time.  From looking at just the Lab VIEW side and digital card it looks like based an user events data is written out, 2 words 32 bits each, possibly unstrobed.  The Lab VIEW gui does not seem to hang up so I am thinking it is not doing any handshaking since the hardware that the I/O card connects to is not available.

[Jim_S]

Hello svt4cobra6,

After reading your post here, I think it might be best if you could post your code. I believe this will understand your application a little bit better. Is this possible?

[svt4cobra6]

Thanks for the response, unfortunately I can not post any code other than the write vi that does show how the card is configured.  I just need to make sure that the timing has not significantly changed on the output of the 6533 card from upgrading from windows me to xp and Lab VIEW 6.1 to 2010 and a new computer.  I am still using traditional DAQ and was able to use the old card as the new computer has the standard PCI slot. 

[Jim_S]

Hello svt4cobra6,

I understand that you can't post your code. As for upgrading from LabVIEW 6.1 to LabVIEW 2010, the overall timing shouldn't have changed. When it upgrades LabVIEW only changes the code when a function is no longer supported by a later version. Ultimately, the only way to know if your code has been altered is to test it. When you get the external hardware, you will be able to understand how the application works and test if the timing has been changed. From here we can see if there is any problems with this.

[svt4cobra6]

thanks for the additional information, yes will have to wait for the external hardware.  I did have a general question about the 6533 data and control line outputs using traditional DAC.  I think for this design it is set up as a pattern IO transfer using internal REQ and an internal clock set up as a VI input, (DIO START).  Anyhow I am monitoring the card outputs with a logic analyzer and it looks like an 8 element array (of 8 bit integers) is being used for the data input (to the DIO WRITE VI) with the first 4 elements being written out on DIOA0-A7, DIOB0-B7, DIOC0-C7, and DIOD0-D7 followed by the last 4 elements also written out to DIOA0-A7, DIOB0-B7, DIOC0-C7, and DIOD0-D7.  Anyhow it looks like the clock input to the (DIO Start VI) controls the pulse width of the data.  It looks like REQ1 goes high approximately 78 microseconds before the first 32 bits are written out followed by 5 microseconds of data (with the clock set at 200k), finally followed by the second data group (5 microseconds of data).  It then looks like REQ1 stays high for 2-4 ms after the second group of 32 bits is written out before going low.   Anyhow if you are trying to clock this data into a storage device I would expect to see rising clock edges when both the first and second group of data appear on DIOA0-A7..DIOD0-D7.  I monitored all the other control lines pclk1,2 ack1 and did not see signal levels other than 0, again I do not have the DIO card connected to anything except a logic analyzer.  Would you know if it is typical to use REQ1 as a clock input to a storage device or if this can be done?