robijn

I'm so glad malleable VIs and the Type Specialization Structure exist now. Well done NI!

Hi, You could perform all the calculations yourself though. It's a matter of calculating for each pixel in the image at which pan & tilt angle it actually is, doing that for multiple images, then combine them and then calculating them back to a single picture. Most lenses are rectilinear (by approximation). It means a rectangular plane is projected as a rectangle on the sensor. You can use the arctangent function to calculate the angle. You'll need the pan & tilt angles to be able to do the combination. It's not without problems though, because no lens is perfect. But it can be done in an acceptable way (I did once manage to get it done a few years ago). Joris

Hi, The FTDI devices and drivers are very good. I've never had them crash and they always do what you want. Actually very few driver releases have been around at all, which is a good sign. I have programmed SPI (amongst other protocols) but I choose not to use MPSSE. It is not necesary, you can only use it to compact your data a bit. Much easier is to use bit bang mode. Create a pattern with your input data, write that, then read the same amount of data back, and decode the output data. Joris

QUOTE (bsvingen @ Feb 26 2009, 10:59 AM) I don't agree with you here. The layers are used to show an abstraction, but it is not the abstraction itself. That is a fundamental difference with an other way of abstraction, by hierarchy. Then the function (or subVI) is the abstraction itself. I think hiding elements in a block diagram does not make it clearer to understand. Does it not encourage making a mess because you can use the hiding tools anyway ? Maybe NI could write a block diagram analyzer that could make a suggestion of what code to place inside a subVI. It could do this based on the the self-sufficiency of a certain part of the code, which can be calculated from the number of wires. However, it would then also need to analyse which wires could better be bundled (cluster), because this is closely linked. Quite a complex problem. Maybe it's best to leave this to a human QUOTE (bsvingen @ Feb 26 2009, 10:59 AM) The error concept is not a fundamental entity for dataflow, it is more like a "wrapping" to put around sub vis. I consider errors in LabVIEW the same as a throw-catch mechanism like in Java (and others). When I place (or get) an error in a wire, code further on will not be executed. The current subVI is exited quickly, and it hands the error to the next VI. I use a special VI (Suppress errors.vi) to catch given errors and for these I might perform a certain action. I could decide to retry, or to generate a different error instead. By default (if the error was not in the list of errors to be handled) the error stays and this means any further code is also not executed. Errors are transported by dataflow and therefor fit in perfectly. Just like in Java I can put some information in the error to know what the error is about. I like that. Joris Edit: made bold actually bold

QUOTE (Ic3Knight @ Feb 25 2009, 03:32 PM) The crossings of wires at property nodes have annoyed me as well. Could it be an option of the node to have the error connectors of property/invoke nodes be placed the the bottom ? Then it would be in line with the commonly accepted style, without too much changes. Refs at top, data in the middle, error at bottom. Joris

Hi Tomi, It's possible to do a little bit in this area. I've been working on instant replay, i.e. continuously recording and playing back at the same time in slow-motion. It's difficult to keep the framerate up continuously. It's easy to get a disturbance, and this sometimes leads to avelance effects causing a lock-up for many seconds... I would think for real-time mixing etcetera there are much nicer applications available, also for much less money. Joris

QUOTE (2and4 @ Jan 13 2009, 11:46 PM) Do you want to call the API to do more than just collect the image ? If you only need to get the images: I've used NI-IMAQ with the "IMAQ for USB" addition with great success. I have a STK1150 compatible capture device called something like EasyCap that works like a charm. It can capture composite and S-video. Never crashed or had strange problems. Further it only installs a small driver that can do full frame (720x576), full speed (25fps) without problems (getting it on the screen at that rate is another matter...). I think it can do both PAL and NTSC. It's just perfect. Joris

QUOTE (2and4 @ Jan 13 2009, 11:46 PM) Do you want to call the API to do more than just collect the image ? If you only need to get the images: I've used NI-IMAQ with the "IMAQ for USB" addition with great success. I have a STK1150 compatible capture device called something like EasyCap that works like a charm. It can capture composite and S-video. Never crashed or had strange problems. Further it only installs a small driver that can do full frame (720x576), full speed (25fps) without problems (getting it on the screen at that rate is another matter...). I think it can do both PAL and NTSC. It's just perfect. Joris

Hi, I have checked with version 8.5. Depending on the option "Automatically close VISA sessions" the behaviour is as follows for me: Option off: The resource stays valid; Option on: The resource becomes invalid when the second VI stops (even though the first one still has this resource selected in its control). Regards, Joris

QUOTE (DidikChandra @ Sep 14 2008, 01:53 AM) Hi, What you want is perfectly possible from LabVIEW by calling the microsoft command line tool devcon, which is freely available. I've used it in the past to detect inserted USB devices, but you can enable, disable, install, uninstall all kinds of devices with it. It can also reboot your PC. Joris

