PXI-2575 minimum load
I work on new project. I will use multimeter PXI-4070 with switch mux PXI-2575. The multimeter will measure voltage on differents tests points of a circuit in test. The input impedance of PXI-4070 are 10Mohms in measure voltage mode. So the current in relays of PXI-2575 will be very low <2.4uA. All voltages to measure are between 0.5VDC et 24VDC. There are also a measure of 8VaC and 16VAC.
The relay minimum load in datasheet of PXI2575 FEV2008 are "10uA at 10uV DC".
The relay minimum load in datasheet of PXI2575 APR2009 are "20mV/1mA".
My questions:
What the minimum load change in 2009 or it's a error in documentation?
What the real signification of "20mV/1mA"?
The current must be always greater than 1mA or periodicly greater than 1mA?
The voltage are voltage to init contact or the voltage must be always greater than 20mV?
What a current less than 1mA decrease life of relay?
If I measure AC voltage what the consequence on the measure when the current are between -1mA and 1mA?
Thank you!
How is this related to the Excel add-on program called 'Measure'. I think you should post to the multi-function DAQ board.
Similar Messages
-
Hi,
I am using PXI-2575 mux with PXI-1044 chasis. I am using .NET C# to control 2575 during a year. In my setup, I am using the mux to read DC voltage or 2-wire resistance generally. It seemed work successfully up to last 2 mounts. Suddenly, some of the channels of mux did not work. I read wrong DC voltage(like 1V instead of 4V or sometimes nothing). Mux is passing the self test in Measurement&Automation, path to COM seems correct but read voltage is wrong. I also hear the swicthing sound. Then, i changed it with different 2575. After a while, some channels of new 2575 were broken. I replaced the broken 2575 with the old broken 2575 and all channels worked successfully.(!) Why this situation happens?
Finally, last day, all the channels of the mux were broken. I could not read anything from COM. I also heared swiching sounds. How can i fix it? When i replace the new one, the new one works succesfully. What is the problem?
Any help would be appreciated.Knights Who Say NI wrote:
Hey unver,
The self test feature only verifies that the digital backend of the module is functional. The 2575 does not have path resistance circuitry.
Most likely, your relays have reached end of life. You can check the number of cycles in the relay tab of the Switch Soft Front Panel. Note that the number of cycles before failure is largely a function of the reactance of the circuitry plugged into the module; relay cycle life before failure is listed for a purely resistive load, so it's likely that the number of cycles is much less than those figures listed in the specification sheet.
For example, if you're muxing through channels on the 2575 taking voltage measurements, the ~200pF capacitance of the DMM pluss the 50pF per foot of cable is going to store whatever currently connected voltage potential is and then rapidly dissipate the stored charge while the next channel is connecting. When this occurs, there is a relatively large inrush current. Likewise, if your DUT is inductive, the current running through a particular connection will continue to flow as the relay opens due to the same current pushing across a higher resistance (an open relay, instead of closed)...
An easy method to reduce the connect capacitance is to add a couple hundred ohm series resistance to your voltage channels. Likewise, adding a flyback diode to each channel will prevent overvoltage on inductive loads. The flyback diode will also work for the 2-wire resistance, but note that the series resistance won't (it will add to your measurement). To solve this problem, I recommend 4-wire resistance measurements with 200 Ohm series resistors (or whatever) on each leg. The additional series resistance does not affect the measurement when performing 4-wire resistance measurements.
Of course, I've jumped the gun a bit, so first, a little troubleshooting. You obviously have a DMM, so let's set it to resistance and plug it into either side of the suspect channel. Then cycle the relay a few hundred times and see if the resistance is consistent on each closure. If it varies greatly, the relays have probably reached end of life. For the voltage readings to be off 3 volts, the relays are going to need to exhibit some pretty enormous closed resistance values... something like 10MOhm... if this is the case, then the relay current/voltage limits have likely been exceeded.
I also recommend scoping the inrush current with an oscilloscope and a series 0.01Ω resistor. Likewise, measure the flyback voltage when opening the relay with a different channel on the same scope... obviously, you'll want to do this with your 2575 plugged into the DUT and operating in its normal environment...
From your description, I'm almost certain the troubleshooting steps will indicate one or more relays have failed. If I had to guess, I'd say it's K15.
Hi John ,
I think this is not the case. Because, highest switch usage is 117(I think this is very very low) and I am doing the voltage measurements over 10kOhm resistance. Hence, capacitive effect is also not the cause. After i had written my previous message, i prepared a basic set up that applies 5 volts one by one by one to all of the 98 input ports of the broken 2575 and reads the com port with NI6259 daq device. I did this process many times with different time periods. As I guest, the device worked successfully at all the tests. Hence, cause of the problem is different and i still need a help. -
I am having problems with the resistance across relays on a PXI-2575 increasing over time (faster than expected). I am using a PXI-2575 in combination with a PXI-4070 for manufacturing test. In some cases I am looking for an expected short circuit. The data sheet states that with no voltage applied (which I have none) I should see < 1 ohm for up to 2.5 million cycles. However, I am seeing upwards of 16 ohms across a particular relay after ~2500 cycles in many cases. I have a total 6 of these setups, and I am finding myself replacing PXI-2575 cards after less than 1 year of service due to these high resistances.
To prove to myself that it is the switch matrix (after measuring the UUT with a Fluke DMM) I used the following setup:
PXI-4070 DMM
PXI-2575 Switch Matrix
LFH200 Cable
24 awg wire
The PXI-4070 is configured for a 2-wire resistance measurement. The PXI-2575 is configured as a 95x1 2-wire mux. The DMM + terminal is connected to pin 46 of Backshell 0 (CH22+) and the - terminal is connected to pin 47 of Backshell 0 (CH22-). A small 24 awg jumper wire is used between pins 23 and 34 of Backshell 3 (COM+ and COM-). On a brand new switch matrix I see ~0.16 ohms using this test. On the most recent one I pulled out of production use, I saw ~16 ohms initially, with it falling to ~5 ohms after leaving it connected for about 5 minutes.
I am up to 4 PXI-2575 cards that suffer from this issue. According to the data sheet I should not be seeing this. Any help would be appreciated.
Thanks
Jonathan RiceSteven
Thanks for the reply. I have done some more testing as you have asked. I realized I actually have 11 PXI-2575's, recently purchased 2 spares, and 3 more for new test equipment. They are all used in an identical manner.
We have made a total of 3 purchases. The first was for 6 PXI-2575's, the next was for 2 (spares), and the final was 3. With all of the swapping around, I am not sure where these failing ones came from at the moment, other than to say they were not part of the most recent purchase of 3. I am more than happy to provide serial numbers, if you can tell me which of the stickers on the board is the serial number. There are two identical looking stickers, one on each of the boards, that have different serial numbers on them.
Below is the data I have collected. Cards 5 & 6 can be considered "good" cards. Note that their readings did not change from their initial readings. They are from the most recent batch. We have no examples of cards with lots of cycles on them that do not exhibit this behavior. Prior to attempt 1 the cards had been powered off and removed from chassis anywhere from days to months. Between attempts 1 and 2 several switch cycles were performed and power was cycled on the PXI and the PC.
*All readings are in Ohms.
Below is a diagram of the setup I am using to test the switch matrices after they fail in the field.
Installing a new PXI-2575 immediately resolves the issue in the test set, and that test set continues to work for another several months.
Any help would be appreciated.
Thanks
Jonathan Rice -
Why is the PXI-2575 not recommended for 2-wire resistance measurements?
The spec for the NI PXI/PXIe-2575 says "Note The NI PXI/PXIe-25-75 is not recommended for 2-wire resistance measurements". Why is this? If I want to perform 2-wire resistance measurements, what would be a good alternative?
It really depends on your measurement. The problem with 2-wire resistance measurements is that the resistance of the wiring and the switch path will be included in your measurement. If you are measuring in the kOhms to MOhms, this should be neglible. But measuring anything smaller will add a large error. That is why 4-wire resistance measurements are recommended. The sense lines can measure the voltage across the part you actually want to measure and an accurate measurement can be made.
This is true for all switches.
My philosophy is to use 4-wire measurements except when checking for an open.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines -
PXI-5105 Minimum Voltage Range
Hi,
I searched the forums for this question but did not get a concrete answer. I'm using a Kulite ITQ-1000 pressure transducer attached to a RDP signal conditioner/amplifier which is then fed into the PXI-5105. The signal has been set so that the maximum rated pressure outputs +10V from the RDP unit. My question is regarding the minimum voltage level... I noticed on the specifications for the 5105 that there is a "Minimum Voltage Range" of -25mV,25mV. Does this mean that the minimum voltage input that should be fed into the 5105 should be no less than, in my case of only positive voltage, 25mV?
Thanks,
RyanNevermind... I figured it out
-
Any reason to scan PXI-2575 and SCXI-1127 in a particular order?
Hello-
Is there any reason to prefer one scan-list order over any other? specifically is it better to scan through ch0, ch1, ch2, etc rather than randomly?
It doesnt seem like it would matter.. but many DAQ devices behave strangely if you scan them in ascending order (eg 0, 1, 2) and thus I always scan them in descending (e.g. 7, 6, 5, ...)
thanks-
bradBrad,
Simply based on the switch modules, there should be no difference in which scan list is prefferable.
Can you elaborate on the strange behavior you have seen on some DAQ
devices? The only interesting behavior I can recall that may be
fixed by scan order is when certain channels are saturated and "ghost" onto other channels. If this is the case, follow the steps in the linked KnowledgeBase to remedy the problem.
What data acquisition device are you using along with your switch modules? What types of signals are you measuring?
Have a great day!
Travis W -
My Dear friends:
I feel very blue. Could you help me?
The case is: We have had a suit of ATE, based on PXI2575, PXI 2569, PXI 6723, PXI 4070. In addition, the TPS developed on MFC has been finished by others.
Now, my tutor asked me to study of “interchange of instrument” based our ATE. I look up some material on the Internet, some books in the library and read some papers. However, it takes no effects and some information is opposite. Here are always some questions puzzling me：
The difference of VISA lib and VXIplug&play drivers? Can we control the instrument cards only by the VISA lib and specific SCPI sentences? You know that the instrument vendors only supply us with driver programs but SCPI, so that we can only use the VISA functions. How can we solve the problem?
What’s more, even if we can use VISA lib and specific SCPI to control the instruments from the vendor, can we use them to control the instruments supplied by other vendors?
The standard of VISA and IVI? Is IVI built on the basis of VISA lib or the VXIplug&play drivers?
Our programs encapsulates “Class CDriveFunc”(the affix) and we can call the functions in other places. Then I only need to set the logic names adapted to the instruments (such Dev12-PXI 2575) and it will make the equipment to operate well.
Can you tell me our program is based on IVI or VISA lib?
Do our TPS realize the IVI ?
Giving that my ATE is based on IVI, does it mean that if my ATE is installed with another compatible instrument card, my TPS will not be modified and I only need to change the relevant logic names of the instrument cards to make the TPS work well?
If I only need to convert the logic names, which place is allowed I to set them? In the MAX of NI, whether need I develop a platform? Another case is that if my instrument card is not from NI corporation, which measures should I take?
Can my ATE based on IVI adapt to any platform, such as VXI, PCI, even GPIB? And if I want my ATE based on PXI to work well based VXI or PCI, what can I do?
If my ATE used the PXI controller, does it mean that I must install the NI-VISA? How can I guarantee my ATE used by another board work well?
If the board I used does not belong the standard class, such as PXI 6723(AO board), boards for communication(RS-232), what need I do?
8. What differences are between the Labview/CVI, measurement studio and VC++?
My development is VC++ 6.0, can it support IVI?
At last, I am moved if you can answer some questions above or give me some suggestions to me? If you come to Beijing, please remember to contact with me.
Thanks a lot!
A loser from Beijing
Attachments:
DriveFunc(cpp).txt 4 KB
DriveFunc(h).txt 21 KBGood Morning Sir,
Can you tell me, what all changes you have done in PLL.vi to run in fpga 7831R? Did your problem got sorted out? -
PXI-6509 Error occurred at Reset Device
Greetings Everyone,
I recently had three (3) PXI-6509's fail in one of my Test Stations. I tried to reset them in MAX and received the following message: "The device reset has failed. The error report from the device driver is as follows: Error -224903 occurred at Reset Device.". I also received "Error -50152". After that while I had the stores list up of all installed boards, the three (3) PXI-6509's removed themselves from the list. I'm wondering what these error codes are telling me. The pop up error dialogue box stated that the "Possible Reason(s): Internal Software Error occurred in Static_Digital_software". I'm also curious as to what this is relating to. I replaced all three (3) board from a NEW chassis that I'm bringing up for use and everything thing is fine. I tried plugging these failed boards into my other chassis and the computer will not even boot up. Thank you in advance for any information that you provide that will help me in understanding what may have caused this to happen. The system was working fine up to lunch time and after lunch is when the problems started.
Regards,
Scott
Solved!
Go to Solution.Greetings Nick,
Here is the course of events that led up to the problem being described.
While testing UUT’s (Company Product): (PXI-1044 with PXI-8101(XP), GPIB Controller and various PXI cards installed)
Before Lunch everything was working well. It was after lunch that the following events took place.
a) Test Sequence hung up during External Power Supply ramp up in which the D-I/O are used to switch relays inside the ITA (Interface Test Adaptor) to connect the DMM to the Power Supply that is in use at the particular time in the test sequence. This has happened a couple times before, but NO error ever happened and just re-booting the system cleared it.
b) The next thing that was performed was shutting down TestStand and Labview.
c) The next thing that was performed was executing “MAX”.
d) Once in “MAX”, I normally try to RESET all of the PXI cards, which is usually successful, but not in this case. The error pop up came up with the two (2) different error codes (-224903 and -50152). Please explain what the “Static-Digital Software is?
e) I shutdown “MAX” and Re-Booted the system.
f) After Re-Boot completed, I executed “MAX” once again and clicked My System, Devices and Interfaces and PXI-1044 “Chassis 1”.
g) I tried to reset the NI PXI-6509 “PXI1Slot7” and received the pop-up error as described.
h) Upon clicking OK. The PXI1Slot7 and PXI1Slot8 removed themselves from the stores list of cards installed and the icon next to NI PXI-6509 “PXI1Slot9” changed from a little green board icon to a white board icon with a little red ‘x’ inside it.
i) Next, I removed all three (3) PXI-6509 from a NEW chassis in a NEW TestStand that I planned to bring on line in a couple of weeks. I placed these boards into the TestStand that is failing and everything is working well once again. I ran some diagnostics and everything checks out OK.
j) Next, I took the failing boards and placed them into the NEW chassis and the computer wouldn’t even boot up.
k) Next I removed two (2) (PXI1Slot7 and PXI1Slot8) of the boards and tried to boot the computer and the computer booted up.
l) I proceeded to execute “MAX” and check the stores list only to find that the board (PXI1Slot9) was not even in the category of the PXI-1044 Chassis1 but outside it and it also had the white icon with a little red ‘x’. It also affected the PXI-2575 in PXI1Slot10, which had a white icon and little red ‘x’. I removed the board from PXI1Slot9 and re-booted the system and PXI1Slot10 recovered with the normal green icon that is usually next to it.
What I need to understand is what “Static-Digital software” is and what the errors are telling me. The fact that three (3) NEW board installed into the chassis and function 100% tells me that there is something wrong with the three (3) boards that I removed from the chassis and that nothing else seems to be wrong with the chassis.
The fact that installing the three (3) boards into a NEW chassis and the computer not booting is something of concern. I’m trying to understand what could have caused this to happen in the first place so I can be prevented in the future.
Regards,
Scott -
I honostly dont know what PXI bus mastering is, but I belive I need to find out pretty soon. I have a project in which I will be needing to take in 16 million samples, 8 million on 2 channels from a PXI-5102 digitizer, and then analyze. The board itself i know can not handle this, but what it can do is "16 million samples to host RAM via PXI bus mastering " This is great, I need 16 million samples, now... how do I do this? Anyhting to get me in the right direction would eb greatly appreciated, thank you very much.
-Mark""I honostly dont know what PXI bus mastering is, but I belive I need to find out pretty soon."
I do not think you have to worry about what it is unless you plan on dropping this device in a non-NI chassis or do not plan on using NI-drivers.
PXI bus mastering
is a method interfaces can use to control the PXI bus in order to transfer dat from on-board buffers into system memory (or other devcies).
"Back in the Old days" (i.e. 30MHz CPU's) bus mastering was not available on all PCI busses. THen latter on it was available in some PCI slot on some computers but but not all (i.e. 400 Mhz CPU's).
I have never heard of an issues re: bus mastering in PXI chassis.
So...
Drop that board in a PXI chassis and load up NI-DAQ, configure it, and you should be
good to go. NI did all of the hardwork for you!
If want to be certain before purchasing the board just tell ask the sales person to have someone send you an e-mail indicating that the devices will do "X". I have done this anytime I was less than certain re: the fine print in a device spec.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction -
HI there,
I have a PXI-1044 chassis loaded with varios NI cards, such as arbs, DIO's analogues and data aquasition cards.
I have also designed my own "Passive" PCB that just uses the supply rails on the cPCI P1 connector.
However I find that the -12V rail is not there on my own card.
Is there a power sequencer or device that turns off the rails to cards that doesnt tell the controller that it needs them ?
Can I frig this using MAX or put a wire link on the PCB connector to another pin to get the -12V line enabled ?
This is proving to be a real show stopper !
All other PXI Cards fitted to the rack function correctly !
Help please !
John
my real email address is [email protected]John,
-12V is supplied to the slots regardless of whether there's a card present or not. If you're sure that you're looking at the right line, you may have a bad/damaged power supply or backplane.
You should probably check the voltage at the "Remote Inhibit and Voltage Monitoring" connector on the back of the chassis with a DMM. The pinout is on page 2-9 of the detailed specifications.
- Robert -
Current measurements between 4071 and 2575 sometimes not correct
I'm using PXI-4071 and a PXIe-2575 in handshaking mode with a scan list.
The DMM is measuring current and the MUX is in 1x196 mode.
When running the scan list, I rarely (randomly) get a very small measurement in the nA to uA (when it should be 4-20mA). I'll run the scan list again and that channel will be correct, so it doesn't seem to correspond to a channel.
I've tried increasing the settling time of both the DMM and the MUX, but neither have had any effect.
Any help would be great.
Thanks,
Caleb Swieson
Solved!
Go to Solution.Cswieson,
Is the relay board relatively old? If a board is close to end of life, there is a chance that the relay will sporatically not close and/or open. If the relay is stuck open, the DMM might measure very low current because no current is flowing (and only noise is coming through).
Frank,
National Instruments
Staff Software Project Engineer -
High resistance measurement by 4071 and 2575
I used NI 4071 to measure a high resistance. The resistance is 78.6MΩ.
When I use 4071 directly to measure it(2-wire), the result is 78.58MΩ.
The measurement is ok. But wnen I connect the resistance to NI Switch 2575,
the result become smaller, about 76.4MΩ。
It is strange, and how to deal with the problem? ThanksHi faili,
I have never witnessed this issue before, so I attempted to reproduce your problem. I used the following hardware:
I PXI-4071 DMM
NI PXI-2575 Switch
LFH200 to 50-Pin DSub Switch Cable
NI TBX-50, 50 Pin Dsub Screw Terminal Block
Short 24-gauge wires between resistors and terminal block
Resistor Combination in breadboard (28 2.7MΩ resistors = 75.6MΩ)
I used the following procedure:
Opened Switch Soft Front Panel
Configured PXI-2575 in 2-wire 95x1 Topology
Connected ch94->com in Switch Soft Front Panel
Wired CH94+ (50-pin DSub pin 21) to one side of 75.6Mohm resistance, CH94- (50-pin DSub pin 22) to other side
I made the following measurements:
Opened DMM Soft Front Panel
With DMM, measured one side of resistance to other side (after settling) = 75.6MΩ
Wired COM+ (50-pin DSub pin 23) to DMM HI Lead, COM- (50-pin DSub pin 24) to DMM LO Lead
With DMM, measured COM+ to COM- (after settling) = 75.6MΩ
So, I wasn't able to reproduce your issue. Perhaps the above will help. Can you tell me more about your system and how it is configured? Perhaps there is a hidden resistance to GND somewhere in your setup. Looking at the equation, to receive an error of:
78.6MΩ -76.4MΩ = 2.2MΩ (or 2.8%)
you could have a hidden 2.73GΩ path to GND. How are you making your connections to the PXI-2575? Just a thought...
Let me know if you have further questions or if this does not resolve your issue!Chad Erickson
Switch Product Support Engineer
NI - USA -
Keep switch channel selected for multiple steps in a scan list
Hi,
I have 3 switches (PXI-2575), one to apply a source to a given line, one to apply a sink, a one to apply a DMM. I have all three switches triggering off each other as well as a DMM (PXI-4070). I apply a source to any given line with the source switch and then cycle through other lines using the DMM switch. Problem is i want to keep the wear on the relays of the source switch to a minimum (for each cycle through the DMM lines I'm selecting same source pin multiple times!). Is there a command for scan lists or some way of setting up the switches so that this can be done?
I thought it might be possible to use the debounce command ';' on its own to signify that i don't want to change the channel selection but this does not appear to work, the DMM times out whilst waiting for a trigger on the second reading. Simplified example scan list that i currently have:
Break Mode: No Action
Source Switch: ch0->com;;;;~ch0->com & ch1->com...
DMM Switch: ch100->com;~ch100->com & ch101->com;~ch101->com & ch102->com;~ch102->com & ch103->com;~ch103->com & ch100->com...
I've also tried selecting the same channel in subsquent scan list entries which flags up error saying explicit connection already exists between the channels.
So is the only possibility just to needlessly wear out the relays?!Hi leon007,
I can understand your desire to keep the wear on the relays of the Source switch to a minimum. I have a few questions, but we should be able to get the application working without needlessly wearing out the relays.
1. Can I assume you are using NI-SWITCH to program this application? If you are using the NI-DAQmx Switch API, please let me know.
2. When you state "I have all three switches triggering off each other as well as a DMM", can I assume (leaving out the Sink switch for now) the scan advanced output of the Source switch (TTL0) is sent to the trigger input of the DMM switch (TTL0), the scan advanced output of the DMM switch (TTL1) is sent to the trigger source of the DMM (TTL1), and the measurement complete destination of the DMM (TTL2) is sent to the trigger input of the Source switch (TTL2)?
3. If you are still having troubles after this post, I would like to know the following so I can assist in testing the issue: What versions of NI-DAQmx and NI-SWITCH do you have installed?
OK, that's it for my questions. Now for yours. Unfortunately, the debounce command ';' didn't work because it is simply a dummy entry - without creating a connection no scan advanced signal will be sent. I've noticed this is not documented well in our help file, and I apologize for that. However, attempting to create a connection where one already exists should be an error. Either the user is attempting to redundantly connect channels (which shouldn't happen if niSwitch Get Relay Position is used), or there is a driver issue.
To keep the relay wear to a minimum, I want to suggest a couple of ideas.
1. Use only one trigger line for the DMM's measurement complete and one trigger line for all the switches scan advanced outputs. To use this option, it cannot matter in your application which switch operates first, and which operates last. The switch that always makes a connection (the DMM switch) will send a scan advanced output trigger with a set scan delay (configured in niSwitch Configure Scan Trigger) that should accommodate for all the switches. This option may add delay in your application, but you will save relay life.
2. Use the DAQmx Switch API and the '&&' command between seperate switch connections. In the DAQmx Switch API, you use just one scan list for all switch modules. For example, we would perform the example scan list entries you provided with the following scan list:
/Source/ch0->com && /DMM Switch/ch100->com; ~/DMM Switch/ch100->com & /DMM Switch/ch101->com; ~/DMM Switch/ch101->com & /DMM Switch/ch102->com; ~/DMM Switch/ch102->com & /DMM Switch/ch103->com; ~/Source/ch0->com & /Source/ch1->com && ~/DMM Switch/ch103->com & /DMM Switch/ch100->com...
The above connects the Source switch CH0 to COM, waits for the relays to settle, connects the DMM switch CH100 to COM, sends the scan advanced output signal, and waits for the trigger input before executing the next scan list entry. This method will keep an order to the madness, as you will have the power to decide which switch operates first, and which operates last.
Let me know if I assumed anything incorrectly or if neither option works for you!
Chad Erickson
Switch Product Support Engineer
NI - USA -
Handshaking DMM with multiple Switch devices - DAQmx error
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.
Attachments:
errror1.JPG 26 KBHi 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.
Message Edited by Knights Who Say NI on 06-11-2010 05:25 PM
Message Edited by Knights Who Say NI on 06-11-2010 05:30 PM
Message Edited by Knights Who Say NI on 06-11-2010 05:30 PM
Message Edited by Knights Who Say NI on 06-11-2010 05:31 PM
-John Sullivan
Analog Engineer -
Hello, i hope someone among you good guys can help me with a very annoying issue i am experiencing in my system, that is driving me mad and that i could not solve in a month of tries. I own an HTPC based on the following configuration:
AMD Phenom II X4 945 CPU
MSI 990FXA-GD80 M/B
8Gb Corsair XMS3 DDR (2x4Gb)
Corsair AX-650 PSU
Samsung 256Gb 830 SATA SSD (2 partitions, system + data), AHCI SATA mode
Seagate 3Tb Barracuda SATA HDD with GPT table
ATI HD 5750 video card (2 displays attached)
Terratec Cinergy DVB-S2 card
Hauppauge HVR-2200 DVB-T card
Silverstone LC-16m case with Imon VFD + Imon Pad remote and USB card reader
Internal serial port, 1394 and eSATA ports enabled
Logitech USB Webcam, USB speakers and USB G110 illuminated keyboard
Toshiba laser mouse
Windows 7 x64 sp1, windows Media Center + DVBLink TV source, MST and various other programs.
Hibernation disabled
No overclok
I used this HTPC with much satisfaction from nearly 1 year, never experiencing an issue: i used to keep it in S3 mode 24/7 and it always got out from S3 state to record TV programs without any problem.
I installed the second drive, the 3Tb Seagate Barracuda, the first week of september. Then a day between the firsts of october i installed Mediaportal to give it a try; fearing system modifications by that software, i saved a backup image in my second drive. After a pair of days (or maybe at that time i noticed it for the first time), the issue has started.
The issue consists in a strange system freeze when the HTPC tries to wake up from S3: when the HTPC tries to exit S3 state the case led gets on, the HDD led blinks once or twice and then fans start running loudly and the HTPC freezes BEFORE the display can show any image (it remains black and goes to power saving mode) - power led on and HDD led off. No blue screen (the display is off). No memory dump. Keyboard's leds off. No manual crash dump possible. All i can do is keep power switch pressed until system complete shutdown.
But the really strange thing is that it happens ONLY once or twice a day, in the rest of the times the HTPC gets to wake up from S3 normally without any issue: it usually wakes up from S3 a number of times per day (7/8 minimum), but only 1/2 times the freeze issue happens (more often early in the morning or around twilight, seldom in other time slots)... Also, when on, the HTPC runs flawlessly as ever.
Thinking MP was guilty in some way, i restored the backup image but unfortunately the issue didn't disappear! So MP was no to blame... something different had happened to my PC...
I think you can understand that such an issue is really serious for an HTPC, because it makes it really untrustable for scheduled recording work: often recordings fail because of the HTPC freezing when it tries to resume... my wife is really sad about it...
Trying to solve the issue, i made the following:
running memtest and video card memory test - no error found
change nearly every MST options - no effect
reading carefully W7's event viewer logs after and between freezes - nothing found that could clarify the issue
changing all ACPI and power related BIOS options (C3 support, EUR 2013, CPU phases, DDR phases, shadowing, etc...) - no effect
updating BIOS and all drivers - no effect
disabling cool'n'quiet - no effect
unplugging Segate 3Tb HDD - no effect
unplugging all external and internal USB devices (except mouse) - no effect
uninstalling ATI video card and running with legacy drivers - no effect
disabling embedded Ethernet adapter - no effect
unplugging the second display (an HDTV) - no effect
tried to get a manual crash dump - not possible as when the issue happens the HTPC is freezed
Those tries took very long to be made, because every time i have to wait all day long for the issue to happen: it NEVER takes place if i wake up the HTPC after a few seconds sleep, seems like it needs at least a few hours of S3 state to take place.
Now, many particulars of the issue seem to lead to a compatibility problem between PSU and motherboard: i read about other users experiencing similar problems using high-end PSUs (min load related?), problems they solved by finding older or cheaper PSUs compatible with their MB (that's a blind try thing, luck was needed)... but in all cases PSU functioning was not bad, so no RMA was possible. Anyway, it is obvious that changing MB solved the issue as well... so Corsair support states it is not a PSU issue but a MB related one.
This seems to be a frequent problem for intel z68 based MBs, but i suspect my 990fxa MB can show the same compatibility issue with Corsair AX PSU, assuming some power related modification has happened in the last month in PSU or MB circuitry.
So i would like to know if someone else is/is not experiencing the same issue using same MB and PSU; more, i would like to know what 80+ PSU is SURELY working flawlessly with my MB, in case i should have to solve the issue by replacing the Corsair PSU (that is manufactured by Seasonic); finally, i would like to ask MSI technicians to verify the issue and possibly working around it with a BIOS update (maybe raising resume initial load, if PSU min load is to blame).
Thanks in advance.Even with AMD power reduction, consumption while on is nearly ten times than in standby... it happens me to leave my PC in S3 for 3/4 days, so power consumption would be too much (i write from Italy and here AC current is much expensive!).
Anyway, i took a more accurate look around about PSU/MB incompatibility and i'm now sure enough that this is the problem. It seems certain MBs in power saving modes (like S3) require a too low power from PSU, so that PSU min load is not achieved, that makes it malfunction. This happens to new, energy efficient PSUs, that eliminate minimum load resistors to achieve maximum efficiency...
Look at this: http://www.silentpcreview.com/forums/viewtopic.php?t=58802.
So this issues happen because MB is too efficient (it requires too low power from PSU) and PSU is too efficient itself (it eliminates power used to remain above min load in power saving). Is this true? It seems ridicolous to me!!!!!!! To save a couple of watts we are forced to leave PC on so wasting dozens of watts? Are PC engineers really dummies?
BUT it looks like this can easily be solved by a BIOS adjustment, isn't it?
Maybe you are looking for
-
Help- After upgrading to Mountain Lion 10.8.4 all of my default user pictures are missing
Hello, After ugrading to Mountain LIon 10.8.4 on my 2010 1.4 GHz Macbook air and now all of my default user pictures are missing. I found a similar situation on the net in which the guy says to do this: "logged in as root and trashed the old user ico
-
After a system recovery, my ipod nano is not recongnized by my computer or ITunes...
the ipod is fine and is recognized on another computer and is charged.... just doesn't show up as a portable device in my computer or ITunes after a system recovery i did. help
-
No gateway reply after installing Nokia PC Suite a...
Having used the usb connection for the first time I now have a no gateway reply problem. Seem to be a lot of issues around this - any experience in this particular situation? Thanks
-
How do I make my HP CM2320fxi compatible after upgrading to maverick?
I am unable to access my scanner, and when printing, the result is sketchy. The printer jams and/or misprints the document, but the technician reports this does not happen in his workshop... only when I use my imac, so clearly there is incompatibilit
-
Can I use thumbnails rather than the {sitename} to load different galleries?
Hi all- I'm new to Spry and all things Javascripting but I'm attempting to construct a image gallery using Spry in Dreamweaver CS3. I've used the "Original Photo Gallery" from the Spry Demo folder as a jumping off point and everything works correctly