Jump to content

Gary Armstrong

Members
  • Posts

    7
  • Joined

  • Last visited

Profile Information

  • Location
    Knoxville, TN

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 8.6
  • Since
    2001

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Gary Armstrong's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. I am implementing a LabVIEW controller for an industrial application (HVAC). My client wants graphics of pumps, tanks, and solenoid valves. I have done fairly well with decorations but now he wants them to change color based on status (on/off). Does anyone supply a graphics library to handle this?
  2. The uC works at 921600 baud with the LabVIEW interface that I have inherited. I don' have a serial line analyzer so I am restricted to trial and error with the uC. So, I try it and see if I get a response. I will try to use to laptops tomorrow and see if I can get them to talk to each other. I do have the uC set to 921600 baud. If I set the uC to 230kbaud my LabVIEW App can talk to it, but no faster. But the LabVIEW app I have inherited can talk at 921600 baud. That's what has me bewildered.
  3. 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
  4. Porting the Two Edge Measurement Counter from TDAQ to DAQmx is proving to be impossible. Apparently NI does not support loading a PRESET with the Two Edge Measurement Counter method under DAQmx. We have also tried the Event Counter method which does allow a PRESET but does provide a technique to route the CTR OUT to stop multiple counters. ----------------------------------------------- Executive Summary This application utilizes multiple counters spread across multiple boards. The counters count neutrons except one counter that is dedicated to time. The counters need to start and stop at the same time. This is accomplished by connecting the start and stop lines to RTSI0 (start) and RTSI1 (stop). The start function (under TDAQ) is accomplished by toggling RTSI0 (see figure 1). The stop is accomplished by connecting the CTRn OUT from the (master counter) to the stop line. One of the counters is designated as the master counter (typically the clock). The master counter is loaded with a PRESET and configured to count down. When the master counter output line goes high, all counters on RTSI1 stop. The TDAQ software permits two functions that I understand are going to go away when porting to DAQmx: (1) The ability to toggle a RTSI line (for use as a global start/stop signal to all slave channels. (2) Remote Device Access (RDA). The in-ability to toggle a RTSI line in DAQmx means that a PCI-6602 channel (pulse generator) will have to be allocated to this task (a solution that HFIR scientist currently oppose, but is satisfactory for a temporary fix on GP SANs). Test Two Edge Measurement.vi Test Count Edges.vi
  5. I added the IP addresses and names to the Windows hosts file which fixed the problem (for several days), until I updated the Licenses file and now it is broke again???
  6. FIre wall is off. No virus sw running. We are on an isolated network with no router, only a switch, so there is no DNS other than the Resolver Cache provided by Windows XP. I have run "ipconfig /displaydns" from the cmd window and see the loopback address. I have also run "ipconfig/ flushdns".
  7. I am using the VI Server to access controls on a vi running on a remote computer. This interaction is intiated with a call to the Open Appl Ref VI, it returns an error 66. Independent of what we do to the VI Server Configuration and Access List (Tools->Options), the result is that same. I can ping the remote computer. I can open the port (3363) with a telnet command from the command window ( telnet 192.168.10.15 3363). All this started when I ported the main LabVIEW application (LV82) to a new computer with LV86. The main LV82 application on the older computer can talk to the remote computer (running LV82) just fine. We have read some of the info in the NI Forums on server.tcp.acl in the LabVIEW ini file and have changed and played with it every way possible but can not resolve the problem. (http://forums.ni.com/t5/LabVIEW/Trouble-with-Error-66-in-LV-8-2-1/td-p/580394) We can run the LabVIEW VI Server example on the remote computer to talk to the main computer but can't get things to work the other way???
×
×
  • Create New...

Important Information

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