Rolf Kalbermatter

Not sure if it serves your karma well, to try to get him to pest other boards . But I've added an alfa filter to my perception already so not sure what you are replying to exactly. Rolf Kalbermatter

LabVIEW is highly parallel in execution. Unless you do not provide data dependency the execution order of code is totally random. In your case this means that the Read function can execute before the Write function is executed. In that case you never will be able to read the value you just wrote! Another problem is probably the amount of data you read with the count character! You typecast an int32 which will result in 4 characters being written and then you should read 4 characters too. Last but not least the serial port settings will terminate by default on carriage return on read. Since you are writing binary data the decimal 13 character can happen anywhere in the data stream and the default setting will sometimes terminate on that character on Read instead of returning all 4 characters. Rolf Kalbermatter

Not that fish & chips is considered top notch culinarian in the rest of Europe And the few times I've been to England and tried it anyhow to test if it was still true, I never was very much impressed by it. To soft and tangy chips! I mean it is usually eatable but not something I would make a trip for. For that I would need something lake Clam Chowder and of course in San Francisco Or should that be some delicius fish meal in Cairns? Of course the French and Italian cuisine is never to be forgotten and nice tasty spare rips in Austin are also great. Rolf Kalbermatter

Having done some work in Wine and knowing the structure of the Wine code a bit I have to say that having a full source installation of said has helped me quite a bit. Not necessarily easy to find a particular function if you do not know where to look for but about how to achieve a lot of things. Wine code is usually good structured and rather high quality so learning from there is definitely not a bad thing. Rolf Kalbermatter

It's not so much that I wouldn't think NI may like to do that, than that I don't think they would even dare to try Back when I was there they probably wouldn't even have thought about it, or at least if someone thougt it he never would have spoken it out, yes. Nowadays they are so big they have to watch a bit what they are doing, otherwise they may get hit on their fingers for being a naughty boy. Rolf Kalbermatter

Ouch , that is worse than eternal hell! Rolf Kalbermatter

1.7.1 is an old version of NI-Serial. That software however is only used when you have specifically installed serial boards from National Instruments. It is NOT NI-VISA but provides the drivers for the NI serial boards to be visible in Windows at all. NI-VISA sits on top of the Windows Comm API and is necessary to access any serial port (not just on the NI boards) from within LabVIEW. Rolf Kalbermatter

If you know the function name such as in this case it is very simple. OTherwise it is indeed hard to find something because of the sheer amount of information on that site. I little to borad of a term and you end up with thousends of links and usually some rather obscure ones (at least for people mainly interested in Win32 API) on the top. For browsing more lasurely in the Win32 API an installation of the Microsoft SDK is quite handy. It is not talking about every possible MS soft but concentrates on the Windows API and family. Rolf Kalbermatter Actually Win95,98,2000 are usually on the same page if it is about Win32 API, or lets better say it sometimes still states that certain functions are available in older Windows versions. Microsoft is slowly getting mentioning of old and unsupported OS versions out of the docs when revisiting such said docs. What I usually end up finding when looking for a particular API are the function descriptions of the Windows CE APIs in tenfold on the top of the found links before I sometimes get the link to the REAL API. Rolf Kalbermatter

I have been upgrading to 8.0.1 about three weeks ago and haven't noticed anything strange in LabVIEW 8 yet. The mass compile did take about 3 hours despite Jim's accelarted tool, but that is probably the price for having a Centrino notbook with a 1.6 GHz Mobile Pentium. Considering that after more than one year I still can work almost 4 hours offline on one battery I guess that is not to bad. Rolf Kalbermatter

I wouldn't really know and if it was me I wouldn't probably discuss it. It can be harsh to feel censored but discussing this on some unrelated place does usually not help. Rolf Kalbermatter

I have to admit that my first reaction when reading this post was, shit this can't be! But above mentioned statement about deleting any posts about deficiencies in LabVIEW 8 made me lough and check for the date of the post Still I think it is quite a good April fools joke and without that statement about deficiencies I could have probably went through the entire post and still believed it at the end. NI having total control of the Developer Forums can remove any post they feel is not appropriate and they do sometimes do this not just for totally out of context posts or spam but also some posts about things NI does not feel the general user group should know about. I think I'm missing a post or two as well somewhere on those forums. Well, maybe it just got accidentially lost when porting the forums over from one software to another. The last porting two years or so ago, made searching in older posts really sometimes impossible. Rolf Kalbermatter

