Rolf Kalbermatter

Please let us know what NI has to say about this. I'm going to be in this same spot soon and it would be nice to know why I need to distribute deployable licenses for a runtime app.

Ok on my own machine I usually run with an account that is part of the admin group and the other computer is a standalone system with only one local user with local admin rights. But reading through it, it all makes sense. Since Vista, MS has tightened security according to the principle that a user should only have access to resources that do not influence other users on a system. This includes the entire registry except the user specific hive, the filesystem including all setting directories that are used by all users. So ProgramData logically belongs to that. I just added a small piece of code that checks in the configuration dialog the write rights for the configuration file, and if that is not there of the directory and only enables the Save button if this is true. A dialog informs the user that the application needs to be started as admin in order to be able to make changes to the relevant configuration items. Since Vista you have to differentiate between elevated rights and a user account that has admin rights. The difference is that in order to be elevated one has to start the process explicitedly as admin with an extra password login dialog, even if the current user is already part of the admin group. Your solution has one possible drawback. Only changing the rights of the config file alone is likely not enough as the directory needs to have its rights also changed. And that allows access to the directory to add more files to anybody, although it should be not possible to change existing files that don't have write rights for normal users.

I want to know that too. I'm using Windows 7 Professional here in 32 Bit and 64 Bit on another machine and ProgramData/<Company Name> seemed to work quite well so far. Or where they trying to access it with hardwired names, instead of requesting the location from the OS? Or is it restricted for Guest accounts or similar?

But you typically are not going to multicast 60MB files to many stations.

To me it seems like an academic research project, and as such literally an "academic exercise". I'm sure such work is needed but I wouldn't even bother to think about using UDP to transfer larger entities that need to stay consistent. TCP is tried and proven for such things, so why it needs to be UDP is beyond me. It's not like UDP would be easier to route in restricted networks or such, so I simply don't see the benefit of going through the hassle of reimplementing some of the TCP handling on top of UDP.

Without that ini token the executable may still get started by the Windows shell, but one of the first things LabVIEW does on starting up is to try to connect a different (same version) LabVIEW instance (through DDE communication) and if it finds it it will simply pass any command line commands to that instance instead and quit gracefully.

To expand on Antoine's post besides the hidden or non-hidden location you should consider if settings are user or machine specific. Things like hardware configuration you probably don't want to maintain on a per user base, but other things like applications settings (data formats, paths, etc) your most likely will want to keep separate for each user.

You haven't shown much so far that would have made me believe that you have much of a technical understanding of those protocols. And wanting to do something is a nice thing, but if it is a useful exercise an entirely different one. Considering some notices in the paper about how the difference in calling socket functions can have a significant influence in lost buffers, I think LabVIEW might be not the ideal environment to tackle this research. You have no control whatsoever, in how LabVIEW handles the socket calls. In addition it adds it's own network data buffering that you can only influence in limited ways from the LabVIEW nodes. And no I'm not talking about controlling socket attributes by calling socket API functions directly, but how LabVIEW calls recvfrom() and friends itself.

To me it looks like IEC61850 is not about transfering large files consistently over the network. To do that over UDP is really not a smart idea as you have to implement on top of UDP something similar what TCP does already for you. An interesting side node to this: A while back I was looking at the network protocol used by Second Life and other compatible virtual world environments. They used to have the entire communication over UDP with their own sequence handling, acknowledgement and retransmission requests. The reason to go for UDP was supposedly the low overhead that was required to make movement and interaction in a 3D virtual world possible at all. However a few years ago they did introduce a new mechanisme for non-realtime critical messages and are porting slowly more and more of the messages over to this new mechanisme. It is basically a HTTP based protocol where the packet load is usually a data structure in their own LLSD format, which is in many ways similar to JSON. And yes I have implemented some basic messages in LabVIEW that got me as far as logging into a virtual world server.

UDP is not a reliable protocol. Unless you intend to do A LOT of extra error handling, packet sequence management, lost packet retransmission and what else, you can forget to use it for transfering a file that needs to stay consistent.

I'm not sure I would undersign this as a LabVIEW bug. LabVIEW doesn't instantiate new executables but the Windows shell does. For some reasons the shell thinks that the launching of the command has failed and seems to retry it in an endless loop. This looks more like a flaw in the handling of launching an executable than in LabVIEW itself, especially since the spawning of new processes seems to happen so quickly that LabVIEW hasn't even gotten a chance to already be loaded into memory and start doing anything at all, that could influence the Windows shell in such a way.

