Rolf Kalbermatter

Hi Didier Congratulations too, from a fellow-countryman living in the "low lands" of Europe. Will be an interesting addition to your family and make sure you and your wife keep busy Rolf Kalbermatter

I haven't checked into this issue specifically but as yen says it's most probably related to how LabVIEW accounts for day ligt saving time correction of timestamps. Traditionally LabVIEW has always used the current times dayligth saving time to convert from its internal UTC timestamp to local time and vice versa. In LabVIEW 7.0 they introduced the ability to account for the DST status of the actual timestamp. For certain reasons that have not been confirmed by an insider to me, they decided however to keep the old behaviour for timestamps before January 1, 1970. There are two possible reasons I can think of (and they may be actually both true): 1) The OS support for determining if a certain timestamp is DST or not is not (on all LabVIEW platforms?) available for timestamps prior to that date. In order to keep LabVIEW consistent across platforms this behaviour has been chosen. 2) For backwards compatibility! Some Toolkits (Internet Toolkit for instance) use the conversion of 24 * 3600 seconds into a date to determine the current timezonde offset including DST status eventhough that timestamp is of course January 2, 1904 and therefore never could have DST. Rolf Kalbermatter

I admit it is a sentiment, but it also has practical reasons. Copy protection has come in my way a few times when using legit software. If the copy protection decides to strike its bad day when you are close to a deadline you really are close to destroying company property by seeing how long it takes to fly from the second floor until it hits the pavement Rolf Kalbermatter

Damn, I have completely missed this label! Makes my OS style user interfaces finally look perfect. Rolf Kalbermatter

Also they need to use on both/all platforms the C decl calling convention. This is the only one that is supported on all platforms LabVIEW is available on. Sadly most 3rd party DLLs on Windows use Microsofts stdcall and then you will have to maintain two VI libraries anyhow. If I write DLLs I always make sure they use cdecl. This has worked great for the OpenG LabVIEW ZIP Tools library which has one VI library and three shared libraries for the three OSes, Windows, Linux and Mac OSX. Rolf Kalbermatter

You are not very specific. With Intel based do you mean some Pentium CPU board or an Intel ARM CPU? In the first case you would just install normal LabVIEW. I have looked into the Embedded developer module but haven't found time to really do anything with it yet. It definitely is not just doing one day of work to support a new target. Even if you can use an existing target and adapt it to your new one (depends of course both on the CPU as on the actual OS you will use) can you expect to spend at least a week or more before you get your first VIs properly downloaded and running. For an entirely new target I would guess this can take easily months depending on your familiarity with the actual tool chain you need to use for that target. Rolf Kalbermatter

Hmm, I haven't seen free software that uses copy protection. :-) Not sure that means anything though! If I have the choice between a software that uses copy protection and one that doesn't I would almost always choose the one without, independant if it is free or not. The only thing I hate more than copy protected software is software that has spyware or other similar things in it. Rolf Kalbermatter

So you want to send a keystroke to another application by placing it in the keyboard queue and honestly believe that you have any change to switch to the other application after having started the VI? Because keystrokes are only sent to the active application! I would recommend to try this on a mechanical computer but with any modern computer your VI has already long terminated before you can even think about switching to another application, lets forget about moving your hand to the mouse and activate that other application. Rolf Kalbermatter