As a former AE (in a long ago life) I can really relate to his feelings ;-) But I was considering checking out labviewforum.de once, but your comment makes this sound like an utterly painful experience. Rolf Kalbermatter I think the problem with your project duplicator is more one of many advanced LabVIEW users not really having made the jump to 8.0 already. I for one still do most of my work in 7.1 and even sometiems 7.0 as there are projects that need simple modifications that do not justify the hassle of upgrading (and veryfying every aspect of the application to still work perfectly). Just starting to work in 8.0 for the first time for real for a project and in fact only because the client has a .Net library he developed himself which uses .Net events. Otherwise I would most probably have used 7.1 too for this project. The whole project management in 8.0 is a really big change of work procedure and might be fine if you start with LabVIEW but can be a little bit of intimidating if you have managed to work with LabVIEW since version 2.2.1 without this goodie. Rolf Kalbermatter

The 3D control is Active X but the 3D Picture Control is an extension to the well known Picture Control implementing some 3D object drawings, using the OpenGL extension LabVIEW has been linking to for several versions now to implement their new (and IMO ugly) 3D control style. The extension to the Picture control is really available since 7.0 but NI only released a Beta-Test Toolkit to make use of it with LabVIEW 7.1 and being marked as a Toolkit LabVIEW 7.1 refuses to safe it back to 7.0 As to 3D programming in LabVIEW I'm afraid I won't benefit much of such a feature. My left eye is basically lame so all those 3D hypes in the past were leaving me with some curiosity as to how 3D visisbility would really look like. Rolf Kalbermatter

Does your server handle multiple incoming connection requests simultansously? If not it may be not able to get into the listen queue before the timeout occurres. Or one of the sockets either on the client or server sides is not disposing closed IP ports properly so that the socket library runs out of port numbers after a while. 4 second interval would result in about 1000 connections per hour and therefore 1000 used up port numbers so this might be a possible explanation. You could try to log the used port number of your client (and server) and if it keeps increasing instead of reusing the same few port numbers then you might have a problem of not properly closed TCP/IP ports. Could it be that your TCP Close function gets wired with an error cluster indicating an error which might prevent the close from completely closing the port. I know Close functions are supposed to close independant of the error in status, but I know that some functions in the past didn't do that always. Another issue I had sometimes with similar symptoms was when using DHCP. There I have to say that what I did was actually keep connections open for a longer period of time and if the IP address of one of the sides changed during that the connection just went into nirvana. Writing to it did nor produce an error nor get the data arrived at the other side, which also still believed it had a connection open. Closing/reopening connections solved that problem more or less but changing to static IPs was what made it really reliable. Rolf Kalbermatter

LabVIEW (and Windows 95 and higher) being a 32bit application you only can use 32bit compiled DLLs. That means that int is really a 32bit integer. Configuring the Call Library Node to use int16 instead will create some serious problems. For the skalars you won't see crash but just some strange and truncated values. For the array this certainly will cause serious trouble including invalid pointer accesses and crashes since the memory area you are telling LabVIEW to pass in will be only half as large as the DLL thinks it should fill in. Also I hope you make sure that the two arrays are preallocated in LabVIEW to the necessary size. In calling DLLs the caller is ALWAYS supposed to allocate memory for the DLL funcitons to fill in their result. For your case this would mean that you have to allocate two arrays of 10 * 10 elements to pass in. Another issue is the use of two dimensional C arrays. This is an area in C where the specification is not always very clear. A C compiler usually will create an array of n * x elements and internally treat it as one dimensional array which happens to be the same way as LabVIEW looks at multidimensional arrays. But it also can sometimes mean that you have an array of pointers each pointing to a different array of elements (which is not very simple to create in LabVIEW at all). Of course doing Matrix multiplication entirely in LabVIEW is another solution, if done right not really slower than doing it in C too. And LabVIEW 8 has additional support for Matrix operations. Rolf Kalbermatter

