6533 Burst Input REQ Stop and Short-circuit

[gokhan,]

We are using DAQ 6533 digital input board in our system.
Actually we use this board for a very simple task, there is 5MHz CLK and
REQ signal and 32bit data. We use the board in Handshake Burst Mode.
REQ signal is High during only if the data is available. CLK signal is
always running.

Part under test comes to test-bed and a sensor detects it. This enables
measurement. If there are defect at current pixel, REQ signal becomes HIGH for the error
pixels. It there are no defects, REQ signal stays at LOW during test. When
the part lefts the test-bed, another sensor detects it.
We get 32 bit data for every defect pixel.

Our problem is:
We are getting only defect pixel data to PC. But we can't know, how many
defect pixel can occur but we can estimate maximum number of defects. For
instance 500000 defect pixels. If we try to read 500000 data, but if there
are defects lower than 500000, PC stops even the part under test leaved
the test-bed.

So, we need to stop burst mode handshake input acquisition/transfer with a
stop trigger even if the number of data transferred is lower than
described number of data.

Is this possible on DAQ6533? (Visual C++)

Data clock is running at 5MHz, we may need to collect 500K to 4M 32bit
data.
We decided, burst mode is the best for this. We faced data loss on other
modes.



We are facing another problem too. The data bus is 32bit. We applied 32bit
parallel data to board. But we read bit 25 and bit 26 always same value.
We connected bit25 to GND and applied HIGH to bit26. We read bit25 and
bit26 is high. If we connect bit26 to GND, both bits become LOW. We
supposed there is a short circuit but we checked the pins at the terminal
block box and checked with oscilloscope but it looks OK. I suppose there
is a problem on software or there is a short circuit at the DAQ board just
after the input buffers.


I hope to get a response until xmas because we would like to finish these
parts before xmas.

Regards and marry xmas.

[rgharrison]

Hi gokhan,

I'm not sure if I understand your application correctly but I'll do my best. From what I understand, you are trying to collect test data on pixels. Each pixel will give you 32-bits of information. You only want to measure pixel information when the sensor activates (REQ line goes high).

First of all, the rate of 5MHz is too quick for sustained input on the 6533 card. You will need to use the 6534 (with the 32MB of onboard memory). Here is a knowledge base that describes some benchmarking.

Performance Benchmarks For The High-Speed Digital I/O - NI 653x
http://digital.ni.com/public.nsf/websearch/4FCA248D888831C386256D8900563E45?OpenDocument

In terms of losing data points, it could be that at speeds of 5MHz you are getting data skew. This means your data points have not all changed before you clock your data. This means you will get incorrect data. The key is that all your data must change within half a clock period of each other. This will ensure that your data will be correct on either the rising edge or the falling edge. This could be your problem as well. Your clock could be clocking data when the data hasn't changed yet. To correct this, you can simply clock on the other edge of your clock. You can accomplish this using some code included in the attached C code.

If it is indeed the case that you have a bad line, it should show up bad when you simply test it in Measurement & Automation Explorer (MAX). Perform as you did by applying a 5V source or a GND source to the line and read the line in MAX. You could also use the code I attached to perform a simple loopback test across the first and second groups of the board. You should read the exact data you are outputting on the first group back on the second group. If the line is indeed bad, then you should request repair on the board. You can initiate a request on the board by going to ni.com/support and selecting contact an AE. Make sure you select the option to have the board repaired or replaced. Anyway, I hope that helps. Have a good day.

Ron
Applications Engineering
National Instruments

[gokhan,]

"
Our problem is:
We are getting only defect pixel data to PC. But we can't know, how many
defect pixel can occur but we can estimate maximum number of defects. For
instance 500000 defect pixels. If we try to read 500000 data, but if there
are defects lower than 500000, PC stops even the part under test leaved
the test-bed.


So, ////we need to stop burst mode handshake input acquisition/transfer with a
stop trigger even if the number of data transferred is lower than
described number of data.////


Is this possible on DAQ6533? (Visual C++)
"


I think we don't loose data in burst mode because defect zones are not big and not frequent.
Could you recommend something for the stopping burst mode using a trigger?

[rgharrison]

Hi gokhan,

There is no simple way to stop an acquisition with a stop trigger. The "stop" trigger used by the 6533 device is actually a reference trigger but you must still specify a specific amount of data. The following knowledge base discusses this case.

Why Does My Stop Trigger Not Stop My NI 653x Digital I/O Device During Pattern Output?
http://digital.ni.com/public.nsf/websearch/3DE994179719296D86256CB000544217?OpenDocument

My suggestion would be to acquire data and use a software watchdog timer. This watchdog timer is a timer that will report if something hasn't happened for a specific amount of time. For example, you can have a software timer in your program that you read every loop iteration. If you haven't acquired data in a speci
fic amount of time, you can assume that the test is complete and shutdown the program. For example, if you know the test will not take more than 5 minutes, you can read the timer value every loop iteration and make sure that 5 minutes has not gone by without an acquisition. If it has, then automatically stop the program. I am assuming that there could be a case where no defects are found at all. But if you know that a defect will definitely occur within a small period of time, you could use that period of time as the "watchdog timer" value.

Anyway, I hope that helps. Have a good day.

Ron