There is nothing wrong with your explaining skills! There are however people who do not want things to be explained to them but instead things being done for them. Or English is not the native language but the posts look pretty ok to me in grammar, so why someone with such a grasp of the language never has heard about "chunks" is beyond me. Also while reading a file in chunks and sending it over UDP will probably work in a local network, I'm pretty sure the resulting file on the receiver end will be damaged after being transmitted like that over a more complex network infrastructure. That is unless one adds also packet sequencing code to the transmission (and in doing so more or less reimplements the TCP protocol on top of UDP).

And going beyond 1500 bytes MTU is only an option if you are on a controlled network where you do know about all routers involved between the two parties. Once you go outside of that, such as an internet connection, the maximum MTU is entirely out of your hands and going beyond the default of 1500 bytes is really playing chances that the communication will actually work, unless you do a lot extra work in reassembling the incoming packages into the right order on the receiving end. And that is something that is even on embedded devices usually handled much more efficiently by the TCP protocol level, so why go to the hassle of UDP in that case? As to data transfer of LabVIEW TCP, it has some overhead in its internal buffer handling but I have in the past reached half the bandwidth of the network without to much trouble, as long as you don't do a two way handshake for every packet send. There used to be some challenges in older LabVIEW versions, with LabVIEW simply loosing data or even crashing on heavy network load (supposedly some rare race conditions in its socket handling), but I haven't seen such things in newer LabVIEW versions.

Actually it is a little different. In LabVIEW < 5.0 a skalar boolean was a 16 bit integer and the most significant bit defined the boolean status and everything else was don't care. However boolean arrays where packed into words, so an array of <= 16 boolean would consume 16 bit. Now the history or this is of course presumably the MacOS which had somehow a similar notion, but the packing and unpacking of boolean arrays caused actually quite a bad performance for some operations. So LabVIEW 5.0 changed it to the more common 1 byte per boolean notion, which is what most C compilers use also as their default boolean implementation (although the C standard does nowhere specify what size a boolean has to be).

Well like with any other DLL too, using the Windows API LoadLibrary() and GetProcAddress(). The bad thing about this is that it will make your SQLite library more Windows specific and less portable. My personal choice for this would be to create an extra C file that adds the necessary C functions and then either add it to the SQLite source, compiling my own LabVIEW friendly SQLite shared library, or in order to be able to reuse prebuilt SQLite libraries, create a separate DLL that contains these helper functions. Yes this requires you to use a C compiler for every platform you want to support your library on, but if you start to support more than one platform (and Windows 64 Bit is a different platform already) the maintenance effort of creating those helper shared libraries for each platform and maintaining the platform specific loading of those helper functions is quickly getting a real hassle in comparison to simply creating the helper library directly in C. And your LabVIEW VI library stays all tidy and clean, no matter what LabVIEW platform you want to support. BTW: I was just checking out Fossil from the same author. Looks like an interesting light weight DVCS application based entirely on an embedded SQLLite manager for its datastorage. Advantages: Integrated Issue Tracker and wiki, support for binary files although obviously without merging of branches, simple HTTP based network protocol with SSL support both for syncing but also interfacing with it from a different tool (like a LabVIEW plugin). And all that in a single executable that barely is larger than the SQLite database kernel itself. The disadvantage, if you can call it that, is the rather simple web based user interface to all this functionality.

Are you trying to use the script node or the LabPython VIs? For the VIs pytscript.dll should not be required at all. For the script node it is required and it used to be necessary to install it in the <Program Files>/National Instruments/Shared/LabVIEW Run-Time/<LV Version>/script directory for the script node to work in an executable. Not sure if the application builder is trying to do that somehow in newer versions without really working it out correctly. The DLL is located in your <LabVIEW>/resource/script directory in the development environment. Try to add it from there into your project and add it as always included component, trying to install it in the according runtime subdirectory. When creating an installer you should add a script subdirectory in the LabVIEW Run-Time destination and specify for pytscript.dll to be installed into that directory.

Thanks for all the feedback here. We certainly are listening to this and are considering the remarks seriously. I'm currently busy getting the LuaVIEW toolkit ready for a new release but the way LuaVIEW has interfaced to Lua, has caused some serious headache in getting it ported to Lua 5.1 (and Lua 5.2 will probably have a few more hurdles, especially on the script side as some differences between Lua 5.1 and 5.2 are subtle but could have rather far reaching effects for certain things). For those interested to get LuaVIEW working with the newest LabVIEW releases I posted a minor update version 1.2.2 to the website. It fixes the unit test crash for LabVIEW versions >= 2009 (which is really a crash in a LabVIEW node for the Motion Resource), and also has two minor errors fixed in the datalogging framework for those using it. No other changes have been made to it. We are planning to have a short beta program for LuaVIEW 2.0 on Windows and Linux within about 4 weeks and release the Toolkit officially for all platforms before NI Week. Interested people can send me a PM on this forum to apply for the Beta Test.