Apart from some more or less well written VIs to access specific USB and similar keys I'm not aware of much in this direction. The problem as I see it is how much do you want to spend to protect your software? Usually LabVIEW is not used for high volume applications (it's runtime licensing while quite liberal nowadays does not always lend itself well for this) and therefore a license protection that costs days and weeks of development time is not likely to recover its own costs. And license management is a trade of its own with most of what is on the markt nowadays being more of a solution to fend of the casual copier than a way to really dwart the determined hacker. And lets be honest, the only fool proof copy protection is to lock up your software in a safe, destroy any backup copies and throw away the key to the safe So what is it you want to prevent and how much is it worth to you? If it is about not allowing to run your software by people that would anyhow never buy your software, then honestly every single dollar spent into copy protection is simply lost money. If it is about the fun to have copy protection built into your application, it's the same. Only if you can make a valid case that software will be bought thanks to copy protection can you start to look into spending money for this if you want to think commercial. As for me I'm much more likely to buy a LabVIEW add-on toolkit with a honest price that uses no copy protection than using an overpriced toolkit illegally at all. And a copy protected software always gets 10 minus points in my opinion if I have to evaluate such software. I may still buy it but then it needs to be a LOT better than its competition. Rolf Kalbermatter

Data acqusition is not just hardware. The data needs to be transfered by a kernel driver into some intermediate buffer and from there into the application buffer. At least the last operation will be executed in the context of an application thread and can contain scaling (DAQmx channels) and other things too. So there is certainly something a core could be doing eventhough it is for a large part IO/memory related and therefore not the best candidate to be parallelized with multiple cores or CPUs unless you would have separate memory busses too. LabVIEW will not control the cores directly but instead use OS threads. How the OS distributes threads onto multiple cores is almost completely out of control of LabVIEW and can actually be tweaked by a power user. So while multiple independant loops will allow LabVIEW to distribute each loop to a differnt thread it is usually very counterproductive to start distributing related code to multiple threads especially if data flow commands a certain execution order. Instead of just continuing execution of a logical dta flow LabVIEW has to suspend a thread and wait for the correct thread to be activated by the OS to continue the logical data flow. In addition to the costly execution context switch you are forcing onto a logical data flow, you incure additional delays since the OS might decide to activate a different thread first than the one that would suit the dataflow best. However if you have a single loop with subVIs you could assign different execution systems to these subVIs and LabVIEW would be forced in that way to use a different thread. But please note that this will only really have any positive effect if you happen to have two different subVIs in the same loop that do both a computationally expensive operation. Without subVIs parallelisme in LabVIEW is limited. All built in nodes that do not have some kind of wait or timeout function are exectued synchronously and in the same thread as the diagram they are contained in since their typical execution time is quite small in comparison to the context switch overhead to let the OS switch between multiple threads. Most LabVIEW applications I write have anything from 2 to 6 or more parallel loops in the main diagram although sometimes some or all of the loops are located in specific subVIs that are called by the main VI once and terminate automatically all when the application wants to shutdown. This has never given me bad surprises (provided you do a proper design before you start with the actual coding) but results in applications that do DAQ, Analysis, logging, test sequence execution, image acquisition and instrument control all in parallel and still have an utterly responsive user interface. Rolf Kalbermatter

But it is already part of the save routine! That is why you get those error dialogs when saving VIs. And sometimes recompiling (shift-run tool) the VI helps but often deleting the offending object is the only course. I haven't seen it often since about LabVIEW 6.1 but can't really comment to much about LabVIEW 8.0.x. It's possible that LabVIEW 8 introduced new ways to create insane objects. Rolf Kalbermatter

All these things point actually in the same direction: You have somewhere in your COMPLEX UI VI some code that resets these properties. It might be a aproperty node that you added at some point, then resized the Event structure or some case, so that it fell of into invisible area. Or some execution logic in your state machine that causes this at initilisation. I've been there and done that too and almost pulled my hair over it before I realized my own fault. For invisible elements try to open the Error Window under Window->Show Error List and check the show warnings check box. Then go to the VI in question and hit de wanring triangle besides the run button. If it's about the executiona logic of your VI you probably will need to single step or at least work through your intialisation logic with breakpoints until you see where exactly the property gets reset. Rolf Kalbermatter

