2569 timing sequence

[MI-CAL]

Hello.

I have a NI2569 and we are trying to sequence the up to 10 sets of relays to emulate the variation in a 10 pin connector (up to 10 connectors...or 100 relays).  To do this we have set up an array that is looking to turn on a number of relays at 7ms apart in an order driven by a script file.

However when we checked the system, it seems to only be able to change the state every 26 ms and not at 7ms. 

Put another way, Channel 0 is activated at time 0ms from start.  We then want to activate channel 4 and 7 at 7ms from start with the remaining channels (1,2,3,5,6,8 and 9) at 17 ms from start (or 10ms after activating channels 4 and 7).  Then we want to hold those channels closed for 4 seconds, then disengage them all simultaneously and hold open for 4 more seconds, then proceed to the next line in the script file.  Right now this takes 26ms between each switching event.  Is there someone with an idea of why this is happening?  Is there an optimal programming technique we need to be using?

Also, the specification sheet mentions something about scanning... Would this "scanning" mode facilitate the time between state changes?

[Now_With_Underscores]

Hi MI-CAL,

It sounds like you're using software-timed commands.  Using hardware scanning would definitely remove the nondeterministic latency you're seeing with your operating system, as hardware scanning downloads a predefined scan list onto the switch and then use hardware triggers to determine when the module advances to connect the next set of relays.  To gain the ability to advance at predetermined times, we'd need a counter board to output pulses in hardware time to tell the switch when to advance.

Even once we add hardware scanning, we're still faced with the fact that the 2569 uses electromechanical relays that have a maximum operate time of 3.4ms.  This means engaging a relay once the switch receives a command at time X might take up to X+3.4ms.  Therefore, we can reduce the jitter you're seeing down to a guaranteed 3.4ms.  For your application that requires events to happen at 7ms, this represents a significant jitter.

Therefore, we should look at a switch with better switching speed specifications.  I recommend using one of our FET based switching products.  Unfortunately, we don't have a FET switch with the same topology as the 2569, but we do offer the 2501, 2535, and 2536 modules; depending on your application, we could use these instead due to their faster operate times (for example, 16us for the 2535).

[MI-CAL]

Thanks.  So basically you're telling me I need to add another piece of hardware (counter) to alleviate the situation?

Please take this as a suggestion that your spec sheet is misleading.  No where does it say definitively that one needs yet another piece of hardware to really utilize the piece of equipment.

So what board do you suggest to work with a 1033 PXI chassis with the 2569 board that doesn't cost an arm and a leg?  AND... will it alleviate my issue without being told later that I need yet another piece of equipment?

[Now_With_Underscores]

Hi MI-CAL,

Apologies on the confusion; can you clarify what specifically in our spec sheet is misleading? 

If we're going to use hardware triggering, we definitely need some other device to trigger with.  We offer the switch with hardware triggers to handshake between multiple devices* and so that when a customer needs an application with timing as precise as yours, we can use additional external hardware to send triggers deterministically.  We wouldn't be able to do this with Windows because it's a nondeterministic operating system, so our hardware triggers need to come from somewhere else.  In other words, Windows does not guarantee exactly when something will happen.  Typically, when we software-execute, there's a few ms delay before the instruction gets through the Windows environment to hardware; once we get to hardware, we're deterministic.  We could use a deterministic RealTime controller and stick with our software-timed calls, or we could use any of our multifunction DAQ boards with counters, or a counter board, etc, depending on your needs.  We could also homebrew a 555 counter and some latches, or an external microcontroller, or pretty much anything else that outputs a TTL pulse and is deterministic.  However we control the triggers, we won't be able to get ms accuracy as long as the command originates in Windows.

As far as utilizing the equipment, if we stick to software-timed calls, we need no external hardware, but we will need to keep in mind Windows' nondeterministic delay, which is typically only a few ms.  I would therefore expect to see a worst-case delay of around 6ms on a modern computer, but this isn't guaranteed because if your computer has other tasks eating up the CPU time, we can't guarantee this.  You mentioned that you're seeing delays much more than this; what other processes are running?  What are the specs on your machine?  It's possible we could minimize the delay you're seeing, but we definitely won't be able to have an accuracy of 1ms with our current setup (we'll need a switch with a much shorter specified operate time and some external triggering source). 

*For example, let's say we have a 3rd party device that needs to test ten DUTs.  This device is very quick and outputs a trigger whenever it's done testing.  It will then wait for a trigger before starting the next test.  Each time the tester finishes, we send this pulse to the switch, which advances to the next programmed set of relays and then sends a pulse back to the tester to start the next test.  This will allow us to cycle through the DUTs very quickly (for example, we can cycle as up to 145 cycles per second on the 2569 using hardware triggers).  This is much faster than if we used software-timed calls, because we then need to wait for the nondeterministic operating system to process the data and send each command.

[MI-CAL]

We are using a Dell desktop 2.4GHz Pentium equipped with Windows XP with only Labview 8.2 running.  We're going to try to push the code into a standalone executable and try to minimize the overhead of labview as well.

Realistically, I too would expect a 5-6ms delay (maybe even 7ms) from the CPU to the backplane of the 1033 chassis... That is why I'm dumbfounded by your comment of the necessity for a counter.

What is your expected latency from the PXIe interface on the computer to a relay input on the 2569?

As far as the specification:  The sheet should have information on exactly how fast you can switch the system using a PXIe interface and Labview sofware on the PC running windows XP or Vista.    The specification sheet I'm speaking of is the following: http://www.ni.com/pdf/products/us/cat_pxi2569.pdf.

Now.  I do have a NI 6225.  Could I use that? If so, how?

