Rolf Kalbermatter

QUOTE(Tomi Maila @ Nov 6 2007, 02:52 PM) Better yet! Just use LabVIEW alone as library name, watch out this one is case sensitive! And then you won't have to worry about lvrt.dll or labview.exe depending on if you build an application or not. Rolf Kalbermatter

QUOTE(crelf @ Oct 27 2007, 03:18 PM) Standardized works too, and for floating points NaN is probably the best approach, at least I do it that way if I do it at all. Of course it could fail if there is an actual calculation that is invalid and its result is wired to that input. But!! then having tested for NaN (and probably doing some default action) is still most probably the best course of action. In terms of subVIs I have not yet come across situations were I wanted really to know if a value was unwired, but quite often if it was valid at all, wired or not! Rolf Kalbermatter

QUOTE(sprezzaturon @ Nov 1 2007, 09:22 AM) The standard developer edition does not include IMAQ Vision. It's an add-on to the developer edition too. And then comes the question isn't there some sort of discrepancy between LabVIEW Developer Edition + IMAQ Vision == WebCam? I would think so. That said if you have IMAQ Vision, the IMAQ for USB (which is a free and unsupported download) certainly would work. If you don't have IMAQ Vision I'm not sure where the analogy about coffee machine routines would be that LabVIEW might contain. Because your LabVIEW obviously doesn't contain real image manipulations too. Of course you can always use generic numeric analysis functions to work on images but by that definition every compiler out there should come with Webcam support. QUOTE I'm not expecting the world here. It's like buying the best DVD player in the world only to get it home and find out that it's buttonless and the remote is going to cost as much as the DVD player. Just a little vent of frustration... With nowadays DVD player street prices that is not even unlikely to happen . Maybe that could say something about what things might be wrong in this world, but that is more of a general problem and has not so much to do with LabVIEW. Rolf Kalbermatter

QUOTE(daro @ Oct 27 2007, 09:10 AM) I really doubt that Vision Assistent 7.1 can control LabVIEW 8.2 to create VIs in it. The other way around I think would work but not a random number of versions backwards. Rolf Kalbermatter

QUOTE(sprezzaturon @ Oct 22 2007, 07:01 AM) And I still can't control my coffe machine with LabVIEW!! Honestly you can always expect anything and everything but I don't think that makes it a legitime expectation just by itself. Most LabVIEW developers couldn't care about webcam access at all. If all you want to do is controlling a life webcam, then the LabVIEW Developers Edition certainly is not the right tool. Rolf Kalbermatter

QUOTE(Panos @ Oct 30 2007, 08:16 AM) Cross posted at http://forums.ni.com/ni/board/message?boar...ssage.id=281182 Please mention when you do a cross post so people can know! Rolf Kalbermatter

QUOTE(Giseli Ramos @ Oct 30 2007, 08:51 AM) The RtlMoveMemory function does not have to be a problem for you. LabVIEW also exports a MoveBlock() function that you can access with the Call Library Node. There is an example at http://zone.ni.com/devzone/cda/epd/p/id/3672 that shows exactly this and it works on every LabVIEW platform. But since you have the source of your shared lib, go for the changed API. It's clearer! Rolf Kalbermatter

QUOTE(PJM_labview @ Oct 24 2007, 11:07 AM) Which VI/Xnode file would you suggest to look at as starting point for that? Rolf Kalbermatter

QUOTE(tharrenos @ Oct 24 2007, 08:49 AM) There is no conversion really. The TCP nodes interpret the data that is passed to them simply as a stream of bytes, which a string is in fact too. So if you want to send binary data you simply create an array of U8 bytes the way you want your byte stream to look like and cast it to a string with the Byte Array To String node. If it is text your device expects you format this text into the string. Rolf Kalbermatter

QUOTE(Tomi Maila @ Oct 22 2007, 02:43 PM) Apart from the already mentioned templates I don't think there is any way to have an Xnode work as a structure. They can be resizing nodes but that is about it. And if I was you I would try to patent it, before you publish it. Otherwise NI will do it :ninja: Rolf Kalbermatter

