Jump to content

Jan Florjanczyk

Members
  • Posts

    11
  • Joined

  • Last visited

    Never

Jan Florjanczyk's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hi Daklu, I'm afraid I don't know a solution to that problem. It sounds like in the end you'd still be constrained by what Ton pointed out. I guess I haven't been using LabVIEW for as long as most of the people here. As to the LabXML package, if you don't want to have to parse the string you can actually read attributes of xml tags and then use a case select to unflatten the string inside the xml tag. Is that a step in the right direction? Sorry, wish I could help more.
  2. Definitely my favourite t-shirt. (Courtesy of Threadless)
  3. A simple solution I've found for storing complicated data structures in xml is to have an array of clusters that each contain a name field (string) and a value field (string). Then, when writing data, flatten it to string and give it an ID in the name field. When you need that peice of data again, simply search the array for that name and unflatten the value. It's not the fastest thing in the world but if your configuration files change and you want to remain backwards compatible you will still be able to read the old values.
  4. There is a nice library that works with the MSXML toolkit. It's called LabXML and is located at: http://labxml.sourceforge.net/. I've tried fooling around with it a bit and it does have all the functions necessary to navigate an xml document, even test it against a DTD or XML Schema. I guess there's no way to get around the problem that Ton mentioned but if you were looking to extract a certain peice of information from an XML document of unknown structure you could search for it using this library (I think).
  5. QUOTE(BitsLover @ Aug 17 2007, 08:49 AM) Hi Dirk, Listboxes act in a similar way to enumerations, their value is a number which specifies which entry is selected (blue/dashed-square). If you write a number value to a listbox indicator, the cell corresponding to that number will be selected. If you read the number value from a listbox control, the index of the selected cell will be returned. In order to programmatically edit the entries of a listbox you may want to use a property node with the "Strings[]" value. What exactly do you mean that the selected cell takes a life of its own? Can you post an example of the way your control is setup? Hope that helps, Jan
  6. Thanks for the great feedback! I am indebted to all of you I am displaying every frame in real-time using en embedded IMAQ WindDraw window and crelf's WindDraw embedding VI. The draw speed is actually fairly fast, on the order of 3ms. I have also tried displaying every second frame of the capture to speed things up, but without success. I am working with 8-bit 640*480 images. I've played around with a few codec's and even got DivX working for a while but I'm just sticking with Microsoft Video 1 at this point. The actual encoding of the AVI is independant of the capture (as I will explain in a second). (Sidenote: has anyone tried implementing x264? I compiled with MinGW but it's a long ways off from LabVIEW integration.) I'm using a 1410 frame grabber and a 6024E DAQmx card. They have a RTSI cable running between them and I'm using that to synchronize/time the acquisition. In MAX a simple grab will show that I can acquire 29fps but display only 15fps. I think this could explain why 15fps is the tipping point for a DAQ buffer overflow I was experiencing. I've designed my program with three loops instead of two. One GUI loop with an event structure that doesn't timeout and waits for user input. One video loop which runs in real time with the video playback/record speed. And one buffer loop which runs as fast as possible (with a small 1ms delay) to either cue up frames into the read buffer or write frames to file from the write buffer. In acquisition mode the program uses the constructs from the LL Ring example and so I am using a ring buffer to acquire images. Unlike Yuri33's suggestion though, I'm actually passing the image references to the write queue. So far, I've been reliant on the fact that Microsoft Video 1 is a fairly fast codec and I haven't had any overwrite of the ring buffer before actually writing the AVI frame. I've also had at one point a second ring buffer of IMAQ images to store the images as they are passed between the 2nd and 3rd loops but I've removed it in effort to gain efficiency. I like your idea of flushing the whole IMAQ buffer Yuri, but is that possible if I want to synchronize DAQ acquisition with each frame? You also suggest flushing the whole queue for recording the AVI and only then displaying the image, does this still ensure that images are displayed "live", that is to say, does there exist a delay between what the camera records and what the user sees because of the time taken to flush the whole queue and write each frame? Currently I capture and display the image at the same time but I write the AVI in a different loop. It sounds like the solution to speeding things up is to seperate the display from the capture. I'll see if I can implent something like that and come back. I really appreciate the help though! Plus I'm glad that I'm not the only one who's tried this. Cheers, Jan
  7. Hello all, I'm working on a conceptually fairly simple project: coding a video recorder/player with the capability of recording DAQmx channels alongside. I'm using the IMAQ AVI functions in combination with some queue-powered buffers I've wired. I have a working video player but my video recorder application still can't get better than 15 frames per second. I've done some timing tests on my program and I've noticed the following: If I try to record video/DAQ at 20fps I should have 50ms between frames to queue up all my data to my write buffer. My sub-vis only account for 30ms worth of processing time in that window but I the whole process of acquiring a frame still takes at least 75ms. Could queues and primitive functions really be taking up to 20ms? How slow are queues really? Also, I am using the IMAQ buffers described in the LL Ring.vi example so the actual IMAQ acquisition is fairly quick. On top of that my write loop also uses a ring buffer. Right now I'm thinking my approach might just be wrong. Does anyone know how media recording software is constructed in general? Has anyone attempted this task? Thanks for any help! Cheers, Jan
  8. Hi Karissap! Here's a simple VI showing how you can get to those properties. I agree it's not the most intuitive thing Jan
  9. I think it would be both for zooming in and zooming out. For example: instead of having a box representing your sub-VI, you could have the sub-VI block diagram embedded into the main VI and simply use zoom functions to access the sub-VI. There was a lot of discussion on another thread I was reading about making LabVIEW work in 3D. I think an implementation of this nature would fill that need. In effect, we don't need an extra dimension in our block diagrams, we just need more space without compromising the general shape/structure of wiring layouts. Primarily I think Deepfish could be useful because it renders vector graphics, which would mean that going from Block Diagram to Pixmap or vector graphics could be done. And from there on, you'd basically be using the Deepfish rendering engine. I'm not actually entirely how the block diagram is rendered? Does NI release this information? It's proprietary I bet, but it's pretty interesting. I'll keep reading! Thanks!
  10. Hello LV Forums! First post I'm working with LV 8.2.1 this summer and I was hoping to put this idea out there: I would really like to have continous zoom in and out of my block diagrams. And now the technology to do so is here! Microsoft Live Labs (currently developing Photosynth as well) is working on Deepfish which was recently demoed at TED Talks: http://www.ted.com/index.php/talks/view/id/129 and is also on their site: http://labs.live.com/deepfish/ . It's reminiscent of the way Safari on iPhone browses webpages but am I the only one who thinks this would be amazing for block diagrams? Cheers Jan
×
×
  • Create New...

Important Information

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