PXI and Instrumentation Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Products with protocol decoding capabilities, like Virtual Bench for example, should feature a protocol word trigger capability.

For Example while debugging SPI on Virtual Bench with MSO it would be interesting to trigger if the 16 Bit Word mathches b001x0010x0000110 or h0A0A.  This is a fairly common capability in the market.  (http://literature.cdn.keysight.com/litweb/pdf/5990-3925EN.pdf)

It would be nice to have also on 657x with the possibility of exporting on on PXI_TRIGx to synch up other instruments or even better, but more complex I understand, on 51xx scopes.

 

Best Regards

Filippo

 

Using RT Utilities or RAD works well to image and deploy when you have like systems. What about when there are many deployments to maintain, each with the same RTEXE and same driver sets, but there are many different models of PXI RT embedded controllers throughout these deployments? What if it was possible to install software to a SIMULATED PXI in MAX as well as to deploy executables and support files to? This would allow for the creation of an image for a specific model controller, without having that controller directly in hand. (BTW, I'm still on LV2013 SP1 for the next few months. I have 42 RT embedded targets that include a mix of the following models: 8196, 8104, 8102, 8115, 8100, 8135, 8820, 8840, and 9139. The same RTEXE runs on all of these. The end-user can customize I/O at run-time and therefore these deployments range quite widely in performance needs and these deployments were created over several years, hence the wide range of embedded controller vintages and performance levels. And, for my scenario, these controllers are not directly accessible through the network, as they are connected to a local network specific to that deployment location. There is a Windows host machine that has access to this local network as well as to the building network.)

We have DUTs that require inductance to be measured at specific frequencies. Currently, NI DMMs don't have the capability to measure inductance at custom frequencies. It would be nice if there was a DMM or other type of NI module that worked like many LCR bridges that have the capability of measuring inductance/capacitance at different frequencies.

 

Why Max is not having option to simulate the cRIO, PXI and Instruments such as DMM, DC POWER, NI SWITCH.  Like DAQmx devices if it is simulated means it will be good.

 

We can able to test the code without the Hardware (PXI, cRIO, etc.).

 

Senthil Prakash S
Certified LabVIEW Associate Developer

It would be great to have Python support for the NI-HSDIO PXI cards. It seems to be the only instrument type to explicitly left out of Modular Instruments python project.

Allow the Ni-Sync operate timing cards in PTP slave only mode for Windows and RealTime controllers.

The option source.ptp.SlaveOnly provides this functionality on RealTime devices, so why not for all use cases.

This is useful for startup in subnets without reliable connection to a reliable master

and also when PTP_TIMESCALE is false.

 

Regards

Valik

Can you please re-enable the "Sweep" and "Pulse" buttons in the RFSG SFP when it sees a PXIe-5840 VST? 

Jim-RF guy

I have an upcoming requirement for connecting two test equipment racks so that one contains a control computer and PXI chassis and the second rack contains another PXI chassis. The control computer will include a two-port MXI Master PXIe card, and each PXI chassis an MXI Slave card.

The problem arises that there is no means to bring out an MXI cable from one rack to the other, except through a hole, rather than a proper feed-through connector.

I can design and build a back-to-back pair of MXI matching Molex connectors on a small PCB, but a qualified, tested, and approved OEM solution would be much better.

The PXIe-6570/6571 Digital Pattern instruments should have an option for a Halt On Failure mode.  This can save test time when a large pattern burst fails a vector early in the pattern.  This is a common feature in other semiconductor ATE.

Hello,

 

It would be great if NI could release a multiplexer (at least 1:8 ideally) based on MEMS switches, which allow for signals from real DC to ~ 10GHz (I'm thinking Analog Devices ADGM1304) and have ~ 1e9 endurance, about 100 times better than standard relays.

 

This would fill the gap in the product offering.

 

Best regards,

Michael

When set RFmx WLAN SEM sweeping time property to "Auto", the length of sweeping time is not long enough for 160/320M bandwidth to get a smooth SEM result for PA measurement. Making the sweeping time longer will get better SEM result. Customer wish RFmx WLAN tool could have the "Auto" sweep time value to be longer enough for better SEM results with PA in the loop.4_11be_MCS0_BW320MHz_Pout_lower_RTC.png

Hey Guys. I have a PXIe 5831, and am performing DPD with a thru (no DUT in the middle). I am outputting a WLAN waveform I found that at about 30% duty cycle and below, I start getting really bad EVM seemingly randomly. Looking at the spectrum produced noise all over, as well as the side band edges. The waveform just looks really bad.

 

With RFmx waveform creator, I have changed the dBFs backoff to 20dB, made the signal -20dBm power, and did a -15dB Runtime scaling in order to make sure that there's not something weird with the DAC being overloaded. I have also tried messing around with the power level of the Signal Generator, but it seems to occur at random power levels as well. The issue still occurs.

 

The DPD I tried are LUT and MP. The issue occurs with both, but seem to be more prominent with LUT.

 

Any and all ideas appreciated!

HI,

I want to exchange opinions to evaluate a possible solution for my project. 
The system consists of a PC (NI LabVIEW 2017, with a certain IP address) to
which the PXI is connected (with its own IP address). A Programmable Logic
device, perhaps an S7 PLC, will be connected to the PXI via an Ethernet port
(No acquisition module, like NI-Profibus) with which it is possible to
communicate with the TCP/IP protocol. Since the PLC is recognized as a
Network Device (and not as a Physical Device), I ask: - How can I interface Labview with the PLC if through NI MAX I can't create
Acquisition Tasks that I can import into the project? - Are there any solutions for Network Devices? - Or, can it be correct to instantiate the TCP/IP protocol from Labview, and
using the IP address and Port, try to communicate directly with the PLC (which
will still be connected to the PXI)? Thank you in advance.
Best Regards

Giuseppe_Vitolo_NI

 

 

MXI fiber cables are single-piece units, and can't currently be containerized between the PXI MXI cards.  Add some sort of adapter hardware that lets you adapt a MXI fiber connection to standard SC terminated fiber pairs, which can be used with off-the-shelf bulkhead solutions.

Problem: If you want to acquire data with a measuring loop you have to send a trigger in each of the loops. I became this problem because I wanted to measure over a long period.

 

Possible Solution: Decouple the Trigger from the Fetch Measurment. So the programm waits on the trigger at the configuration on the trigger.

It would be nice if the frequency list mode in the NI-FGEN driver can accept variable amplitudes, an amplitude for each frequency/Duration in the list.

Yes, it sounds silly, but hear me out. It might be a worthwhile idea.

 

There's lots of Minecraft mods based around building factories and setting up systems to automate them. If players could use hardware from NI's product lineup, and program it over a virtual network the same way one would program the real thing, it could be a great way to introduce hobbyists to it, and give them some amount of experience that could carry over to working with actual hardware. A player could craft a PXI chassis and controller, add a redstone interface module or something like that, as well as craft a router that connects the equipment to a virtual network adapter. Also add a touch panel for good measure. Then you could use LabVIEW to deploy code to the in-game hardware.

 

I've never tried using LabVIEW with Minecraft in any way so this might not work well, but it might. If so, now that Community Edition is available, it's never been a better time!


See also my thread on the LAVA forum: https://lavag.org/topic/21761-has-anyone-thought-about-using-labview-with-modded-minecraft/

Hi all,

 Proposition: make an SLSC chassis controlled over EtherCAT. Would be a great addition to a realtime HiL system with a lot of IO to be switched/faulted by providing deterministic switch capabilities. It's not always feasible to buy that many PXI switch cards...

E.g. our DUTs have usually about 100 IO lines (some even over 150), each of which have to be tested for open, short to another one, self-short (in case of differential lines) etc. We usually don't have a requirement to switch very fast, but we'll welcome a possibility to switch in predictable time.

I would like to request a pass-through connector for mounting on a panel of a test fixture or a screen room.  This connector would be similar to the connector on the CB-68LPR breakout board and would mount to a panel.  The other side of the connector would be either wirewrap/solder pins or another connector for connecting another cable.