I need help changing a VI from NI PXI-1042Q to USB-6210

[emrysm]

Hello all.  This is my first post, and I apologize ahead of time if it's in the wrong place or is inappropriate... I was instructed to come here for help.

I am working on changing a VI that is functioning perfectly with an NI PXI-1042Q over to a much smaller unit, the USB-6210.  Supposedly the USB-6210 can handle the same inputs/outputs that I need (one analog input read at 30 kHz, 2 digital outputs written at 10 kHz), however I am having a bit of trouble getting it to work properly.  The outputs seem to go where they are supposed to, but the new system is orders of magnitude slower than the original, and for the system I am using this is unacceptable.

I'm sure I'm doing something wrong, but I'm about as new to LabView as you can get so I have no idea where to start.  Any help would be appreciated.

Additional info you might need:

LabVIEW 2010

The VI is attached.

Respectfully,

Emrys Maier

University of Texas at Arlington Research Institute

Research Assistant

[JÞB]

Orders of magnitude slower...

Well YES, when you create and destroy your DAQmx Tasks in every itteration of a for loop you are going to bury yourself in the overhead creating, verifying, reserving, and commiting a task takes (as well as uncommiting, unreserving, and destorying the Task) SEE Here

Sean N really took us down deep into the DAQmx State Transition diagram.

Enter the loop with a commited task.  close it after the loop.

"DAQmx Tasks need to be created once- preferably during development and saved to the project for deployment"- JJB

[emrysm]

If I understand you correctly, you're saying that the original program was very inefficient... but it worked perfectly, so can you tell me what is different about the 6210 that causes it to suddenly work 100~1000 times slower using the same code?

I will attempt to implement your suggested fix, I'm just trying to figure out what the difference between these two systems is.

Thanks for your reply,

-Emrys

[JÞB]

one is using the PCI bus the other is using USB

(And probably has some power management problems and a 1.0 device on the hub)

A Quick link to USB FAQs-  pay attention to FAQ2 1-3

USB Plug-n-Play Devices (Windows)

Options

• Mark as New
• Bookmark
• Subscribe
• Highlight
• Print
• Email to a Friend
• Report to a Moderator

‎01-22-201202:20 PM

In this topic we will discuss some of the common problems that have been observed using USB devices with LabVIEW on Windows operating systems.  Many of these points are also applicable to other environments but the examples will be use the Windows 7 OS.

FAQ 1 : My USB device stops working unexpectedly.

The first thing to look at is the OS power saving options.  There is a global trend towards developing "Green" electronics and energy star ratings are getting fairly common.  "If its not being used shut it off" is nothing new.  Cavemen learned how to bank a fire to preserve energy that would otherwise be wasted.  Likewise, the Windows OS has a power saving feature to shut down power to the USB hubs when no user activity is present.  In Automated systems this feature can cause problems since removing USB hub power will shut down the USB device.   Solution: Use the device manager to change the USB hub Power Options.

FAQ2: I set the power options and my device connection is still unreliable: Remember, those computer USB ports are often the cheapest that can be mounted on the chassis and share the PC system power supply to supply USB Power. Most uses of USB are temporary connections like a thumb drive or a camera.  These connections do not require high reliability since the user is right there interacting with it.  Power surges and fault tolerance at worst cause the operator to retry the data transfer.  Automated systems require a bit more robustness.  Solutions:

1) ALWAYS use an external self powered hub.  Perform your engineering due diligence and inspect the devices specifications too- If you can't find them for that device that should clue you to seek an product from a vendor that WILL publish their specs.

2) High noise environments require the use of ferrites on the USB cable- and don't buy the cheapest cable either! The cheap ones are poorly shielded. 

3) PROTECT the HUB connections-  If you have a USB2.0 device and Joe User plugs in a 1.0 device in a open slot managed by the same hub- Bingo every port on the hub may back convert to USB1.0.  WORSE there are a lot of damaged or marginally engineered USB devices out there.  Joe User's device may cause power fluctuations when it is inserted or removed from the hub just don't let it happen!

FAQ3: I am testing USB devices and the OS can't find them anymore.

