Rolf Kalbermatter

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.

LabVIEW is a little smarter than this. Data to be passed into a subVI is only copied if it branches of to some other function too that can not operate independently on that data, such as any inplace operation or another subVI. Otherwise LabVIEW schedules the function that does not potentially (it doesn't know if a subVI would modify the data, but assumes so for safety) modify the data, to execute before the subVI or any data modifying operation in order to avoid the data copy entirely. The data space of a VI has little to do with possible parameters wired into and out of the subVI but a lot with state information for the VI and things like shift registers.

The problem with this is that you start to accumulate a lot of (optional) formatting hinting parameters to the function quickly. Time format, floating point and decimal format, and what else. I wonder if a single string could work, where you use a syntax like the Format into String syntax to actually list all possible formatting options. Decimal point would be always the first formatting option like %.; and other formats could be looked for based on patterns such as %<.+>T etc,

I don't know much about SNMP either other than the principal operation of it but my understanding is that there exist special tools to create (compile) a MIB file from a different intermediary text description that the developer of an SNMP device creates. So if you have an existing device with SNMP implementation you should get the according MIB file from the manufacturer of the device. If you designed the device yourself only you can know what SNMP variables and OIDs you have used and will have had to dig into the whole SNMP RFCs and associated documentation anyhow to get there.

Well LabPython simply loads the Pythonxx.dll and instantiates a session. As such it will work with Python still running. But it will not be able to communicate with anything in the Python process automatically, as each Python sessions is in fact a separate Python environment. If you need to communicate between a Python session and a session created through LabPython, you have to setup explicit inter-application communication, especially since LabPython runs in the LabVIEW process, while Python runs in its own process, so process memory protection applies fully here.

Be aware that the second solution using InPort and OutPort is not going to work for 64 Bit Windows system, as far as I know. You may say that this is not an issue now, but there are rumors that future Windows versions will go the same path as Apple did, and will be 64 bit only, without any option to boot a 32 bit version anymore.

Omega is NOT ASCII code 234. It may be so in one or several specific codepages but Windows knows literally dozens of codepages. They usually (not always) produce the same glyph for the ASCII codes 1 to 127 but have wildly varying glyphs for the codes 128 and higher. And different fonts support different codepages but are not equivalent to them. There are two ways to deal with this to be able to display more than 128 different character glyphs at the same time. Traditionally older systems used a Multibyte encoding scheme which is what LabVIEW uses too,. The second is Unicode, which is nowadays kind of common as far as platform support goes, but support on application level varies wildly with many applications still not being able to deal with Unicode properly. Also Unicode has some issues as far as collation tables and such go. There is the official standard from the Unicode consortium and the defacto standard as implemented by Microsoft in Windows. They differ in subtle but sometimes important ways, to make it very hard to write a multilanguage application that uses the same code base for Windows and non-Windows systems.

Originally OpenG VIs were located under the OpenG palette only. Then, I believe Jim, figured out the Dynamic palette feature and the OpenG VIs were also added to the respective subcategories. However this dynamic palette feature was quite bristle as it didn't seem to be a designed feature and NI broke it in later versions somehow.

I won't be able to spend any time on this before the christmas vacation. And at the same time I want to address Windows 64 Bit compatibility. So I would say a good estimate for a new release that includes the newest source code already present in SVN is sometimes after start of next year.

As long as it is for your own use, there is nothing that forces you to do any licensing related stuff (this is about OpenG, or other Open Source, use of commercial software needs of course to obey their licensing requirements even for personal use). But once you distribute your app, commercial or not, you need to comply with the Open Source licensing requests and this means you need to add some credit information for compiled apps or leave the source code intact in the distribution. Chances that a coworker is going to fuss about this if you let him use the compiled app are rather small, but you are strictly speaking in violation of the OpenG license if you don't add some credit information somewhere in your compiled app. If however you distribute the whole thing in source, that already fulfills the license requirement.