06-10-2010 02:32 PM
Hi.
I'm trying to create a handshaking loop with DMM (PXI-4071), SWITCH (PXI-2569) and MUX (PXI-2575). All three instruments are in segment 2 of PXI-1045 chassis (slots 8, 9 and 10) and I am using PXI trigger lanes to route triggers.
I followed the NI article 'Multi-module Scanning with National Instruments Switches' - I modified the NI SWITCH example 'niSwitchDMMSwitchHandshaking' to configure the other SWITCH but when I tried to run the example, I got an error:
0xbffa6b9a - No registered lines could be found between the device in the route. (pop-up screenshot is in the attachment). It is the niSwitch_InitiateScan function for the second Switch that returned the error.
Changing PIX trigger lanes has no effect.
I tried both CVI and LabVIEW examples with the same result.
I even tried to use two 2575 MUXes - same result.
Can anybody tell me what am I doing wrong?
Solved! Go to Solution.
06-11-2010 05:24 PM - edited 06-11-2010 05:31 PM
Hi Pavel,
For the purposes of this post, I'll define the measurement complete signal (sent by the DMM to the switch modules after each measurement) as 'MC' and place it on TTL0.
For the
purposes of this post, I'll define the scan advanced signal (sent by the
switch module(s) to the DMM once the relays have settled) as 'SA' and place
it on TTL1.
You mentioned you're using NI-Switch, which is NI's IVI compliant switch API. Since the IVI Foundation regulates the behavior of IVI compliant software, we must adhere to their rules when implementing our API. Unfortunately, the IVI switch standard doesn't provide a method to control arbiting of triggers between multiple switch modules simultaneously.
Let's look at what happens when we setup a system with multiple switch modules handshaking with a single DMM. The DMM is going to take a measurement and then send MC on TTL0. Meanwhile, each switch is listening to TTL0, waiting for the MC pulse. When the MC pulse is received, each switch sets the relays according to its next scan list entry, waits for debounce, and then sends SA on TTL1. The problem we run into here is that depending on the switch module, number of relays connected simultaneously, jitter, etc, it's possible that one module will send the SA trigger on TTL1 before the other. Since the IVI spec doesn't provide any way to implement a 'master' switch or an arbitor, it's impossible to implement a system such that only the last switch that settles sends a trigger. Therefore, what happens is we get a whole bunch of switch modules sending triggers at slightly different times onto TTL1. If one switch is driving TTL1 high while the others are driving TTL1 lo, it's remotely possible that we could damage the TTL circuitry on the PXI backplane.
To date, NI hasn't seen any failures due to simultaneously driving the TTL lines high and low at the same time with NI switch hardware, but it is theoretically possible that damage could occur. For this reason, NI implemented a change in DAQmx 9.0.0, 9.0.1, and 9.0.2 that prevents a user from setting up handshaking with multiple switch modules while using NI-Switch. What does DAQmx have to do with this, you might ask? A component installed with DAQmx is responsible for verifying the triggers are valid.
Customers with existing NI-Switch multi-module handshaking applications will find that upon upgrading to any of the above three versions of DAQmx, the error you observed will occur. We've evaluated this customer feedback and have decided to revert to the previous functionality in a yet-to-be released version of DAQmx. Please note that NI does not advise driving the same TTL line with multiple sources due to the chance that we'll double-drive the line. Therefore, it goes with out saying that NI does not advise using NI-Switch in multi-module handshaking applications. We do, however, still recommend NI-Switch for Syncrhonous triggering because the switches never send triggers (in synchronous mode, the DMM just waits a predefined amount of time before switching).
Note that if you use the DAQmx Switch API, we're no longer bound to the IVI spec, which means we have an arbitor that ensures only one switch module drives the SA trigger on TTL1. NI highly recommends that customers evaluate using the DAQmx switching API for multi-switch handshaking applications. An example DAQmx handshaking application for the DAQmx Switch API is located in Example Finder»Hardware Input and Output»DAQmx»Switches»Switch Scanning with DMM - Handshaking.vi.
Note that in DAQmx, we'll only have one scan list, regardless of the number of switches we have. Note that the syntax in DAQmx scanning is different than NI-Switch. I'll defer a detailed explanation of the differences to the DAQmx and NI-Switch Help (search for 'scan list'), but in short, we'll need to include the DAQmx Device name prior to each connection. For example, in NI-Switch, if we want to connect CH1 to Com1:
CH1->Com1;
In DAQmx, we'll need to include the Device name:
Dev1\CH1->Com1;
Note that to add additional switch modules in the DAQmx API, we simply call the Set Topology and Reset VI multiple times:
DAQmx keeps the session loaded in memory and as I noted above; we define which switch does the action as part of the scan list entry.
If you'd still like to use NI-Switch, you could roll back to DAQmx 8.9.5 or previous, or if you want to stick with 9.0.x, I highly recommend that we daisy chain the triggers as follows:
DMM Measurement Complete to Advance Trigger on Switch1 via TTL0
Scan Advance from Switch1 to Advance Trigger on Switch2 via TTL1
Scan Advance from Switch2 to Trigger Source on DMM via TTL2
Note that we'll need an additional TTL line for each switch module. Also note that some switch modules allow front panel triggers, which reduces the number of TTL lines we'll need on the backplane, but which requires external wiring between switch modules.
06-14-2010 09:21 AM - edited 06-14-2010 09:23 AM
Thank you, sir knight, for your quick and detailed response :).
Unfortunately I must stick to NI-Switch drivers so I cannot use DAQmx directly (company-wide requirements).
Cold you specify which component exactly is responsible for validating the TTL trigger routes (and possibly it's version)?
BTW I have DAQmx version 8.9.5 installed - I started with NOV 08 package (CVI + device drivers, DAQmx version 8.7.2) but because of DMM soft front panel error in NI-DMM version 2.9, I installed the latest available NI-DMM (I think it's 3.2.2). Together with this, MAX version 4.6.2 and DAQmx 8.9.5 were installed. This caused the problem with trigger lines conflict.
Un-installing DAQmx and NI-DMM and going back to original NOV 08 versions doesn't help and the problem with triggers remains. Uninstalling MAX requires uninstalling almost every device driver (plus I got the non-functioning DMM soft from panel, plus MAX 4.6.2 has a few nice features I would like to keep if possible).
So the easiest way for me is to replace only the component (I assume it's a dll) that validates the trigger routes.
Thank you,
Pavel
06-14-2010 11:43 AM
Hi Pavel,
I verified that the component that controls the TTL routing for PXI is included in NI-DMM 3.0.2 (the most recent version as of 6/14/2010). NI-DMM 3.0.1 contains an older version of the TTL routing code and will therefore allow us to place multiple scan advance complete lines onto the same trigger.
Unfortunately, the component that controls TTL routing is one of the lower building blocks of the installed NI Software, and as such we don't expose it to the user. In order to get this to work, we'd need to uninstall nearly all NI software components, which is a major undertaking. Here's what I'd recommend instead:
For the time being, let's daisy chain the triggers from one switch to the next. This will allow us to begin development in NI-Switch; as soon as NI releases a fix, you'll simply change the triggers such that they all point to the same TTL line. This will allow the switches to operate in parallel instead of in series, so the switch portion of your project will work faster.
If we absolutely must operate the switches in parallel, I'd recommend either uninstalling all NI software or getting a machine with a fresh install of XP, and then installing software no newer than DAQmx 8.9.5, NI-DMM 3.0.1, and NI-Switch3.8.
As I mentioned previously, NI is aware of the break in backwards compatability and we're committed to reintroducing the old functionality in a future version of the driver.
Keep this thread bookmarked and post back in a month or so and I'll let you know if we have any updates.
Have a great day!
06-14-2010 11:53 AM - edited 06-14-2010 11:56 AM
One last note:
We can use NI-Switch with multiple modules in parallel if and only if the switches scan such that only one connects relays at a time. This is because NI switch modules only output a scan advance complete signal if any relays on said module connect as part of the scan list entry. For example:
Scan list for switch 1:
ch0->com;ch1->com;ch2->com;;;;
Scan list for switch 2:
;;;ch6->com;ch7->com;ch7->com;
If the above two switch modules are set to drive the same scan advance complete line, we're guaranteed that only one module will send a trigger at a time because no two switch modules connect relays at the same time. This is because the first switch connects relays on the 1st, 2nd and 3rd triggers, while the second switch does not connect relays on the 1st, 2nd and 3rd triggers. The second switch module then makes connections on the 4th, 5th, and 6th triggers, while the first module does not. NI only recommends multi-switch module synchronization with NI-Switch if the above conditions are true, as this prevents double driving the same TTL line.
The following scan lists are not recommended (double drive points in bold😞
Scan list for switch 1:
ch0->com;ch1->com;ch2->com;
Scan list for switch 2:
ch6->com;ch7->com;ch7->com;
Scan list for switch 1:
;;ch0->com;ch1->com;ch2->com;
Scan list for switch 2:
ch6->com;ch7->com;ch7->com;;;
Also note that the following scan list would hang indefinitely because there's a point in both scan lists where no relays are connected, and therefore none of the switch module will send a trigger, so the poor DMM will just wait until it times out (I've bolded the portion where we'll hang):
Scan list for switch 1:
ch0->com;ch1->com;ch2->com;;;;;
Scan list for switch 2:
;;;;ch6->com;ch7->com;ch7->com;
For more information on scan list syntax, refer to the scan list section of the NI-Switches Help document.