Rolf Kalbermatter

QUOTE(Jim Kring @ May 15 2007, 04:50 PM) It is but it contains almost nothing in comparison to earlier versions. This is with VISA 4.1 and MAX 4.2. Rolf Kalbermatter

QUOTE(george seifert @ May 3 2007, 01:02 PM) It's a kernel driver issue in combination with your PC hardware or more properly your BIOS. I've seen HP BIOSes creating strange things lately a few times. A few months back I tried to install a PCI-1407 card in a HP PC and decided to also install the greatest and newest NI-IMAQ with it. The card simply didn't work. It showed up in the device manager but with an exclamation mark and indicating an error 10 had occured. While dealing with NI support about that I happened to try an older NI-IMAQ that I had from an old setup (Ver 2.5.1 or so) in comparison to Ver 3.6 and everything worked alright. Later that day I got a message from NI that the issue was known and could be resolved by downloading and installing a new BIOS for the HP computer according to this http://digital.ni.com/public.nsf/websearch/F69AB8D3B7C0261F8625723E007205FF?OpenDocument' target="_blank">Knowledge Base Article. I didn't go through the hassle of installing a new BIOS since it now worked and also because I was at a customer site with firewalled internet access and optaining the BIOS would have been problematic. Rolf Kalbermatter

QUOTE(zampala @ May 1 2007, 04:46 AM) Have you checked that NI-488 drivers for Linux support your GPIB interface? While the actual register interface is very common for all NI GPIB interfaces, the actual connection to it (PCI, ENET, USB etc needs to be specifically supported by the NI-488 driver for this to ever work. I would guess that NI-488 for Linux does not support all possible GPIB interface busses yet or maybe there is a newer release that does. Check out the NI site for this. Rolf Kalbermatter

QUOTE(Bryan @ Apr 20 2007, 07:12 AM) With >1GB USB sticks getting very common why not install an image of an OS with LabVIEW installation on them. If they can boot from there you should be able to do so too. Just need a stick that supports booting from. And then it should be quite simple to create as many of those sticks as you might need to get to test all machines in parallel. Not completely free but USB sticks don't cost that much anymore. You could even go with a smaller stick for DSL I think although not sure what are the smallest that support booting up. Alternatively you could use such a stick to boot up the system into a minimal configuration that connects to the network and downloads everything else necessary to the local RAM disk. Rolf Kalbermatter

QUOTE(Aitor Solar @ Apr 23 2007, 07:35 AM) OpenG has a VI that does this all in G. Works quite well and much less likely to create crashes :-) Please not that this VI does just what it is asked. Meaning if you ask it to get a certain page that has a redirection it will do so which will only return a short status message and some redirection code which you need to parse and use to get the real page. Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ Apr 22 2007, 05:59 PM) LabVIEW 3000 with AI and mind reader interface. It just reads the developers mind and creates everything as it finds it there. The AI is necessary to overcome fuzzy, non-existing and wrong knowledge about what the developer thinks she/he needs. Rolf Kalbermatter

QUOTE(Beri @ May 8 2007, 09:17 AM) Come on! Of course it is and it is a rather trivial exercise to write a VI that takes a byte array and formats it into a hex string. Not that I will do your housework but with a bit of thinking this should be doable in less than half an hour and if you add a bit more you can even spend time for optimizing it. Considering that you want to write something like a network analyzer I simply can't believe that you can not come up with such a VI yourself. Rolf Kalbermatter

QUOTE(Karlos @ Apr 23 2007, 04:32 PM) What version of LabVIEW? The always on top is called floating and is something that has changed about from 7.x to 8.x. If you use 8.2 then it is simply a property of the VI Frontpanel class, called "Behaviour" and one of its values is Floating or Floating w/ Autom-Hide. By removing the menu you should be able to disable the menu short cuts at runtime. Rolf Kalbermatter

QUOTE(BrokenArrow @ May 14 2007, 08:09 PM) I just checked in a 5.1 installation and yes it is not set reentrant. The write in itself may not be a big problem I would expect more trouble with the read in fact. Your boss probably will be in your neck again next time production tells him this application is not working and they can't meet the target with such an ugly beast. Then you should tell him to either reserve time for a proper redesign or at least a through clean up (I would at least expect a few weeks of work) or forget it as that application is simply unmaintainable and never can be made to work reliably without that. Rolf Kalbermatter

QUOTE(crelf @ May 4 2007, 09:46 AM) I've used a few times Inno Setup and was quite satisfied with it. For simple installations it is really easy to create a setup script and if you want to go further you can add real code based on a Pascal like syntax but that is really only necessary for your own specifc dialog templates or custom installation steps involving Windows API calls. And it is free too and often used by Open Source projects for their Windows installer. Rolf Kalbermatter