Does your notebook happen to have a built in modem? That is usually installed as serial port too. It's not that they usually don't work, but that they don't work reliably. Not a problem for a quick throw away lab setup but definitely a gotcha if used in an industrial application that should preferably have an uptime of 110% for 24/7. What can happen is that some suddenly stop working until unplugged and replugged or possibly been reseted. One specific one has been very reproducible and it turned out to be a special byte sequence in the binary data stream that could throw its driver into nirvana.The bug is known with the manufacturer but being a low cost device they don't spend any more dollars in maintaining a released product but instead want you to buy their newest junk.

The VI calls into the LabVIEW runtime itself and that function supposedly does use some platform specific interface (GDI on Windows) to calculate the bounding rectangle of a specific text. The issue you see with italic text actually happens when calling those Windows GDI functions.

Wow iterating over Pixels in a loop through .Net calls. You only can hope that icons never get bigger than 48 * 48 pixels or that function is going to be soooooooooo sloooooooooooow. Instead there are ready made LabVIEW VIs in vi.lib/platform/icon.llb that use exclusively Windwos API calls and are not just factors faster than your solution.

Well DLL call overhead is in the order of microsoeconds or less. You could experiment with the configuration of the Call Library Node and change the error reporting mode (in the extreme case to Disabled), but I doubt you would see any significant difference there. The delay is most likely in passing the command over the pipe itself and then even more in the interpretation and execution of the command in the program. And your two String Subset Functions could be replaced by a single Split String node.

Well not really sure about the block size mentioned by the other poster, but the ZIP Library has gone through some optimizations for sure. If you extract each file seperately by reopening the archive each time, you impose a huge performance hit. The global directory has to be traversed each time and the particular file be searched in it. The ZIP library routine to extract the entire archive in one go only opens the ZIP archive once and then traverses the directory listing once to retrieve one file after the other. Since it already has the right directory entry handy it also doesn't have to look it up again each time. Multiminute delays does seem a bit excessive however, but if it was an archive with many small files it may be explainable.

Well whenever the information that is available is enough for me to know what I need to do. Of course in some areas that may be quite different for me than for other people.

Noooo!!!! Please not!!! LabVIEW manager functions are ALWAYS C calling convention! That it seems to work is simply very bad luck (and it most likely doesn't really work but just not crash anymore). What the real problem is, is the fact that these VIs were written long before anyone knew what 64 Bit pointers will be and therefore LabVIEW also had no means to configure parameters as pointer sized integer since in all LabVIEW versions sizeof(*void) == sizeof(int32) was true. The second paramter to MoveBlock() is configured therefore as int32. To make this work all Shared Library Nodes in that library need to be revisited to check for parameters being configured as (u)int32 but really being pointers and they need to be changed to be pointer sized integers. After that the library should work independent of the bitness of LabVIEW. This means that besides the second parameter to MoveBlock() at least the function where this wire comes from needs to be reconfigured too. Edit: I see it uses the WinAPI RtlMoveMemory instead of LabVIEW MoveBlock(). From the VI Name I assumed it would be using the LabVIEW manager call. The problem about the pointer sized integer parameter however remains the same. It just so happens that Windows hasn't mapped the heap of your application above the 2GB range, otherwise it would badly crash. And that library needs to have a lot pointer sized integer adaptions to make it 64 bit safe.

This is an area in LabVIEW where there have been subtle changes over the versions. But basically if you only enter the DLL name into the path then LabVIEW will call the LoadLibrary() function with just the DLL name, which will cause Windows to search in all standard locations for the DLL. LabVIEW will update the path constant with the entire path to the DLL that Windows has loaded the DLL from, but will remember to only use the DLL name itself even in the future. And it will also not include the DLL into any build if you go to build an executable, assuming that it is either a system DLL or one being installed by a seperate installer (which is usually the common way that you get the directory to the DLL path in the PATH environment variable). If you however browse to the DLL or enter the enitere name directly, then LabVIEW will assume that the DLL is private to your application and also include it in any build. This can cause havoc for system DLLs, since kernel32.dll on your XP system is seldom the same on another users system which will cause troubles. Also since about Windows XP Windows will attempt to load explicitly loaded DLLs (LoadLibrary() calls with a full path, even though the same DLL is already in memory from a different path as this was required to support the SxS DLL loading, an attempt to alleviate DLL hell, but in my opinion just a way to cause more DLL hell) and that causes total havoc for many DLLs from the Windows system. Personally I think LabVIEW should explicitedly avoid from including any DLL into a build, that resides in either the Windows or the system directory, even if the user entered a full path, but it is debatable if it is LabVIEW's job to worry about such things. I do think that the influence of initially entering just a DLL name in the Call Library Node versus the entire path, should be made visible somehow and also be better documented.