Rolf Kalbermatter

QUOTE (karthik @ Aug 17 2007, 09:06 AM) One thing I have noticed is that at some point Agilent, then still HP was marketing Vee rather agressively trying to get every LabVIEW account they could. This has changed a lot in the last 8 years. Now they try to market it together with their devices to Agilent shops (customers heavily using Agilent devices) mostly and seem to have abandoned most other venues to sell it. As such it would seem to me to have a rather limited user base. It certainly is second to none if you only have to deal with Agilent devices and like the way you have to think and program in Vee, but for most anything else it has no advantages to LabVIEW and IMO, a lot of disadvantages, but it's been a long time since I played with an evalution version of it. Rolf Kalbermatter

QUOTE (No.1 @ Mar 30 2009, 08:56 PM) Neither am I. I use my own ODBC based VI library and ODBC does not know an explicit cancel method but you simply close the statement handle (a specific query or other SQL statment execution) with an option to force it. What that does on the server side is however quite a different story since it is ODBC driver specific. It could communicate the closing of the statement to the server and cause it to abort any ongoing activity on that statement but it could also just close the handle on the client side and let the server continue with whatever it is doing, eventually discarding any response from the server it gets for this particular statement. Rolf Kalbermatter

QUOTE (Mark Yedinak @ Mar 30 2009, 04:35 PM) This would seem mostly a useless restriction to me unless for security reasons, when you want to restrict the firewall passthrough both on the outgoing and incoming side. Rolf Kalbermatter

QUOTE (No.1 @ Mar 29 2009, 10:41 PM) By not using high level VIs but taking apart your query into at least an Execute query and the actual data retrieval. If you close the statement or result set reference before you actually retrieve the data, the query should be dropped and any already generated data with it. You probably need to find a way to see if the query already produced some data before starting the retrieval as it might not be possible to cancel an already started data retrieval. You can try it out however if closing the result set reference in another part of the code does maybe abort the data retrieval too. Rolf Kalbermatter

QUOTE (hma @ Jun 8 2007, 08:02 AM) I understand now what you want, but don't feel this type of Tab Control is ergonomic in any way. I usually feel annoyed whenever I see a tab control that goes over more than one line of tabs. The variant with scrollarrows to the right to scroll through more tabs than what is possible to put on the screen is only slightly better IMO. Personally I prefer for cases like this the array index display approach with a Pull Down menu control or a List Box control being the element selector and the rest of the page presenting the currently selected array element. And that is not just because it is easier to do in LabVIEW than the multi row tab control . Rolf Kalbermatter

QUOTE (Clio75 @ Mar 27 2009, 04:37 PM) Scan from String will not have this problem. And if you know you could have numbers with a specific decimal point instead of the current system decimal point (instrument responses for instance) you just prepend the %.; to the format string. Rolf Kalbermatter

QUOTE (xavier30 @ Mar 27 2009, 11:17 AM) So you are supposedly using the Call Library Node to call those external Libraries. Ever checked (really really throughfully) that you pass all the right data types to the Shared lib, and most importantly never pass in an array or string buffer to the lib to be filled in by this library that could be to small? The fact that it works in the IDE or on Windows means really nothing in the case of such problems. The buffer you pass into the library might often border non vital data that gets corrupted too, but won't cause a fatal crash or it might be even so that it is a buffer for a filepath that is shorter in those other situations never overwriting illegal memory except in the runtime installation. Lots of things to consider here, but using the Call Library Node and testing your application to not crash on one specific installation/built is really not enough. You really ought to validate every single Call Library Node to have all the data types right and most importatnly either have no output data buffer (array or string filled in by the library) or that those buffers are under all possible circumstances preallocated large enough in the LabVIEW diagram. Rolf Kalbermatter

QUOTE (ned @ Mar 28 2009, 02:01 PM) Ben is right. No need to request the TCP Open to open a specific local port at all. Just leave the local port input empty, which tells LabVIEW to let the OS select whatever port it can. For a client (No TCP Listen used) only the remote port is normally important, except with some strange protocols sometimes. Rolf Kalbermatter

