Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since

stijn_'s Achievements


Newbie (1/14)



  1. update: we decided to go with InTime as OS, and use a variety of NI hardware depending on specific conditions. Some setups will use a simple PCIe card, for others we'll go with MXI - PXI and a couple of cards. The cards will be addressed by use of the new X-series DDK which seems to work very well (our prototype has a PXI rack with two cards synced).
  2. interesting, I didn't know that. One of the systems we're going to evaluate is IntervalZero's NTX btw. can you elaborate?
  3. we could indeed move some part of the procssing into the non-realtime side, but the heaviest part must remain in real-time, and we want to move some of the non-realtime into the real-time side. That last one is the main poblem: we really want it to be real-time in our future system, since it's causing problems now, but it's pretty compicated and in C++ so porting it would cause seruous headaches ;P Should we move it into a dll, we would probably use debugging functionality. Apart from that, we are so used to Visual Studio that switching to another IDE would be another dealbreaker..
  4. update: after spending some time with an NI rep, we're really convinced that the PXI hardware in combination with a RealTime OS would be extremely well-suited for use. The hardware is really nice. Major problem: the software is not. Seems RT is only possible using NI's proprietary software. Our current codebase is the result of about 5 years of work by two people, in rather advanced C++. Converting everything into C or Labview to make it run on PXI is just impossible given the time we have (and are willing) to spend on the rather boring conversion job. I was hoping it would be possible to run Windows CE on a PXI controller but apparently that's not an option. We're looking into alternatives now, seems there are some: - InTime. If this really does everything as advertised, we won't look any further. I mean, it sounds too good to be true: put a PCI A/D convertor in your pc, program as you always do using VisualStudio, and the thing runs it in real-time.. - An SBC/embedded PC running Windows CE. A lot (if not too much) of choice in this department, and it seems to be widely covered by the industry as well.
  5. @Neville: thanks for your in-depth answer yes, that's it exactly. we have tons of proprietary hardware, but all communication with these modules is purely analog or via TTL. So we'de use the analog/digital I/O on the PXI system to communicate with our current system. that's a pretty interesting idea but it's not scalable enough for us. For example right now we have to purchase eye trackers, with PXI we could just plug in a video acquisition board and write our own eye tracker software. Things like that seem very hard without a true bus system. we're well aware of that; but translating our C++ signal processing libraries to Labview is simply put impossible: it would be a massive job, and they're used not only for our RT device but also for offline processing etc. One option would be to put the processing in dlls and call those from Labview RT but I'm not sure that works (it does in 'normal' Labview). Anyway, we'll certainly do some more research. A decision will be taken approx. next month so it will take a while before I can give you guys an update but I definitely will.
  6. Hi, we are currently looking into replacing our current hardware (made in-house). In a few days we'll visit an NI Test&Measurement roadshow; I'm pretty sure the NI folks will all go like 'yeah PXI is ideal for your application' but I'd like to get some more objective information first. These are the requirements for a basic system: real-time. I'll try to explain: must be able to acquire 16channels of analog data at 20kHZ/16bit, together with (ie synchronized to the uSec) 32 digital TTL inputs sampled at the same rate, every 2mSec with a maximum jitter of a couple of uSec. In other words, all channels of the external analog/digital signal must make it into the software exactly 1mSec later, represented as arrays of 20 samples per channel. a low-latency link to an external pc running windows/linux/mac os. Ideally if the external pc would be polling that link, it should be able to react to any data on it within a mSec. I'm not sure that is even possible on a non-realtime os, but right now we poll the parallel port on XP an it seems to be doing that fine without too much jitter (seems never higher than 5mSec or so) we must be able to write at least the signal processing in C++, with a compiler providing support for at least TR1. Ideally the entire application would be written in Visual Studio. line-by-line debugging of the code. Again, ideally, this would be debugging with Visual Studio At a first glance much of this seems possible with PXI running NI's realtime os, and programmed using LabWindows. But the site is a bit vague about what can and what cannot be done using LabWindows, plus I'm not sure how the debugging works. Please share your thoughts about this. Recommendations for other systems than PXI are also welcome.. Thanks!
  • Create New...

Important Information

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