As a reference (it's actually mentioned in the online manuals too somewhere) a single precsion number can be only accurate to about 7 significant digits while a double precision number can be accurate to about 15 significant digits. Rolf Kalbermatter

Then read the entire MSDN article pointed to in the previous post! It mentions that GetCursor is only for the applciation cursor while there is a GetCursorInfo or similar function that will give you the global cursor (at least if you are not using an archeological Windows version). Rolf Kalbermatter

I think there are such VIs on the NI site. Try to locate them there. I haven't used them but a collegue got them in the past. They were limited in the data types supported but adding new datatypes didn't seem to difficult with a little digging. Rolf Kalbermatter

I don't think LabVIEW will add support for modyfying it's toolbar anytime soon. But with the new splitter pane you can create your own very nice toolbars in LabVIEW 8 quite easily. Rolf Kalbermatter

Wow LabVIEW contains actually a reverse compiler . Now everyone that saves his VIs with password or no diagram at all is simply buggered ;-) Hmm, not sure how that differs from the first really. Still needs a reverse compiler and I just so much like this new extraSuperSecretTool. Naaa! This last one is to simple. It can't possibly be this! ;-) Rolf Kalbermatter

The latest news I heard are the same. NI seems to have dropped the idea to think about how to commercialise the Cubix platform. So it's a nice idea but it will probably never be sold in that form. Maybe an opportunity for a third party. With the LabVIEW Embedded Developer platform this would be very feasable, although I wonder about the commercial benefit of such, if even NI doesn't sees a chance to make it a profitable thing. Rolf Kalbermatter

This is only really true for modern hubs. Older dual-mode hubs frequently had trouble to auto negotiate the correct speed and/or handshaking too. Rolf Kalbermatter

Changing the global cursor is not such a simple exercise. Basically Windows maintains a cursor state for each application and changes it accordingly whenever the cursor changes into a screen area owned by a different application. And in the case of LabVIEW it gets rather nasty for the application cursor. LabVIEW has the habit of resetting the cursor frequently to what it thinks it should be. But if you use LabVIEW 8 then you have already functions in the palatte to change the cursor state for at least LabVIEW. To change the global cursor consistently I'm afraid you would end up having to write some hook function again. Rolf Kalbermatter

Maybe that would be a chance to learn C? It's still THE engineering programming language and won't go away anywhere soon. Having some knowledge about C programming will always be an added bonus in almost any engineering profession where you even remotely need to get your hands on a computer. I'm not volunteering to write this thing for you, sorry. It's going to be a time consuming exercise in any case and to get it work exactly as you envision it will probably get a hard exercise for someone else than yourself. Rolf Kalbermatter

Maybe not Most of people at the NI marketing department used to be female back when I was in Austin some 14 years ago, and they were very nice folk to be with . Not sure if that has significantly changed. Rolf Kalbermatter

The file IO APIs the Large File package uses are standard Windows 32bit APIs. The only reason this might not work is that the underlying RT OS and its WinAPI implementation does not support files bigger than 2GB at all. If that's the case there is absolutely nothing you could do in the application itself and maybe that is why HDF5 is not supported. Rolf Kalbermatter

I haven't played with the watchdogs on cFP and don't have one handy to play with but I'm afraid there is only one wtachdog hardware resource on the cFP. Either trying to open more than one will not work at all or if it does it may reset the watchdog on every access which means you would only fail if ALL your loops stop. A better aproach may be to wire up a small LV2 style global that allows your loops to open a reference to some internal state (an array index might work). On every reset store the actual timestamp in the apropriate index and evaluate all timestamps to have not elapsed more than your set value. The whole thing might be a little bit involved in logic to make sure to reset the actual watchdog apropriately but it could definitely be made to work. Rolf Kalbermatter

In principle LabVIEW should only use XWindow and therefore should be independant of the Window manager and Desktop environment used so should run on any system that has an XWindow server. There have been however some trouble in the past letting LabVIEW run on dummy XWindow servers that only provide some sort of text output (to save resources for applications that could run as headless systems) and I'm not sure there has been any work done to improve on that. Rolf Kalbermatter