QUOTE (zythum @ Mar 27 2009, 11:33 AM) While File Mappings aren't that difficult, the Windows API to deal with that is a bit more complex then just accessing a single function. So this part while in theory possible to be dealt with directly from the diagram using the Call Library Node is actually better handled in an external C DLL, that deals with these problems directly and offers LabVIEW a clean and easy to access interface. The real killer however is the Windows message handling that is required. To implement that in LabVIEW only is not possible, since there is no way for you as LabVIEW programmer to intercept specific Windows messages. There is a Windows_Message_Queue example on the NI site that offers a C++ DLL to do that, but it is not exactly for what you need and you will have to modify it to work for your purposes. So I would simply create a complete new DLL and put everything in there. If I would have to do that I would estimate about 1 day of work for this to get a reliably working DLL and two or three LabVIEW VIs to access this. Now I do have a lot of experience with external C code integration in LabVIEW, so if you are gonna do that expect to have quite a bit longer for this and be willing to learn C to a level that goes well beyond beginners level. Rolf Kalbermatter

QUOTE (EHM @ Mar 26 2009, 10:37 PM) Not sure about your proxy but I did not add the Host: xxxxxxxxxxxx in the past to my proxy requests and that worked. The Host can be added according to the RFC for forward compatibility but I don't think it is required. The absolute URI however seems to be at least for older HTTP versions a requirement. I did however use HTTP/1.0 as version indication so maybe that is why. And last but not least: are you sure there is an index.html document on the server. It could be index.htm or something entirely different so as a start I would try just the server address http://www.example.com/ without any document path. Rolf Kalbermatter

QUOTE (jlokanis @ Mar 24 2009, 02:16 PM) Anything special about your setup? Project or project VIs on a network drive? LabVIEW starting up from a network drive? It seems that there must be something like this. Something similar though not to LabVIEW only I see on my machine if I do not have a connection to my VPN server. Presumably because I have a path somewhere in the registry that points to a location on a shared drive only available when logged in through VPN. But Widnows seems to check that path anyhow everytime I click on a file in Explorer . It's annoying but not annoying enough to really dig through the registry to find the offending entry. Rolf Kalbermatter

QUOTE (Yair @ Mar 24 2009, 01:55 PM) I hadn't noticed at first but if you go to his blog he has linked to, you can find some info about things he did. Seems he likes to tinker with computers and some of what is written there certainly is on the border of legality. Might be using dads LabVIEW copy or whatever and taking his last few inquiries together he might be just looking for things to crack, probably more to boost about than anything else. Rolf Kalbermatter

QUOTE (NeilA @ Mar 23 2009, 02:19 PM) What your ActiveX node requires is not directly a GUID but an object reference to one. Most likely because it requires it as the binary form of a GUID and not as string. Why someone would make an ActiveX interface like that is beyond me but here it is. You could try with Variant to Data. Failing that you will have to find out what reference class that node expects (you could try to right click on it and create a FP control and inspect its ActiveX class name). If that works you will have to find out how to instantiate such an object on your system and then find the method that intializes it with the string form of your GUID. Rolf Kalbermatter

QUOTE (BOBILLIER @ Mar 23 2009, 05:13 PM) So what speaks against making your LabVIEW application work in the format that the current user is using? LabVIEW's string conversion function give you every power to do that. If you know you need to deal with decimal point (for instance instrument communication) then disable the "use system decimal point" input at the string nodes or prepend %.; to all format strings for Format into String and Scan from String. If however you write out data to disk or whatever, such as a spreadsheet file to be read by the other application then just leave it as is and LabVIEW will use whatever is the current user setting for the decimal point. Don't try to outsmart your end user. They seldom can appreciate that . Instead make your application work as best as possible in the environment your users work. It may seem like a lot of a hassle to do what I explained above and after the fact it can be indeed quite a bit of work. But once you stick to this rule it does in fact not cost you any more work as it will get second nature to consider at all string formatting places if you do need a specific format or instead want to go with whatever the user has currently selected. It always depends who will be the other device/application dealing with the data. Rolf Kalbermatter

QUOTE (LVBeginner @ Mar 19 2009, 10:56 AM) WinHTTP should by default use the proxy server settings that you have configured for your IE. The local port is assigned randomly by the OS and should be of no concern to anyone. If you experience problems with the firewall you will have to create an exception rule in it that opens outgoing connections to the target port of the proxy such as 8080. Rolf Kalbermatter