This is a Plug-n-Play feature that deserves some exposure.  When you connect a P-n-P device the OS remembers its serial number in a HKEY (Hive-Key) registry entry.  This is helpful when (for example) you want a specific instrument, Say an NI-USB-6008, to show up as a DAQmx Device with VISA Alias "MyDAQ1" every time it is plugged it.  On the other hand, If you want to test a line of USB-Serial converters this can be problematic since the P-n-P driver will mount the first serial number as "COM3" and the next as "COM4" add infinitum until the enumerator controller in the registry and VISA recognized aliases get used up.  Solution: Use the Windows registry API and the Hardware Configuration API in LabVIEW to clear unused VISA Aliases and HKEY entries.   Speak with your staff IT professional about HKEY structure and possible side effects before developing a plan to edit registry entries.

[JÞB]

In this topic we will discuss some of the common problems that have been observed using USB devices with LabVIEW on Windows operating systems.  Many of these points are also applicable to other environments but the examples will be use the Windows 7 OS.

FAQ 1 : My USB device stops working unexpectedly.

The first thing to look at is the OS power saving options.  There is a global trend towards developing "Green" electronics and energy star ratings are getting fairly common.  "If its not being used shut it off" is nothing new.  Cavemen learned how to bank a fire to preserve energy that would otherwise be wasted.  Likewise, the Windows OS has a power saving feature to shut down power to the USB hubs when no user activity is present.  In Automated systems this feature can cause problems since removing USB hub power will shut down the USB device.   Solution: Use the device manager to change the USB hub Power Options.

FAQ2: I set the power options and my device connection is still unreliable: Remember, those computer USB ports are often the cheapest that can be mounted on the chassis and share the PC system power supply to supply USB Power. Most uses of USB are temporary connections like a thumb drive or a camera.  These connections do not require high reliability since the user is right there interacting with it.  Power surges and fault tolerance at worst cause the operator to retry the data transfer.  Automated systems require a bit more robustness.  Solutions:

1) ALWAYS use an external self powered hub.  Perform your engineering due diligence and inspect the devices specifications too- If you can't find them for that device that should clue you to seek an product from a vendor that WILL publish their specs.

2) High noise environments require the use of ferrites on the USB cable- and don't buy the cheapest cable either! The cheap ones are poorly shielded. 

3) PROTECT the HUB connections-  If you have a USB2.0 device and Joe User plugs in a 1.0 device in a open slot managed by the same hub- Bingo every port on the hub may back convert to USB1.0.  WORSE there are a lot of damaged or marginally engineered USB devices out there.  Joe User's device may cause power fluctuations when it is inserted or removed from the hub just don't let it happen!

FAQ3: I am testing USB devices and the OS can't find them anymore.

This is a Plug-n-Play feature that deserves some exposure.  When you connect a P-n-P device the OS remembers its serial number in a HKEY (Hive-Key) registry entry.  This is helpful when (for example) you want a specific instrument, Say an NI-USB-6008, to show up as a DAQmx Device with VISA Alias "MyDAQ1" every time it is plugged it.  On the other hand, If you want to test a line of USB-Serial converters this can be problematic since the P-n-P driver will mount the first serial number as "COM3" and the next as "COM4" add infinitum until the enumerator controller in the registry and VISA recognized aliases get used up.  Solution: Use the Windows registry API and the Hardware Configuration API in LabVIEW to clear unused VISA Aliases and HKEY entries.   Speak with your staff IT professional about HKEY structure and possible side effects before developing a plan to edit registry entries.

[emrysm]

Thanks for the info on USB.

I have simplified the VI to only contain one output waveform to avoid the original problem you mentioned (attached), then I verified my USB settings and transfer rates, which are all very good.  The USB-6210 is quite capable of sending/receiving data at the speeds that I require (10 kHz is practically nothing on even the slowest USB connection).

I am still having the same trouble, unfortunately.  This code _should_ cause my stepper motor to rotate a few degrees very quickly (as it does with the NI PXI-1042Q), but it does it incredibly slowly on the USB-6210.  I am still looking for help with understanding why this device is acting differently when everything I know says it should work perfectly fine.

** FYI, the steps and rate are wrong on this version of the file, but I have been tinkering with them and it doesn't seem to matter what I set them to.  The correct values are steps = 100 and rate = 10000

-Emrys 

[emrysm]

Upon further testing, I have found that the device outputs precisely the number of samples I request, but it does it at a set rate (~2.5 kHz).  My 'rate' setting does absolutely nothing for this device.

Does anyone know if there's a way to change the rate that the USB-6210 outputs data out of digital output ports?

-Emrys

[emrysm · Accepted solution]

The device is incapable of outputting the required frequency from the digital outputs, however the counter outputs do it perfectly.

-Emrys