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