Jump to content

EricLarsen

Members
  • Content Count

    85
  • Joined

  • Last visited

  • Days Won

    2

EricLarsen last won the day on June 6 2013

EricLarsen had the most liked content!

Community Reputation

8

About EricLarsen

  • Rank
    Very Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since
    1992

Recent Profile Visitors

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

  1. 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.
  2. 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 understanding the specification, or something else is wrong. Anybody have any ideas?
  3. 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 = 1.2.0.14 NI SmartBalloon = 2.0.0.2 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?
  4. 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.
  5. 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 simple, just wait for a trigger, store some analog data, then download it to the crio for processing. Ultimately the correct solution is probably to buy a couple NI-9775 modules, but for bureaucratic reasons this isn't possible now.
  6. 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.
  7. 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 thermistor IC on one of the channels for cold junction compensation. This works OK, but it's not a great solution. The TC is really susceptible to noise and other environmental conditions that affect the reading. Has anybody ever done anything like this and has some tips that might help? Ideally, I'd like to find a signal conditioner that can be placed near the process to convert to voltage to re-transmit to the DAQ. This company has something that works with type K with 1ms response rate: http://thesensorconnection.com/signal-conditioners/signal-conditioners/type-k-thermocouple-amplifier-signal-conditioner-0-5-vdc-out But I need type R. Anybody seen anything like that? Thanks!
  8. 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.
  9. 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 Right Click in the Pen and Touch control panel, but no luck. I've done this for both the Pen Options and Touch control panel. Anybody else seen this? Is this a bug, or is there another way to disable this feature?
  10. 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.
  11. 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
  12. 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?
  13. 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!
  14. 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.
  15. I've got a 3rd party DLL I call from within my application. One of the functions returns a pointer to a variable length null terminated string. I use the mysterious GetValueByPointer.xnode to dereference the string and return it's value. This works great from within the Labview development environment. I'm using 2013Sp1. But when I compile the application into an executable, the xnode returns an error 7. It appears the DLL is returning a valid pointer, but the xnode can't dereference it. My hunch is that the pointer is crossing some kind of protected boundary, but I don't know for sure. I suppose I could write a wrapper around the DLL call, but I really don't want to have to do that if there is a simple workaround. Any ideas?
×
×
  • Create New...

Important Information

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