QUOTE(BrokenArrow @ May 7 2007, 10:53 AM) Ohhh my god! My current projects are around 800 Vis easily, contain probably less than 20 globals, and also less than that in sequences (most of them being single frame sequences to enforce some dataflow dependency). Your problem is likely some serial port timing. If you have VIs that do some waiting inside and use that same VI for something else that something else won't be able to run before the first operation has stopped. However I thought the Serial Port Write.vi you mention was set to be reentrant so that should not be a problem. If it isn't making a copy with your own name and setting it to be reentrant will save you some time since you won't need to create individual VIs for each place. A reentrant VI really executes the same when used in multiple places like the same amount of individually named copies of that VI. The drawback of reentrant VIs is that you can not debug them well before LabVIEW 8 and basically not at all before LabVIEW 7. Rolf Kalbermatter

QUOTE(bbean @ May 13 2007, 08:17 PM) Well you gave yourself in fact the answer already. The solution is to upgrade since it works in LabVIEW 8.2. It is likely a problem in Active X callback event handling inside LabVIEW, where you can do little short from rewriting the ActiveX component, which I assume is no option here either. NI does usually not release bug fixes to older LabVIEW systems once a new version is released (unless you own >500 licenses and therefore have a certain direct influence on the NI decision making). Rolf Kalbermatter

QUOTE(BrokenArrow @ Apr 29 2007, 08:45 AM) No certainly not! By using property nodes to set that value of controls in abandunce you will likely create a program that feels very sluggish. For just one time intialization of the front panel this would probably be not to bad but it is very likely that once you start to use value properties intensely you use it all over the place and if you do that in a generic update state of your UI state machine it can already get bad. If you do that in a subVI through a control reference that is called all over the place in your program, you can probably sell a coffee machine too with your program so that your user can do something while waiting for the UI to update after each mouse click :-) Rolf Kalbermatter

QUOTE(Tomi Maila @ Apr 19 2007, 12:54 PM) You could send the VI to Jim directly (or myself) and ask him to add it on your behalf. He (and me) will maintain your copyright notice. Or you get an account at sourceforge.net and ask Jim to have you added as developer to the OpenG Toolkit project. This will give you commit rights to the libraries but obviously this is not something you and everyone else would want to be granted to just about everybody. Once you start to commit your own VIs to the libraries there are a number of things to watch out although adding to existing libraries is really quite trivial. I usually leave the task of generating a package to be distributed to Jim for instance when he feels alright with it. Rolf Kalbermatter

QUOTE(crelf @ Apr 21 2007, 05:08 PM) You can also read the first post in a row of posts to come about LabVIEW external code at http://expressionflow.com/external-code-in-labview-part1-historical-overview/' target="_blank">http://expressionflow.com/external-code-in...rical-overview/ to get an idea about what CINs and CLNs are about, why they exist and why you should use CLNs instead of CINs nowadays. Rolf Kalbermatter

QUOTE(Pablo Bleyer @ Apr 18 2007, 03:12 PM) Your CIN likely makes use of some external functions located in a DLL. This could be a C runtime library or some non-standard Windows or third-party DLL. In the first case you can either make sure the runtime library installer for your development environment has been run on each computer you want to run your LAbVIEW program on or define in the CIN project to link with a statical C runtime library instead of a dynamical one to prevent problems on plattforms your compiler or depending tools hasn't been installed (this will make your CIN code resource considerably larger). In the second case you will have to find the non-standard Windows or third-party DLL you are calling and find a MS or other installer that will install it and make sure you tell any user to also install that package too. A CIN LSB is in fact a DLL too and a DLL that references other DLLs that can not be found by Windows will be refused to be loaded by Windows, leaving LabVIEW with no LSB to link into the VI. Rolf Kalbermatter

QUOTE(Pablo Bleyer @ Apr 16 2007, 01:56 AM) The problem is not that the variant does not know what datatype it contains but the fact that LabVIEW is very strictly typed. And that is why there is a difference between a strict typedefed control reference and a non-strict one. These are decisions that are made at compile time and if the datatype of something can possibly change at runtime somehow then the only solution in LabVIEW to still be able to access that datatype at runtime are variants. If you make the refnum strict that is not necessary and if the refnum is non-strict it is necessary, otherwise LabVIEW could in no way allow you to access the Value property at all. To change that would require to change the entire LabVIEW system to be weak typed but weak-typing has other disadvantages one of them being that a datatype is usually always of some kind of variant type and the necessary (and usually quite time consuming) conversions are always done at runtime. Strict typing has the advantage that most type conversions can be done at compile time resulting in significantly improved performance at runtime. Other disadvantages of weak typing are the possible loss of information when converting multiple times between different types, or the fact that certain type conversions are simply not useful but you only see that at runtime instead of at compile time. Rolf Kalbermatter

QUOTE(Jim Kring @ Apr 14 2007, 09:43 AM) Hmm, I tried that and it failed to install Tourtoise. Also that installer does nothing to install svnserve as a service in Windows, which is the main point in my post. Rolf Kalbermatter