QUOTE (AutoMeasure @ Jun 3 2008, 05:56 PM) No, that's not possible. The interface is capable of supporting this, and I think this is relatively little work for NI to implement it. From a sales point of view there should not be too big a problem either, as you need IMAQ anyway if you want to do image manipulations, so many people would be happy (including me !). What you can do in your case (slow capture) is open and close a camera each time. You are able to select from multiple cameras/sources if they have a different name. Joris

Basler GigE cameras are quite affordable. Joris

QUOTE (Tomi Maila @ May 16 2008, 06:37 PM) You can use a counter of a DAQ card to count the frames via the V sync. And maybe you can generate an IRQ at every V sync...? With these things you can update the picture on screen according to the actual frame number. Joris

I also wanted to use the standarized joystick interface instead of expensive hardware to detect joystick and potmeter positions. I ended up with this controller: http://www.lbodnar.dsl.pipex.com/joystick/ which is very nice. You could even use it to acquire voltages between 0 and 5V as really cheap analog input device. But if you do this be warned, the inputs are not protected so this is not advisable. This one has 10 bits, sufficiently accurate for me. So far I only needed 4 of the possible 8 axes and about 15 buttons of the 32 possible. The best feature of this type of controller is that you don't need any special drivers to use it (on windows). Joris

XML was meant to be easy and human readable. Both those goals were missed. I don't use it but use text files instead. Joris

I wanna change values in wires while debugging ! Joris

Maybe you can use remote VISA. There are also programs that read a hardware port and generate multiple software ports that all lead to this same hardware port. Xport is such a program. Joris

QUOTE(R.Alves @ Feb 6 2008, 03:27 PM) IMAQ for USB has special VI's to read from generic windoze cameras. You cannot use the normal functions to grab the image. Joris

QUOTE(R.Alves @ Jan 29 2008, 08:30 PM) I guess that the IMAQ for USB toolkit will work then, it's free for download but I think it requires IMAQ. I am using this toolkit to grab images from S-video inputs on USB capture cards. It also works with webcams. Joris

GigE is the way to go. I guess it wont be long before there is an RT system with a compatible interface. Joris

QUOTE(yasmeen85 @ Jan 25 2008, 12:59 PM) You don't have to read per single cell. You can read the whole file at once, there are functions for that. After reading the whole file you can perform your described algorithmn on the data - which will have to be performed cell-by-cell. BTW reading from an Excel file is difficult, but there is a standard function to read from a CSV file or Tab separated file (also creatable with Excel). Joris

QUOTE(Aristos Queue @ Jan 7 2008, 03:06 PM) Well, not against that part of the story. I would object against the comparison being made with C. Only with lots of knowlegde of the internals it's possible to know if new memory will be allocated or that existing memory will be reused. As a programmer, I don't consider this interesting. I want to use my objects, I don't want to think about how I should shuffle with the various parts of memory. Only when things are too slow, I am going to optimize my code and remove duplicate allocations and copies. The first C example would contain the data right in the parent objects. This would result in an infinite size of the object, as each child object would contain yet another fully sized object. But in LabVIEW we cannot control how the data is stored. Advanced users know that complex data structures are stored with a pointer to them. But in theory, the storage behaviour of for example a string could be changed by NI at any time, and the resulting programs would still run the same (apart from big timing differences). The current implementation is one of multiple possible implementations, where the semantics are the same. The structure of how the data is stored is much more similar to Java, so I consider that a beter comparison. In Java, just as in LabVIEW, you have no direct influence on how the compiler performs its actions, but you know the end result. You cannot access pointers there. When you store an object, internally a pointer is stored, just like it's done in LabVIEW. There is no fundamental problem with recusive structures in Java, while you cannot use use dangerous pointers like in C. And what is nice is that you can "store" a NULL object. Joris PS Very clear article Tomi !

QUOTE(Aristos Queue @ Jan 6 2008, 08:10 PM) Is it really ? I thought we could not build a doubly linked list. Joris

QUOTE(rolfk @ Nov 1 2007, 10:05 AM) Hi, I'm tuning in a little late, but I've just found out that with IMAQ for USB I can actually read images of ANY windows standard video device. This is very convenient, and I think this would really be something worth considering to have in the LabVIEW standard package. Of course without the extra tools that IMAQ offers. I have a Pan-Tilt-Zoom camera (Sony-D31) which is really cool to control from LabVIEW. I am acquiring the S-video signal with a Hauppauge WinTV card. I wanted to have a bit of an overview of the camera's range, so I decided to stitch some images. The result is below. With some work it would have been possible to do this without advanced IMAQ functions - provided you have access to the image data array. http://lavag.org/old_files/monthly_01_2008/post-1555-1199268831.jpg' target="_blank"> This is about 200 degrees wide, and I have to program some more to get some 15 degrees extra on all outer borders (so 230 degrees). I think I will be using this at the EC swimming in Eindhoven in March to be able to point the camera's. There's no real budget for this, it's just hobby work. Joris

Hoora ! Implementing your own "stack" was often a bit cumbersome (although it forced you to think about the problem...) I have had for a long time the following text in the footer of my mail - just to illustrate: To understand recursion, we must first understand recursion. And a happy new year to all of you ! (sorry, this is terribly off topic) Joris