Jump to content

elyness

Members
  • Posts

    9
  • Joined

  • Last visited

    Never

elyness's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. QUOTE (Eugen Graf @ Apr 24 2007, 12:20 PM) I know it's been a long time since your post. I just discovered this problem myself. The solution, in LabVIEW 8.6 anyway, it to close the Event reference after the event occurs. The wait on Even vi returns the event reference. Just use a normal Visa Close on this reference and you should be good to go. Eric
  2. I just ran into the same problem trying to get reference to FPGA vi's. The trick is to use the "Get All Descendents" method of the Target class and specify type as "VI". This returns an array of reference to all of the VI's in the target. Attached is your vi modified to use the Get All Descendents method.
  3. I have run into some additional problems too. If I create a task with say 3 input channels, then close and clear the task, then create a new task more than 3 input channels, LabVIEW hangs. It's not a labview crash because it is still running. It seems to be in an infinite loop somewhere deep in the DAQmx Base hierarchy. Also, there is a VI in the DAQmx Base hierarchy that has the exact same name as a VI used when you save a .jpg file. In order to have both DAQmx Base and the Write JPEG File.vi in the same program, you must rename a vi in DAQmx Base .
  4. What do you mean by "artefacts"? Could it be that your counter is overflowing? At 1kHz, a 40MHz counter reaches 40,000 if it starts at zero, approaching the 65,535 limit.
  5. I have found what seem to be very serious bugs with labVIEW FPGA. Has anyone else run into this? I have a system that uses 4 7811R RIO I/o Boards. Each board has some similar tasks and some different tasks. I wanted to have a single program that I downloaded to each in order to save compile time. So I had front panel boolean controls to enable or disable parts of the code. The host program would configure the state of the controls before running the FPGA vi. In emulator mode, everything was fine. But in device mode, my program produced no output whatsoever. It turned out that the boolean controls that enabled parts of the code were always false. When I hardwired a constant, everything worked except that now I had unique programs for each of the 4 RIO boards. Since it takes almost an hour to compile each one, this is a real pain. Later I discovered another even more startling bug. One subvi was used in three of the FPGA programs. A front panel integer control defined its operation. The value for this integer orginated in the host, was set on the top level FPGA vi and passed through wires to the subvi. Again this worked fine in emulator mode. In device mode I got nothing at all. Finally I found that the value of the control on the subvi was always 0 not matter what I set on the top level VI. When I replaced it with a constant, it worked perfectly. I looked at the code extremely careful and added debugging to make sure there wasn't something I was doing wrong. But I was doing everything right and since it worked in emulator mode, I'm left with a baffling bug in labview FPGA. Oddly, other values are passed to the same subvi and tthey arrive as expected. Anyone seen this?
  6. I'm glad to hear there are more OS X LabVIEW developers. Most of my projects are in Windows but I have one customer that uses OS X and I'm personally a big fan of it. We could really use the 3-D picture control but the biggest obstable for us that there's no image acquisition or processing supported. I could do without the acquisition part, if they could just give us the analysis vi's that would be huge. DAQmx Base, even in its infantcy has made a big difference for us. It's got a long way to go but it's a good start. We tried three different methods for reading thermocouples over serial connections and all of them were more flakey than daqmx base.
  7. I hate it when a customer says, "Can't you just..." but -- it seems like it wouldn't be a big leap to automagically compile the C code output from LabVIEW to an ARM processor that is already running Linux. It would really open up the embedded world to LabVIEW programmers like us.
  8. Am I the only LabVIEW for OS X user out there? I just got my USB 9161 and 9211 thermocouple device working with the newly released version of DAQmx Base for OS X. I am able to read temperatures from LabVIEW but the DAQmx Physical Channel control does not automatically populate with the ID of my USB device. (Note that the phyiscal channel control does contain the PCI devices.) If I type in the name, Dev1/ai0 for instance, it works. But so far, I can't find any way to query for attached devices without just trying to read them and checking for an error. This isn't particularly good because my software is running on several machines that all have slightly different hardware configurations. If I don't get an error reading an analog input on dev1, I only know that the device contains an analog input but I still don't know the device type. Is it a thermocouple device or a generic analog input device? Anyone else run into this?
  9. NI wants to bring LabVIEW down to the embedded world but I don't think it goes as far as I would like. I would like to write labview applications that runs on a PDA using Linux and the Intel PXA-255 processor. As far as I can tell, the PDA has to have an x86 based CPU. Does anyone know if they have or plan to have support for the intel PXA-255 processor? It uses the ARM instruction set.
×
×
  • Create New...

Important Information

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