QUOTE(Gavin Burnell @ Mar 29 2007, 04:37 PM) Actually some well known NI person here stated once that he would rather like to make those castings impossible at all and has done so in the past for some areas as it is a very hacky way of sending LabVIEW into some crash course. There seems to be some extra security checks that when you try to access a typecasted property that doesn't exist for the actual object in question gives you an error message but he stated that this security check while there, is anything but fool proof. Rolf Kalbermatter

QUOTE(dannyt @ Mar 5 2007, 04:00 AM) I personally feal these two issues are non-issues. If you distribute your program as an executable the source code is gone anyhow. So the additional security of not having the VI names as strings appear in the executable is really a minor thing. You can get the same by name mangling your VI names when building your executable. Performance is for all of my applications not in the subVI call overhead (most projects I develop or maintain currently have between 600 and 1000 VIs) but in the limited user reaction :-) or the limited reaction time of the external hardware systems I need to control. Also when I do calculations I do make sure to use inplaceness and preallocated arrays as much as possible together with shift registers and auto indexing. All these things allowed me to get performances for almost any algorithme, that was close to what you could get with normal C code without dirty optimization tricks and often is faster than many C routines I did find on the net to do the same (and obviously could be optimized by cleaning them up and use more proper functions or implementations). QUOTE Finally if instead of releasing an executable you release the actual project, I suspect this would not be the way to go. Obviously not. Because in the project you distribute the original source code, so at least the security concern would not play at all. Rolf Kalbermatter

QUOTE(sam @ Apr 13 2007, 11:42 PM) LabVIEW 32bit will run. If and when there is a LabVIEW 64bit is a top secret. It seems impossible to get anyone from NI to comment about that in any way and I doubt you want to resolve to illegal methods to get some NI person at gun point to tell you about that. Hardware support for Win64 is basically non existent for the moment. Rolf Kalbermatter

QUOTE(Jim Kring @ Apr 12 2007, 11:07 AM) This is a great way using the local file protocol that SubVersion supports. However as of SubVersion 1.4 and higher you also have the option to setup an SVN server as service under Windows, which makes it startup and run automatically without even a user needing to be logged in. It does require a small amount of command line typing but is not really difficult at all. You just need to get the binary package of SubVersion for Windows and do the attached steps. Rolf Kalbermatter

QUOTE(alukindo @ Apr 13 2007, 11:28 PM) You can disable DST in your OS. Other than that LabVIEW won't do anything different than what it does now since it uses OS functions to deal with date/time. Before LabVIEW 7.0 it always used the current DST status to convert date/time. From LabVIEW 7.0 on it uses the actual DST status that belongs to the actual timestamp for all timestamp on and after Jan. 1, 1970. There is however one limit to this that was uncovered with the recent DST change in the US. Windows only can have one DST period per timezone and that applies to all years. So there will be a two week period when DST calculation is off now for all years before this one in the US. Microsoft stated that they fix that in VISTA but have no intention to fix that for earlier Windows versions. In LabVIEW 8 and above some of the Date/Time functions have an extra boolean input that allows you to treat the data/time in UTC. Rolf Kalbermatter

QUOTE(gleichman @ Apr 12 2007, 02:47 PM) This is absolutly right. There is no problem per se with calling VIs anywhere on the disk even in an executable. There are however some restrictions as to what such VIs need to conform too. 1) For the runtime system the VIs should have been compiled in the same LabVIEW version (bugfix version number differences are normally ok) and for the same platform. 2) You need to construct the path to those VIs exactly in order to be able to call/load them. 3) If they make use of SubVIs those subVIs MAY NOT clash in any way with subVIs that are used in the main executable already. Either you make sure they use a completely different hierarchy of subVIs (name prefixing for instance or LabVIEW names spaces in >= 8.0) or you make sure those subVIs are all exactly the same for the plugins as for the main executable. Number 2 is the first stumble block most people fall over. And once they figure that out they immediately run into 3, which can only be solved with a strong discipline while developping. I usually do that by having a Top Level VI which includes all Top level VIs of my project including the plugins and make sure to recompile the entire project before making a distribution of the executable and/or plugin component. Rolf Kalbermatter

QUOTE(AdamRofer @ Apr 12 2007, 12:14 PM) Well it's a great way. And using the VI's from the large_file OpenG library would be also possible. Basically by wrapping the returned handle from CreateFile into a LabVIEW bytestream file refnum you could use the standard WriteFile primitive and CloseFile primitive. Of course this has a subtle chance of breaking in future LabVIEW versions but it is using all documented External Code Reference functions and should therefore remain working for quite some time. My prior approach does have one advantage of being able to print text to any Windows printer that can represent a bitmap device (that would exclude plotters for instance but I'm not sure Win32 still supports them at all. Win3.1 GDI did however.) It is to bad that FMOpen() seems to test the first path element to be only one character, otherwise no DLL call would be probably necessary at all under Windows. Rolf Kalbermatter