FT232R from FTDI hangs/freeze LabVIEW randomly

[automasjon3ea]

Hi.

I've been creating a program to display and log humidity and temperature sensors using the FT232R chip from FTDI (http://www.ftdichip.com/)

To build the DAQ.vi I've used the example 1 from FTDI which can be downloaded here: http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/LabVIEW.htm

The DAQ.vi I'm having trouble with is attached here.

What is happening is that from time to time (could take 10 minutes or could take 10 hours) the program suddenly hangs/freeze, and to solve it I have to diconnect and connect the USB-cable to the FT232R. When I have done so, the program starts working again, but I've lost all the data from the freeze-time.

Have anyone else experienced this problem using FTDI chips, or have any idea what could be wrong? And is there an easy way to find out if the bug is hardware or software-related?

I appreaciate the help!

NB:I know the attached .vi doesn't have wait times between write and read, but I've been having the same problem when using wait times as well.

[pallen · Accepted solution]

Hi there,

You have not included any of the SubVIs in your program.  This makes it difficult to guess what the problem might be. 

As this is a serial device, I'd suggest looking in the example finder at the Serial Read/Write example.  You absolutely will require a delay of some kind between sending a command to your device and receiving a response. 

One method of determining that your data is "ready" is to use the Bytes at Port property node.  http://zone.ni.com/reference/en-XX/help/371361H-01/lvinstio/visa_bytes_at_serial_port/

Serial communication starter and troubleshooting help here:  http://www.ni.com/white-paper/4049/en

[automasjon3ea]

Thanks a lot, I will definetly try some of the tips in the link!

How can I observe the property node to figure out if there isn't enough bytes in the buffer when the program freezes? 

How can I use timeouts to make sure the DAQ-sequence continues even though there isn't enough bytes waiting in the buffer? Do you have an example?

[pallen]

I can't seem to find a good ready-made example of using bytes at port.  But there's this discussion here that links to an image

It's not a very good image, but it shows the property node connected to the VISA resource name out.

If you want your program to "do something else" while it's waiting for the bytes to appear at the port, then you need to change your program architecture.  A timeout on the VISA read function only sets how long the function will wait for the bytes before completing with an error. 

Take a look at State Machines. 

[autmasjon3ea]

Hi again.

I have now implemented bytes at port and timeout in the program, but it still freezs randomly and starts again if the USB is unplugged and plugged in again.If there isn`t enough bytes (3 bytes) waiting in the buffer, the program now continues and discards that piece of data.

I have used counters to locate where in the DAQ-sequence structure it fails, but it`s not the same sequence each time. Sometimes it`s while running the Configurations settings for the serial communication and sometimes it`s during read and write.

Is it possible that the problem may be hardware-related? For example due to noise peaks on the VCC to the FT232R? Another idea is that the drivers may be the issue, but I have the newest drivers from FTDI.

[JÞB]

This sounds like Windows power management shutting off power to the USB HUB but you have any of the common problems in this FAQ article:

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

[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

[automasjon3ea]

Thanks for the help! The problem is finally resolved (it seems)

The problem seems to be lack of wait time between send and receive and after the serial communication presets have been selected. The program have been working fine after we increased wait time to 20ms after the configuration parameters, and increasing wait time between send and recieve to 30ms. When having 20ms we saw that it often happen to be less bytes in the buffer than it was supposed to, but having 30ms, it now never happens.