Rolf Kalbermatter

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.

I can only confirm the upgrade pains. When it was BridgeVIEW it was a predominantly LabVIEW based system with some external Logos (Lookout) components added in. Each version removed quite a bit of the LabVIEW based components and replaced them with the newest hot from the press NI technology. These replacements were supposed to be seamless, but in practice always caused various pains. And even once replaced technologies got sometimes replaced with yet another even newer technology. All in all I can't say that I can still work with the DSC toolkit anymore as just about anything is very different than it was at one time. Also I do have developed over time my own entirely LabVIEW based data logging and monitoring system, that has many of the features of the original BridgeVIEW based system and works perfectly fine, so my need for DSC has more or less completely diminished. Additional bonus of this system is that it also ports quite nicely to RT targets like CRIO and Compact Fieldpoint. That required some initial work to make it work fine on those resource constrained systems but by now I can move an application based on that framework almost seamlessly between desktop and those RT targets. And multiple applications can communicate with each other their tag database so really distributed systems is just some extra initial configuration effort away.

Not really much NI can do about it. This is not a standard socket property at all and Windows socket implementations don't even support to set it through the API. So even if NI ever decides to add a property interface to network refnums, it's not possible to change this setting from the program in any way. And the 200ms acknowledgment is a standard TCP/IP socket feature, that Microsoft implemented in Windows 2000 to conform to the standard. So the really faulty party here is the PLC that resends already after 50 ms if you want to call it a fault. Realistically it's just a workaround to guarantee that any packet is acknowledged after not more than 50ms :-) Enabling this registry setting in Windows is the only way to change this setting, and you don't want LabVIEW to change this behind your back in the registry ever! Especially since it enables this feature for any connection on that interface, which can be a real burden on network traffic if normal internet traffic also happens to go through this interface.

Yes! An invisible wiring error? It's about 99.99% of the cases for me when I see such strange behavior. The wire looks as if it is coming from the tunnel but in reality comes from some other place, that resets the reference. Or there is a tunnel that uses default data if not wired, and another one on top that caries your reference from that case but goes nowhere. That is one reason that I really think twice before enabling the "Use default Data" on any tunnel.

Well there is a #pragma pack(1) so it sure will work. And more importantly, this structure has no alignment issue since a float is a 4 byte entity, so together with the int it aligns the double on an 8 byte boundary, no matter what packing definition is used. Change the float to a double (and make the according change in the VI too!!!!) and the #pragma gets important again (or he also changed the default alignment in the project settings!).

If it is Visual C+ it for sure uses 8 byte default alignment. So wrap the declaration of the struct between #pragma pack(1) typedef struct { .......... } Structname; #pragma pack() [/CODE] It's always a good idea to reset any alignment setting back, as otherwise you get a big mess with the order of includes changing the behavior.

I think so. Leave it on sourceforge for whoever wants to look at its implementation and do his or her own stuff with it. But it probably shouldn't be an official OpenG package anymore. I started it for a quick and dirty test once, and after it got a personal thing between me and Windows, to try to force it into submission . Once that point was proven it lost its appeal for me. I learned quite a bit about Windows device driver programming with it, but mostly stuff I didn't want to really know.

Most likely you don't want to call the Constructor Node at all after the first initial call from your Top Level routine. Proper solution would be to separate the Construction of the object from any other initialization that you might want to do from your plugin. A quick fix would be to wrap the Constructor Node into a case structure that is selected by the Not A Number/Refnum primitive, This will create the refnum anyhow the first time around (and even if it got somehow invalid in the meantime, which it shouldn't anymore).