ACK signal remains high after transfer complited

[Sir]

The PCI-DIO32HS board are configured for burst mode input with pclock reverce direction. Data input works OK, but after the transfer was complite, the ACK signal remains in HIGH state. The problem is that I want to use ACK signal to control the periferal device, and I need the ACK signal LOW after the transfer was done. What to do?

[Elizabeth W]

Hello,

What pin are you connecting the peripheral device to?  It would be helpful to start out by verifying that you have connected the correct ACK pin, if you haven't already done so.

Are you programming in LabVIEW or another programming environment?  Also, which driver are you using: NI-DAQmx or Traditional NI-DAQ?  It sounds like you're using Traditional NI-DAQ but I just wanted to be sure.  Once you let me know this information I could possibly recommend a burst handshaking input example program you could use to test your hardware configuration.

Also, could you clarify what you mean about using reverse direction for PCLK?  That was unclear to me.

Sorry to ask so many questions, but I need a little more information about the situation before I can provide much more help.  Thanks!

[Sir]

Hi Elizabeth!

>What pin are you connecting the peripheral device to? It would be helpful to start out by verifying that you have connected the correct ACK pin, if you haven't already done so.

I use HW Group 1, port0 + port1. ACK and REQ pins also from HW Group1. May be a device is damaged?

>Are you programming in LabVIEW or another programming environment? Also, which driver are you using: NI-DAQmx or Traditional NI-DAQ? It sounds like you're using Traditional NI-DAQ but I just wanted to be sure. Once you let me know this information I could possibly recommend a burst handshaking input example program you could use to test your hardware configuration.

I use LabWindows and NI-DAQ7 traditional version. I try an example, coming with ni-daq driver, the situation is the same. To solve the "HIGH ACK" problem I have to reassing ports in group by the following construction:
DIG_Grp_Config(DIO_BOARD, Group1, 0, 0, 0);
DIG_Grp_Config(DIO_BOARD, Group1, GroupSize2, Port0, DirIn) + Mode config, - this is not the best solution...

>Also, could you clarify what you mean about using reverse direction for PCLK? That was unclear to me.

I mean, thet the source of clock signals is a pereferal device. I use this command to tell my PCI DIO32HS about that fact: Set_DAQ_Device_Info(DIO_BOARD,ND_CLOCK_REVERSE_MODE_GR1,ND_ON);

>Sorry to ask so many questions, but I need a little more information about the situation before I can provide much more help. Thanks!
No problem! I need solution - you need information.

[Elizabeth W]

Hello,

Thanks for providing the additional information.

When I asked what pin you are connecting to, I meant the actual pin number on the terminal block.  I want to check and make sure that the physical pin you are connecting to actually corresponds to the ACK signal output.  Sorry I wasn't clearer on that one.

I do suspect that there could potentially be something wrong with the hardware, especially if it's not even working with the LabWindows shipping example.  Which example did you run?  Also, how long have you had this device?  If you have used it before, did you notice this problem previously? Can you think of anything that could have happened to damage this device? 

One other thing to check: have you verified that your clock signal from your peripheral device is coming in as you expect it is?  To do this, you could try running the example program you used previously, this time allowing the DIO-32-HS to generate its own PCLK, rather than importing the PCLK signal from the peripheral device, and see if this results in the same problem with the ACK signal.  Give this a try and let me know what you find out.