QUOTE(tharrenos @ Oct 23 2007, 05:22 PM) Well how the Lantronix device converts TCP/IP into RS-232 will have to be defined by them. So read the documentation for the Lantronix device, bug their technical support and ask for some examples. And yes don't expect them to have LabVIEW examples. Much more than C is probably not possible, maybe one VB example too, but it should give you some ideas. Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ Oct 5 2007, 03:42 PM) It's not that difficult once you now how ;-) Rolf Kalbermatter

QUOTE(Justin Goeres @ Oct 17 2007, 08:10 AM) Well, that is not entirely true. The LabVIEW DSC Toolkit comes with an access control library with user configuration dialogs and login screens and a Wizard that can enable and disable controls in a front panel based on the currently active user from this access control system. It is quite powerful but the entire DSC Toolkit is not cheap and if it is only just for this user access control sybsystem it might be a bit overkill. On the other hand it is (or at least used to be, not sure about the latest status) something you could embed in your own applications without runtime license fees (not true for most other parts of the DSC Toolkit) and designing your own even remotely comparable access control system will cost a lot more in money and not have the ease of use of a front panel control configuration wizard. Rolf Kalbermatter

QUOTE(vinayk @ Oct 19 2007, 01:14 PM) The error means as the error handler VI can tell you, that the VI is not in memory. Why you may ask! Because you think you provide a path to the VI to the Open VI primitive, but you don't. This VI will interprete a string input as VI name and nothing else. And when you provide a VI name only the VI must be already in memory. What you want to do is change the string constant into a path constant instead! And with that we are at the next problem. Using absolute path names to refer to VIs is ABSOLUTELY the worst you can do. This will immediately break when you move your project, or build an executable and/or install this on another machine. So reconsider how you want to refer to those dynamic VIs. The way I do this is having a VI somewhere whose location is relative to the dynamically called VIs, for instance in the same directory. Then this VI queries its own path and strips its name from that path and returns that. Now append to that path the VI name you want to load et voila. Rolf Kalbermatter

QUOTE(Neville D @ Oct 11 2007, 12:10 PM) <br /><br /><br />That configuration should be stored in the LabVIEW INI file and reused on each load. Not sure about the current version of LabVIEW but you actually needed to restart LabVIEW in order to get that configuration active when Thread support was introduced in LabVIEW 5.0. Rolf Kalbermatter

QUOTE(Gabi1 @ Oct 9 2007, 09:18 AM) Yes I do mean that and it's because of what you mention in your last sentence. A lot of work to create something which is hard to debug, maintain and use. I have some experience with this but with templates, since reentrancy was not possible for dynamic VIs back then. And it is a pain in the ###### whenever I have to go back and change something about it and then consequently test it too. Rolf Kalbermatter

QUOTE(Smikey @ Oct 9 2007, 02:50 AM) I would say you are on the wrong board here. The SMX2064 not being a NI product, MAX can do little more than verify that the general PXI registers are there and some manufacturer identification is available. Other than that MAX does almost certainly not know how to access that board. Then the Visual Basic application: If it encounters a problem, you will have to take it up with the programmer of that application. Again NI and probably just about anybody else here can not even guess what the problem might be. Rolf Kalbermatter

QUOTE(Gabi1 @ Oct 9 2007, 08:49 AM) Well aside from the obvious of having the VI simply in a BD and accessing that particular instance from there, no! Unlike non-reentrant VIs where the name of a VI is enough to reopen a VI reference to it, reentrant VIs maintain their data space attached to the VI instance (reference) and once you loose such a reference you loose the data space. But then using reentrant VIs through VI Server is usually more trouble than it is worth so I personally wouldn't really do it. Rolf Kalbermatter

