Jump to content

Search the Community

Showing results for tags 'usb'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • OpenG
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 10 results

  1. LV2016 64-bit I have inherited a LabVIEW Interface that talks thru a USB2 Interface to a micro-Controller at 921,600 baud. This opens a new world of possibilities as USB2 can handle data at much higher rates than a typical RS232 interface. I have been tasked with rewriting the LabVIEW code as it is difficult to maintain. I have an application that will talk to the uC at 230 kbaud but can't attain the 921,600 baud. I have tried copying the pertinent VIs from the supplied code into my app but still can not attain 921,600 baud. Plus I don't have a serial line analyzer capable of handling USB2, so I can only trial and error with the uC. Is there a setting I have to do in LabVIEW to allow serial communications at the higher rates? At the moment, I am trying to get the Find Controllr VI to work. I have included the support VIs for the Find Controllr.vi. The Find Controllr VI attempts to find the correct port and baud rate and then obviously communicate with the uC. Find Controllr.vi Packet TR.vi Get Available Ports.vi Serial Data.vi Check For Packet.vi Open Port.vi Create Packet.vi Extract Packet ID.vi PTI CRC.vi
  2. Hello everyone, I have a small problem with SPI communication. I'm using NI USB 8452 module and LabView 2013 with driver NI USB 845x 14.0. As a first step I ran the example from attached library called "Atmel AT25080A Write.vi". The problem manifests as logic "0" all the time on MOSI and MISO lines. No Data transferred. CS and CLK works properly. I never use pull ups when using SPI but maybe I should? The question is did anybody meet the same problem while using this usb 8452 module? All 4 SPI lines connected directly to oscilloscope. Waiting for any reply. Thanks in advance.
  3. Hi, I have several USB instruments (Agilent/Keysight optical power meters) which I can talk to via USB. To minimise the time "wasted" by transferring data between the instruments and the PC I would like to query them in parallel. Unfortunately, LabVIEW doesn't agree with that strategy and reliably crashes when doing so. It doesn't matter which command I send, so here's a sample snippet, where I just query the instrument ID repeatedly. I don't even have to read the answer back (doing so won't make a difference): This will kill LabVIEW 2012 and 2014, both 64bit without even popping up the "We apologize for the inconvenience" crash reporter dialog. Has anyone had similar experiences? I've seen LabVIEW crash while communicating over RS232 (VISA) but it's much harder to reproduce. Is it outrageous to assume that communication to separate instruments via different VISA references should work in parallel? All my instrument drivers are separate objects. I can ensure that communication to a single type of instrument is done in series by making the vi that does the communication non-reentrant. But I have to communicate with multiple instruments of different types, most of which use some flavour of VISA (RS232, USB, GPIB). Am I just lucky that I haven't had more crashes when I'm talking to a lot of instruments? Could it be a bug specific to the USB part of VISA? I've only recently changed from GPIB to USB on those power meters to get faster data transfer rates. In the past everything went via GPIB, which isn't a parallel communication protocol anyway afaik. Tom
  4. Hi guys, Long time reader, first time writer. I'm currently trying to develop a data gathering system using a NI sbRIO-9606. The premise is quite straight-forward; I have a digital signal (data and clock) with a bitrate of 10 Mbit/s which I want to store to a USB flash drive in real time. The single-board RIO has no problem reading and processing the bitstream but storing the data to the USB flash drive is apparently not as easy as I thought. According to the manual the USB port supports a transfer speed up to 480 Mbit/s (USB 2.0 standard?) but I've been unable to achieve any faster transfer speed than around 1 Mbit/s (1.3 Mbit/s worst-case). This is unaccaptable for my application! I'v tried to disabeling buffering for the Open/create file function and only storing files in multiples of the sector size but it does not seem to help. Are there any preferrable USB flash drives one must use? Or am I unaware of any "high speed file streaming" options in LabVIEW? Sincerley, CC
  5. All, I am having some issues with errors when I am writting to an external USB drive. The errors appear to be random. I was able to get a log of the errors. I have attached the VI that I am having issues with. The code number for the error is 1. Endless File Write_rev1.vi 6/23/2014 18:55:9.864 : 8 : 1 : Get File Size in Endless File Write_rev1.vi:2590003->SPI User Interface test1_rev1.vi : Indicator of multiple errors : 2 6/23/2014 18:55:10.886 : 0 : 6 : Open/Create/Replace File in Endless File Write_rev1.vi:2590003->SPI User Interface test1_rev1.vi<APPEND> H:GDataGDaqData HS_00039.efd : Indicator of multiple errors : 2 6/23/2014 18:55:11.910 : 1 : 6 : Open/Create/Replace File in Endless File Write_rev1.vi:2590003->SPI User Interface test1_rev1.vi<APPEND> H:GDataGDaqData HS_00040.efd : Indicator of multiple errors : 2 6/23/2014 18:55:12.934 : 1 : 6 : Open/Create/Replace File in Endless File Write_rev1.vi:2590003->SPI User Interface test1_rev1.vi<APPEND> H:GDataGDaqData HS_00041.efd : Indicator of multiple errors : 2 The error appears to start with the "Get File Size" vi in the VI that I have attached. Once that happens it appears that I can't access the file or hard drive. Not sure if the real problem is with the "Get File Size" vi or if is just when the drive access is messed up. The VI will write to a file until it's size is greater than 62.5K. Once that happens the file is closed and the file name is indexed and the new file is open. The errors appear to have happened on a file index increment becuase the last file that was written was 62.5K. The only error handling that is part of this VI is that if there is an error opening the file the file name is indexed and used for the next time the data is written. I wanted to know is there was any other kind of error handling that I should put in this to handle file errors. Or maybe to reset the USB port possibly? Are there possibly any waits that I should put into this sequence of step? The drive I am using is from imation and the model number is H100 1TB. I am also using LabVIEW 2013 SP1. If you need any more information or have questions please let me know. Thanks for your help. Joe
  6. I am working on an RT app and hardware that uses more than 50 USB devices connected via USB hubs to an NI rackmount computer. After a hard reboot of the rack mount computer, the USB devices and hubs take more than 5 minutes to enumerate. I am looking for a way to verify all the USB devices have enumerated. Polling VISA Find Resources appears to cause the entire system to lockup if we start it immediately in RT app. If we manually delay for 10 minutes or so in the application and then call VISA Find Resources, it appears to work OK as long as all of the devices have successfully enumerated. A hard-coded 10 minute delay is not optimal because on soft reboots, the delay is unnecessary. Are there any other ways to get the state of system USB enumeration other than VISA Find Resource? During reboots, the NI boot loader takes a minute or so to "Enumerate USB devices" but it appears it only enumerates each USB hub before it completes and moves on. PS. I know there are latency issues using USB on an RT system. We chose to use the RT platform for stability (no windows updates, etc) vs determinism. This may or may not be a good reason, but its what we have now.
  7. WireFlow releases the first Security suite software that is natively supported on any LabVIEW platform with an available USB port, including VxWorks and Pharlap based Real-Time targets. The security suite addresses IP protection issues for the LabVIEW platforms; not only does it add copy protection, but also enables user identification and feature control. To learn more, please visit http://www.wireflow.se/news/SecuritySuite_news /The WireFlow Team
  8. I've been asked to code and test temperature logger based on the NI-9211. Done. It turns out that the room is 15' x 30' and the custom 20 gauge type J thermocouple wires ordered from Omega are 12' long. I need to reach the far corners of the chamber from an adjacent control room. The first thought was to order new thermocouples, but then I noticed that NI offers 'extension wire'. http://sine.ni.com/nips/cds/view/p/lang/en/nid/10492 Is it possible to extend the existing thermocouples using the correct type wire up to lengths of say 50' ? If so, any downfalls, tricks or calibration issues? I'm monitoring an ESS chamber that cycles from zero to 60C.
  9. For years I have successfully used the Icron USB Ranger 2204 Cat 5 Extender with both cDAQ and SCXI. But now I have one very annoying issue. I only recently purchased some NI 9237 units for my pressure transucers. Those, and only those, modules don't seem to like being polled over the USB-to-Cat5 extenders which I have in both of my test cells. I have timing issues. Not with all of them all of the time. But with all of them some of the time and with some of them all of the time. I get that pop-up message that says not all of my channels have been read. Increasing the timeout even to ridiculous lengths helps not at all. The rest of the porgram works just fine so long as I do not assign a bridge channel. So, what gives? I can't go bringing my PC closer to the test setup because of safety reasons. We're a combustion lab. I don't want to have to be stringing out long wires all of the time because we're a test lab and those get set up, taken down, changed all around every week. It's a big issue. Can anybody recommend a USB extender other than the Icon which they have used with good success on the 9237 units? All that I am trying to read are finite samples, just two of those, and the speed doesn't matter much. I've already tried different speeds to no avail.
  10. Here is a strange request but I am casting a wide net to see if anyone has seen a solution to this. I need a device that can route a USB dongle to a DUT's USB port. I need to be able to simulate the insertion and removal of the USB dongle without physical access to the dongle. I need this to be controlled via Ethernet. Ideally, this product would allow me to insert a single USB dongle and route it to multiple DUTs simultaneously. If that is not possible, I could insert multiple dongles and route them 1 to 1. So, why do we need this? Well, our product is designed to boot off a USB dongle and get us a basic OS that we can then use to load a full test OS from a network server. But, once we install the network OS, we want to reboot and not see the dongle anymore. Right now we need someone to physically pull the dongle from the DUT. We would like to automate this process. thanks for any ideas, thoughts or sympathy... -John
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.