Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


EricLarsen last won the day on June 6 2013

EricLarsen had the most liked content!

Community Reputation


About EricLarsen

  • Rank
    Very Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since

Recent Profile Visitors

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

  1. I had almost the exact issue a few years back. I had a Windows computer that would send out a UDP packet every 100 ms to a Labview real-time PXI system. If the PXI system didn't receive a UDP packet for 5 seconds it assumed the Windows machine has failed and would go into a fail safe mode. The issue was that the Windows system was also doing some data processing, and every so often the data processing would cause the Windows box to freeze long enough interrupt the communication. The real issue is that neither Windows or Ethernet is really capable of maintaining a 100% reliable real-t
  2. The ghosting goes away when the interchannel delay is 20 us. I'm in FPGA mode, so I'm only scanning the channels specified in scan list, and the grounding appears to be correct. That's why I'm wondering if I really understand the specification or if something else is wrong. I can live with a 2.4 mV error to get 250 kS/s, but 60 mV is too high and appears to be far out side of spec.
  3. I'm hoping somebody can explain what the multichannel settling time specification means. I'm using an NI 9205 in FPGA Mode, with a range of +- 10V. According to the spec. sheet, for a 4 microsecond interchannel delay, the settling time accuracy is "+- 120 ppm of full-scale step, +- 8 LSB". If I have a 5 volt signal before a 0 volt signal in the scan list, what level of ghosting would I except to see on the 0 volt channel? According to my probably wrong calculation, for a +-10 volt range, 120 ppm should be about 2.4 mV. But I'm seeing about 60 mV ghosting instead. Either I'm not
  4. I'm finally getting around to installing this after seeing your NI Week presentation (which was really good BTW). The dependencies for GPower Error and NI SmartBalloon are GPower Error & Warning = NI SmartBalloon = There are more current versions of both libraries out and VIPM wants me to downgrade. Is there are reason these dependencies are fixed or could this be modified to allow the current versions?
  5. Just an FYI for the future, in the Labview examples there is a VI called Extract Numbers with Match Pattern.vi. Very similar to MikaelH's code and really useful.
  6. I've got a bit of an unusual situation here. A customer has an existing cRIO-9036 running real time Linux. They also have a USB-6366 acquiring some high speed signals for another system. They would like to interface the high speed signals to the crio system. They've asked if it's possible to connect the USB-6366 to the cRio. The crio system recognizes the USB-6366 as a USB RAW device. So the question is it possible to control the USB-6366 using RAW communication? I've got no experience in this area and haven't been able to find any documentation on this. The application is pretty
  7. Something like that ..... Can you recommend a device that can do that? None of the thermocouple signal conditioners I can find can come to anywhere near that speed. They typically operate around 150-400ms.
  8. We got a process which has very rapid heat up rates (~10,000 C/sec). We are experimenting with small type R TC wires to measure this process. Ideally we are looking for 1000 Hz readings on the TCs. This is well outside the rate of standard TC DAQ hardware. To add to the fun, we'll probably have very long TC wire runs (100-200 feet). We are limited to TCs instead of non-contact measurement due to physical constraints. Right now I'm using a cRio system with an NI-9205 for measurement. I've got the TC wired in differential mode with 50 kOhm bias resistors. I've also got a small thermi
  9. Could your instrument be echoing back the string? This is a common way for instruments to acknowledge receipt of the communication. Another possibility is you've got your TX and RX wired for loopback and you're reading back your own string.
  10. I'm developing a UI to run on a touch panel computer (NI TPC-2230 with Windows Embedded 7). I've got a bunch of Boolean controls set to Switch Until Released. The intent is for an action to happen when the user presses the button, and the action stops when the button is released. This works great in the development environment when using a mouse. But in the touch panel, pressing and holding for a certain amount of time activates a right click. This is called 'press and hold for right click' feature. I've tried to deactivate this feature by unchecking the Enable Press and Hold for Rig
  11. Just an FYI, there is a better version of this vi from MGI called Change Detector.vi. It operates the same way, but has a drop down polymorphic selector that specifies whether the first call should return a TRUE for FALSE. Brilliant solution to the indeterminate first call issue of the OpenG vi.
  12. What you're looking for is called an ADSR (attack,decay, sustain, release) envelope calculation. Pretty standard stuff in the audio world. Lot's of discussions out there about how to do this. The Sound and Vibration tool kit from NI might even contain this. Or, check out: http://cnx.org/contents/18005ea2-b457-42c1-89c9-79ed1d57b73f@3/Musical-Signal-Processing-with
  13. I've got a stepper motor application that due to cabling limitations is perfect for encoderless stall detection, such as on the NI-P70360. Has anybody used this feature and has some insight they could share?
  14. Darin, you're a genius. I was barking up the wrong tree. Error 7 is a file not found error, which often seems like one of those generic error codes that's thrown out when nothing else will do. But no, in this case the error means exactly what it says, it couldn't find the library specified on the diagram. Problem fixed!
  15. MoveBlock would work if you knew the string length in advance. I don't think you could use it for a variable length string. The xnode is supposed to have some internal magic that handles strings, and it does work. Just not in a compiled executable. Sounds promising, but it doesn't appear to work. Labview interprets this as a 3 or 4 byte gibberish string. I'm trying to wrap my head around why this is.
  • Create New...

Important Information

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