CVI HSDIO (NI6541) acquire with external strobe

[bjasper]

I'm using NI6541 to interface to a component handler (I know...overkill..but it's available).  I'd like to use 4 bits as generate output and 12 bits as acquire input.  And one external signal as trigger/pause input.  The handler signals to acquire ~ once every 100ms.  On that event I want to read/fetch the 12 bits and about 100ms later write the 4 bits.  I can't find example code that is very close.  I know I probably want to run the acquire clock at max 50Mhz and use pause/trigger to acquire minimum (2?) samples.  And I'd like to use the pause/trigger signal to cause an event like CVICALLBACK; or some simple means of NOT BLOCKING waiting to read the acquisition...I have other tasks to do.  Can you give me give me guidance?

[Lea_D]

Hi bjasper,

I see you're using our digital waveform generator/analyzer 6541. Are you familiar with using CVI with HSDIO? I'd like to point you to a couple resources for this. First of all is the examples for HSDIO and CVI. You can get to these by going to your start menu » Programs » National Instruments » NI-HSDIO » Examples » CVI. This will open up a folder with several CVI examples already made. I believe the folder titled Dynamic Acquisition and Generation is going to get you close to what you're trying to find. Unfortunately, I don't think we have an example that does exactly what you're trying to do since applications can get extremely specific.

Can you be a bit more specific about what you're looking for from this forum? If you're looking for a more turn-key solution, check out some of our partners.  

Please let me know how I can help.

[bjasper]

Hi Lea,

We've used the 6541 extensively in generate dynamic script.  Here, I'm working a handshake interface, tester to an SRM component handler.  The handler has 4 positions.  Each position has SOT (start of test from handler), EOT (end of test from tester) and 5 bit code (bins from tester).  PXI 6541 is the tester.  SOT is a positive pulse 1-100 ms.  EOT should be a 2 ms positive pulse.  Bin code has a 1ms setup and hold time around the leading positive edge of EOT.  Not all SOT's will occur every cycle but the active ones occur all at the same time.  Totals are 20 data bits out, 4 pulse bits out, 4 pulse bits in.

I think I need dynamic acquisition and generation using an internal capture clock.  And possibly use a pattern match mode trigger to detect the SOT's.  Not sure how to handle the uncertainty of 4 SOT's...possibly a mask?

This will require experimentation but I'm looking for some up-front guidance so I don't waste time on functionality that isn't there.

Thanks.

[JuanCarlos]

Hi bjasper,

I have limited experience with handlers, but typically the interface for them are slow. For slow interfaces where handshaking is required, I would recommend looking into static IO. Yes, you loose exact timing and al the niceties of dynamic IO, but with static IO you gain full software control of the state of the DIO lines, if the speeds are slow enough, static IO may be the way to go.

One thing to keep in mind is that the static IO speed is dependent on your system, so give it a try and see if it is fast enough for your particular handler.

Hope this helps,

Juan Carlos

[bjasper]

Yes, I would like to use static IO because speeds are relatively slow.  One issue; I can't see how to capture the (any of 4) SOT pulses that are spec'd at 1-100 ms.  Is there any trigger with static IO that can ensure this pulse is not missed?

I could use a timer and poll the SOT bits but there's no guarantee that I wouldn't miss the pulse event.

[Lea_D]

I definitely agree with Juan Carlos about the static I/O. Static acquisition is all software-timed so it's not clocked. When you use niHSDIO_Read_StaticU32, the device immediately reads the digital value on the channels configured for the static acquisitoin. 

I'm also not super familiar with handlers or SOT, but it sounds like there are four pulses before your signal that you're aquiring. Would it be possible to tell your device to aquire sooner or have a delay between reading and generating the device? It sounds like the pulses are just being generated before the software is actualyl telling the 6541 to read the device.

Additionally, you mentioned that you're trying to collect pulses that are spec'd at 1-100 ms. Is this a specification of your SRM device? Do you have a link to that specific device so that we can get a bit better of an idea what you're expecting to capture? It doesn't look like we have a specification for the 6541 with that kind of range. Just in case, this is the specifications manual for the 6541 devices.

[bjasper]

Hi Lea,

The crux of the problem is acquiring the 'any-of-4' SOT pulses coming from the SRM handler.  Forget the generation side...that's well understood.  There are 4 SOT signal wires to be acquired by the 6541.  They are independent but synchronous.  They are a minimum 1 ms wide.  Each one might occur without the other 3 or any combination thereof.  But, they all occur in the same timeframe.  The problem is how can I be sure not to miss the pulse.  To run static acquisition I could install 4 edge triggered flip-flops but that's additional hardware.  I could use dynamic acquisition with internal 6541 clock but then I don't know how to setup the 6541 for trigger on any of 4 pattern matches.

Do you see my dilemma?  Neither static or dynamic seems to satisfy this function.

[Lea_D]

Hey bjasper,

As JuanCarlos stated, you loose the exact timing capabilities when working with static I/O. Yes, the read tells the device to read immediately; however, since it's not clock, this is really undeterministic. Because this is undeterministic, it can take 1ms to even go in and read. I think this is why you're missing those pulses. 

Static I/O doesn't have triggering capabilities. To help solve the issue, you could try increasing the loop rate in software and/or working with a faster processor so that the amount of time that it takes to read the signal off of the device is minimal.

[Lea_D · Accepted solution]

Hey bjasper,

Without an extremely fast PC, you'd probably be looking at dynamic aquisition. You mentioned that each signal might occur without the other or any combination of them. Does this mean that the only time that you don't want to trigger is when all channels are zero? You could look at using niHSDIO_ConfigurePatternMatchRefTrigger. One of these inputs is "Trigger When". If we set this input parameter to NIHSDIO_VAL_PATTERN_DOES_NOT_MATCH (37), the program can be configured to trigger when any of the lines go high. This way, if the 3rd channel goes high, the pattern no longer matches 0's so it triggers. If all of them go high at the same time, the pattern doesn't match and it triggers.

[bjasper]

Hi Lea,

Excellent suggestion.  So I'll look into setting up dynamic acquisition and trigger on pattern not match 0000.

Thanks.