[Now_With_Underscores]

For example, we could use the counters on a PCI-6601, a PXI-6602, PCIe-6320, etc.

If we absolutely want to use just the switch, we could set the scan advance mode to "immediate" (which tells the switch to scan as fast as possible) and then use two of the relays as a dummy channel.  Since we know how long we want to wait (Z), and we could easily determine how long the delay is between successive 'scan advance' outputs (Y), we could therefore calculate the number of times we need to cycle the dummy channels (X) to add the correct delay: (Z)/(Y)=(X) cycles needed.

For example, you want 7ms delay (Z).  You pick channels 98 and 99 as the dummy channels. You then download the following scan list to the board and scan in 'break before make mode':

ch98->com98; ch99->com99;

ch98->com98; ch99->com99;

ch98->com98; ch99->com99;

ch98->com98; ch99->com99;

ch98->com98; ch99->com99;

ch98->com98; ch99->com99;

ch98->com98; ch99->com99;

ch98->com98; ch99->com99;

You set the scan list to repeat, the scan advance to immediate and then you put a scope on the output trigger.  Doing this, you calculate the delay between successive scan advance triggers to be 2.4ms±27us (Y).  Therefore, we can deterministically scan in intervals of 2.4ms with a pretty decent accuracy.  Keep in mind that with the 2569 we can't do anything about the operate time of the relay itself, which is a mechanical device and therefore needs time to move its armature (this is why I recommend using a FET based relay, which has no moving parts and has operate times in the ms range).

You then divide Z/Y and get 2.91, or ~3 (we can't scan a decimal).  This means that we can deterministically tell the relay when to connect by simply adding these dummy channels whenever we'd like a deterministic delay.

For example, say you need to turn on channel 0, wait 19 ms, and then turn on channel 1:

19ms/2.4ms= 7.91, or ~8.  We then need to add 8 dummy scans and scan in 'no action' mode:

ch0->com0;
ch98->com98;
~ch98->com98 & ch99->com99;
ch98->com98 & ~ch99->com99;
~ch98->com98 & ch99->com99;
ch98->com98 & ~ch99->com99;
~ch98->com98 & ch99->com99;
ch98->com98 & ~ch99->com99;
~ch98->com98 & ch99->com99;
ch1->com1;
etc......

 (we need two dummy channels because we need to make sure each scan list entry contains at least one connect; otherwise, we don't send a trigger).

Definitely let us know if you have any questions.  The level of control you're looking for is more of a niche application.  Apologies if it's confusing, but it's not a typical application.

[Now_With_Underscores]

Pushing the code into a standalone executable might help, but only to the variability of Windows and only if the code itself is written properly and doesn't consume too much CPU time.  If, for example, your code is running a while loop without any delay timer, we could easily consume 100% of our CPU time running the loop 10,000,000 times a second.

The latency from the PXIe interface to the input on the 2569 is much much much lower than 1ms.  MXI is essentially a high speed, low latency extension of your PCI bus.  Keep in mind we use the same MXI systems to deterministically send data between chassis full of DSA/RF/DAQ equipment in fractions of microseconds.  Being that this bus typically operates in the hundred MHz + range, I'd guess the latency is at most 10ns.

For specifications, there's really no way we could reliably specify the software-timed scan rate, jitter, accuracy, etc, because each computer is unique and may contain a different version of Windows, different installed software, different CPU, etc.

[MI-CAL]

Ok. 

Here is what I would like to do.  See the attached.

First, using the Graphical Programming language, how would I configure the 6225 to send a digital pulse to engage the other 2 Slave relays based on the Master relay (relay 1)?

Second, could I actually control it from the PXIe interface so that every 30 seconds the counter could execute off another Master, have different Slaves respond, and/or change the sequence of events?

[MI-CAL]

One more update for you.

First, to explain why we didn't go with a FET based system.  I believe I stated before that the risk of a lack of true electrical isolation from the your FET board exists for our concerns.  The relay system was the only way to ensure true circuit isolation from your board.

Second, regarding the issue (relay or not):

Originally, we set the system so that 10 independent systems could be tested, each with 10 channels (utilizing the 100 relays we paid for).  We also have a script file which we used to randomize the sequence of each of the 10 channels.  We generated the vi so that to minimize the processing time and to better perform an A:B comparison on each system, we ganged each channel on the 10 independant systems, so channel 1 on system 1 would turn on simultaneously with channel 1 on the other 9 systems (and so on).

However, in requesting to switch 100 channels, we got a 20+ms* delay between switching events.  Clearly not acceptable when we were expecting a 1ms delay.

Now we reduced our demand of the 2569 to only 3 channels switching on one system just to see if there would be any improvements in the time between switch close requests, and viola, the system is switching as we intended with only a 1ms* delay.

This clearly tells me that either the overhead in the 2569 board is the issue, or the number of requested channels between the PC and the 2569 is the culprit.

Not knowing the underpinnings of your board, why is it that if I call for 100 Relays on the board to turn on, 10 at a time simultaneously (which they do very nicely by the way), with a 1ms delay between each sequence of 10, I get a 20+ms delay between the activations? 

YET, when I call as few as 3 channels to switch on with 1ms between each request, the delay between the requested sequence is nearly nonexistent?

I don't think a counter will help me unless it was independantly linked to each individual relay (or a gang of 10 in my case).

MS Windows (as much as I like to dislike them too) apparently is not the problem in this case to our knowledge.

*The data was acquired using an Agilent logic analyzer.

[MI-CAL]

Just curious.  Have you confirmed this finding and if you have, what is it?  With a true switch board, can I honestly eliminate the delay in the switching?