QUOTE (BOBILLIER @ Mar 23 2009, 01:14 PM) MSDN is your friend. But if you intend to write an application for other users that is going to overwrite their preferred system settings you are going to annoy most of your users big time. A program trying to mess with my system is going to be uninstalled in a matter of seconds never to be looked at again, no matter how nice it is. Rolf Kalbermatter

QUOTE (Yair @ Mar 23 2009, 02:18 PM) It is indeed undocumented and has no editors that are available to people outside the LabVIEW R&D and I honestly doubt there are even many people in LabVIEW R&D that still would know how to use it :-) Basically it resembles the Mac PICT format with some modifications. Rolf Kalbermatter

QUOTE (KarstenDallmeyer @ Dec 5 2008, 06:34 AM) If you know you want to use the broadcast address you can also just simply plop a U32 constant and type in as large a value as you like with at least 11 digits. LabVIEW will truncate it to the max for an U32 which is 2^32 - 1 = 4294967295 = 0xFFFFFFFF which incidentally is the U32 value of the IP adress 255.255.255.255. So while the String to IP seems to have indeed technically a bug I never would have noticed since I do not go through the turnabout way of using String To IP to pass the broadcast UDP address to the UDP Write node. Rolf Kalbermatter

This is a version I did about 15 years ago in what was then LabVIEW 3.1. I programmed it to work with 8bit color images but it seems to work well for the 1 bit images you provided too. It is by far not what I would recommend to program nowadays although I think there are some interesting ideas in there. If you look at the Decode Bitmap function you may wonder why it is programmed like it is. The reason is manyfold. First there was no inplace operations back then. Second this had to run on 486DX 33 MHz CPUs back then without requiring minutes of runtime execution. I think you could squezze out a few more optimizations but in general it was what was necessary to make a RLE Decoder performant in LabVIEW back then. As said it is not really how I would program it today both in terms of using LabVIEW features as well as overal architecture but here it is. I only upgraded it to 6.0.2 from 3.1 so it can be also read with the newest LabVIEW version. Nothing else was really changed. Download File:post-349-1237721972.llb Rolf Kalbermatter

QUOTE (Yair @ Mar 16 2009, 01:52 PM) Yair is quite right. Most of the scripting properties are NOT accessible remotely for a good reason. Think about security! And about how they build VIs in Vision Builder and Co: Quite simple by executing LabVIEW VIs that run in a special runtime environment that is part of the tool that has the scripting feature not removed. Can you create a VI executable that could make use of that runtime environment? No, not really, both because of technical limits (no tool to create a LabVIEW executable that would call this special runtime instead of the standard lvrt.dll) as well as legal (that runtime only comes with those tools and is part of their license). Even if you would have installed and licensed that tool on the target machine it would be legally questionable if you have the right to execute your own code using that runtime engine enclosed in there. Rolf Kalbermatter

QUOTE (flarn2006 @ Mar 20 2009, 07:32 PM) The answer is quite simple. If you would have the source code of LabVIEW you could! You could then easily build a "cheat engine" as you call it from that source code where the password check is disabled. However the password protection itself of LabVIEW files is fairly sound. There is encryption of parts of the (undocumented) binary file structure to create a hash key. And recent versions create multiple such hash keys over various parts and that spans even the plain text readable new style XML LabVIEW files. In addition a VI knows about the password protection of the owning library and vice versa and the same with classes. While patching an older LabVIEW executable was probably an option for a good hacker I have serious doubts that this is still possible within a reasonable amount of time. And it is the worst way as every single patch release of LabVIEW is nullifing that. Hint to NI: that would be one more reason to actually release intermediate patch fixes! Makes almost every user happy and makes the life for those trying to go around the password protection a little more difficult. In the past few versions patch fix releases were never really announced properly but only in according discussion threads. I would find it useful to consider a somewhat more proactive patch fix release announcement. Rolf Kalbermatter