The description you are mentionening seems to be for Visual C 6.0. For Visual C 2003 or similar you will have to replace some of the keywords in $(keyword) with something else that has changed between Visual C. Sorry can't help you here as I'm still using Visual C 6 and for that matter when creating a CIN, which by the way is considered legacy technology and therefore not recommended for new designs, I'm using the nmake command on the command line instead. That whole Visual C IDE business for creating CINS seems simply overkill and to much hassle to me. If you are trying to develop something new I would recommend you to abandone the CIN route althogether and go with DLLs/shared libraries instead and link them into LabVIEW through the Call Library Node. CIN support is probably not going away soon in existing LabVIEW platforms but support for new and upcoming LabVIEW platforms (Win 64bit, MacOS Intel, etc) is likely to be non existent). Rolf Kalbermatter

But it is the case! The Windows extended properties for a window determine if the window will have a taskbar button or not. And I do not see why you couldn't make this test yourself. It is really simple and asking for a ready made example sounds a little like a HH (homwork hustler). Rolf Kalbermatter

Just try "LabVIEW" as library name. It might work in the built application but there is no guarantee. The special LabVIEW library name was introduced in probably around 5.0. Not sure if LabVIEW was already using it as a place holder for the current instance or if that was only added later on. There is probably quite a lot more than a single Windows API call behind SetDefaultPrinter. Printing in LabVIEW is somewhat involved and the original idea was to hide as much as possible of the printer setup and configuration from the user. This makes it now a little difficult to provide full print control. And the reason this name was changed in later versions is probably because it had a name clash on one of the platforms LabVIEW is compiled for. Rolf Kalbermatter

As the original author of the OpenG Pipe source code I can only say that the code as present now is still an alpha work in progress. I haven't found much time to go deeper into it and just got it so far to work somehow under Windows although there needs to be done more testing and also the Linux and MacOS parts would be nice to have. What might be the problem with LabVIEW 8 I have really no idea. Pipes under Windows at least are a somewhat fragile technology with lots of possible problems and it is very well possible that LabVIEW 8.0 does something with the Command Line Console for its own internal dirty work that might conflict with trying to redirect standard IO to pipes. I haven't currently any time to dig deeper into this so anyone with some C programming knowledge feel free to investigate what might be the problem. The code comes with the source code for a simple command line executable that can act as loopback device so it is definitely a good idea to try to make the DLL work with that example under LabVIEW 8 first. If this works but not with PErl then it is likely that Perl does some weird stuff too that clashes somehow with LabVIEW 8. Rolf Kalbermatter

Could be. Or if they are VIs from the LabVIEW DSC system or similar toolkits it could be the system flag for those VIs that also excludes them from being visible in the VI hierarchy and in eneral any search of any kind. Rolf Kalbermatter

Controls are entirely different objects than Nodes. I don't think you have any more distinguishable properties for controls than the Class Name itself. Rolf Kalbermatter

But it's truth. The big performance problem is not in thread switching here (thread switching while costly isn't usually where things go completely bad) but it is in copying the data. In order for the data flow paradigma to work without race conditions LabVIEW needs to make a copy of the data whenever a global or local is read. This is no problem for scalars but some people like to store x MB arrays in a global and read it every second to append a new subset to it and write it back. This is about the worst scenario you can think of in using globals. Thread switching however does occur when using the Value property since properties are executed in the UI context. So here in addition to possible performance loss because of data copy the additional two context switches will further increase the performance problem. Rolf Kalbermatter

Unfortunatly Lithium batteries have this characteristic that they will age independant of their useage. While it does probably make a difference if you use your computer often, unlike the well known problem of older battery technologies where not discharging a battery completely would considerably detoriate on the life time of the battery, Lithium batteries suffer from a general aging process that is mostly independant of their use. This means that such a battery stored for 2 years somewhere won't be much better than one that has been used for 2 years on a daily base. This is a general rule which has been described in several places. Of course there are differences. Some batteries will be absolutely useless after two years while others seem to be able to handle aging better. My former Dell had first a battery that was completely gone after less than a year (and I got a replacement under warrenty for it) The second battery which was used just as much did last 2 years and still was fairly well. My current Sony VAIO is about one year old and still going strong with somewhere around 3 hours of power outlet independant operation. But from what I have read so far it seems safe to expect that Lithium batteries usually won't last longer than about 3 years even if not used. I believe there have been recently new technologies introduced that should make the manufactering of Lithium batteries both cheaper and increase their life cycle too. Rolf Kalbermatter