QUOTE(JFM @ Oct 8 2007, 07:54 AM) I'm not sure what version of Pharlap they purchased. But even if they got the source code for it, fiddling with the network socket code in an OS is a very tricky thing to do. Probably there would be a #define somewhere for the maximum allowable sockets and that is were it goes wrong. In many RT OSes the sockets are maintained in a static list and being static means it is preallocated at compile time and can never grow bigger than the max. Changing that into a dynamic list has possible performance drawbacks and makes the resource management in general more complex, so that is not something one wants to modify into an existing static implementation. Nice to hear that VxWorks seems not to have this limitation. Rolf Kalbermatter

QUOTE(klessm1 @ Oct 8 2007, 11:46 AM) The best bet is always to use the newer version of a lib if you get such a conflict but it will not always work. The newer version may change interfaces (yes it's a bad thing to do, but it's very easy to if the developers don't watch very extremely carefully) and then crash the application which was compiled to the older lib. But as long as it seems to work, I would definitely try it. If you get to know what they use QTlib for, I would be really curious. I could try a disassembler but don't feel like doing it nor have I the time at the moment. Rolf Kalbermatter

QUOTE(crelf @ Oct 8 2007, 06:48 AM) That is mostly from comments on the wine-devel mailing list at http://www.winehq.org/pipermail/wine-devel/. But searching through all of the mailing list archives won't be trivial. A lot of work on MSI was done by Mike Mc Cormack and Robert Shearman from Codeweavers and they had some comments on MSI in a few mailings. I couldn't find easily a specific wiki page for MSI on wiki.winehq.org so I'm not sure about a more concise collection on findings about MSI. Rolf Kalbermatter

QUOTE(crelf @ Oct 7 2007, 03:01 PM) Hard to find that back! I was looking about 6 months ago for a tool to see how MSI is built up to fix some issues with a corrupted installation that refused to allow me to uninstall it nor upgrade it to a newer version. And on the MS site I came across an article about the tool Orca which is basically the original tool to look into and edit MSI files. In there one of the persons involved in the development of MSI quite at the start explained how it got started and the decision to use a relational database structure as the base of an MSI file and he was strongly suggesting that that use of a relational database was quite an overkill in terms of what needed to be solved but that at the time they started to realise it it was already a fact. I would be glad to point you to that article but have to admit that I have no idea anymore what search criteria got me there in the first place but it was on an MS or MSDN site somewhere. And on my current system most of the software that used to show up under the National Instruments Installer now also shows up in the main installed components section and refuses to uninstall from either location. Upgrading still seems to work for that software but I also have components visible that are really subcomponents of other (non NI) software and don't give any option to uninstall, repair or whatever. So I'm sure my MSI registry database is currently quite messed up but I hesitate to do a full reinstall of this machine as that takes me at least 3 days to do, with all the NI software and other tools that I frequently use. The MS registry clean utilities that should help don't do anything for these entries either! PS: I do follow Wine development too and they did a lot of work on MSI support in the last two years and the overal consent there seems to be that MSI might be to most overengineered part of Windows and contains quite some rather questionable design decisions and implementations. Rolf Kalbermatter

QUOTE(ashishuttarwar @ Oct 3 2007, 03:09 PM) I would really recommned doing that. It's not a good idea to rely on a particular MAX default setting. You might end up just copying the program to a different computer (maybe your development machine died) and suddenly it doesn't work at all. Setting the serial port parameters explicitedly in your program before using it will prevent this problem. And believe me when you are in a hurry it is usually not the first thing to do to search the problem exactly there. So 5 minutes of extra programming time can save you many minutes or even hours of problem solving later on. Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ May 16 2007, 07:57 PM) I think NI shoot in their own foot when they decided to go with MSI as their installer solution. Not only is MSI even according to some of the people involved in its development quite an overkill in many aspects to the problem of software installation but it is such a huge and infelxible beast that you simply have two choices: Dump it and go for something else or live with its difficulties and inefficiencies. And as longer as you do the second as harder its gets to do the first. Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ Oct 3 2007, 01:36 PM) I remember several comments of him that would sound to me like belonging in the same category. Rolf Kalbermatter