QUOTE (ASTDan @ Mar 18 2009, 03:08 PM) While you can get away not using the project for simple LabVIEW host applications it sure is a very handy tool to use when you start to do multi target applications (host, RT, and FPGA, and/or PDA targets in one project). I also agree that the auto populating feature is rather disturbing than useful. My projects never contain the low level functions but only the top level functions of each target, the dynamic VIs in a seperate folder and any GUIs in another folder. Possibly I add another folder for some specific VIs etc. I still organize my files on disk too but I find it useful to have another level of organization where I can maintain a somewhat different logic of how to organize my VIs than what it looks on disk. The feature that is called autopopulating folders by NI (just copy the disk hierarchy into a seperate tree view) is not useful at all in my view, and does cause all sorts of headaches for the NI developers too to avoid cross linking in the project. That all said I still have projects that were developed in earlier LabVIEW versions and are currently maintained in LabVIEW 7.1.1. So I couldn't even throw away the traditional way of organizing VIs even if I wanted to. QUOTE (jgcode @ Mar 19 2009, 10:56 PM) neBulus and Neville D Maybe this would have helped? Real-Time Target System Replication I haven't used the code personally but I know they exist as I was investigating for a similar thing for a project that went cold last year. Now there is one for FPGA too. FPGA Target System Replication While I haven't used the latter the first one is indeed working. I didn't use it for multi target deployment but built them into the host application to have a user friendly way of updating the RT target with a new software version if that should arise. It is a bit tricky to built it into a user application in a way that it can be used by people not familiar with LabVIEW or even programming at all. I made it basically a one button click operation in the maintenance screen of the application together with another button to discover any cFP target in the local network to fill in the IP address to use. Seems trivial enough to use. Rolf Kalbermatter

QUOTE (RickAlta @ Mar 19 2009, 07:59 PM) It sure is messy and with a lot of troubles. The alternative is to create a LabVIEW DLL from that VI and export it as a C function (watch out for the function prototype to be exactly like what the callback needs to be). However that has also its own problems. Unless the LabVIEW version calling (indirectly through .Net) this DLL function is exactly the same than the LabVIEw version used to create that DLL, the VI will execute in the LabVIEW runtime version that was used to create it and hence be a seperate process. This means there is no possibility to share LabVIEW data between your caller and the DLL directly since memory pointers, refnums and just about anything else have no meaning in the other. The same would apply if your .Net component would execute out of process since it would invoke the C callback pointer in its own process that would instantiate the according LabVIEW runtime. The real question is why do you have this C .Net wrapper? If you would go directly to the .Net component and it would use .Net events for this asynchonrous notification the problem would be solved if you use LabVIEW version 8.0 or higher. There you can let LabVIEW handle .Net events directly by assigining it a callback VI that will be executed on occurrence of the event. This whole .Net C wrapper makes everything unnecessarily complicated for you. Rolf Kalbermatter PS: If you can go with something more recent than LabVIEW 8.0 because of two reasons: 1) LabVIEW 8.0 had quite a bit of quirks in many areas. I have found LabVIEW 8.2.1 to be a lot more stable and reliable but 8.5(.1) or 8.6(.1) should work just as well. 2) .Net events were new in 8.0. So I would expect them to have one or two quirks that you might run into in that version that might have gotten fixed later.

QUOTE (mesmith @ Mar 18 2009, 08:50 AM) No it is not exactly as you seem to think. Lets take your example: The proxy address is usually in the form of "myproxy.mysite.net:8080" since it seldom uses the standard HTTP port of 80. So you parse that address into the DNS name (everything up to the colon) and the port number, using 80 if there is no port number. Now pass this information to TCP Open. Then you have a HTTP Request of the form "GET /index.html HTTP/1.1". Since the Proxy must know to what server to forward the HTTP request you have to modify this by prepending the server address to the absolute path of the resource. So the command to send to the proxy will be "GET http:/www.google.com/index.html HTTP/1.1". That's all. Rolf Kalbermatter

QUOTE (neBulus @ Mar 17 2009, 02:31 PM) I do not have any exact numbers but it is probably quite a fast fix indeed. In earlier days (LabVIEW 3 and so) patch fix releases where actually a lot more frequent with the f number sometimes approaching two digits. So there might have been some that were actually released as fix before anyone extern to NI might even have noticed them. However I do think they should make it somehow possible to release such fixes more frequently and allow an easy installation. A lot of LabVIEW is nowadays not in the actual binary executable anymore but in external VI files, although mostly password protected, so it is often a matter of replacing one or two VI files in a LabVIEW installation as was with this particular bug. That could be easily made more frequent since the test scope of such a modification is rather limited. For changes that get into larger components like the LabVIEW executable itself I do understand that the testing before releasing is a major pain and they probably never will go to release such fixes in lets say a monthly interval. If those VI based tool would not be password protected we might fix them ourselves and make them available but as it stands now we have to rely on NI to do that for us. Rolf Kalbermatter