Rolf Kalbermatter

At least in LabVIEW 7.x the Feedback node has some dramatic non-optimizations in comparison to shift registers. This is not inherent to the feedback node as it is in fact just a different thing for the same functionality but probably a oversight or time pressure issue, where the optimizations applied to the shift register over the last 4 or so LabVIEW versions haven't been implemented fully yet. For the records there have been LabVIEW versions (5.1 and also 6.01 and others that had some rather obscure and nasty overoptimizations of the shift register resulting in wrong execution of the code.) Considering this I think it is better to introduce a new feature not optimized to the max than having it create wrong code due to a corner case not covered where it does a to agressive optimization. Rolf Kalbermatter

You say 9 characters. But the string according to the earlier decoding only has 6 relevant characters. So those extra 3 characters might be some information but just as much one or two termination characters too. Depending on delays is a very unreliable operation and will fail sometimes. If you would capture a string or five and then display it in a string control configured to Display Hex Codes you could post that Hex code string and we might guess at what could be a good solution to detect the end of string. Rolf Kallbermatter

This is my hacked together variant of the Set Default Printer.vi. I did some empirical research activity (in earlier days this was called reverse engineering and a hex editor and some disassembly can help wonders here) and this is to the best of my knowledge what the NI VI does, with some extra code to fix the behavior of that function with invalid inputs. BTW: There seems no way to get the cancel status at all. (Basically calling this function with an empty string and FALSE for show dialog, sets the internal LabVIEW printer name apparently to an invalid setting and after that any print activity will abort with a printer dialog error (34) and the only way to get printing back to work is to restart LabVIEW or the applciation). You can produce the same error with the Application property in LabVIEW >= 7.x Printer.Default Printer). I posted a bug report about this but never received anything besides the automatic acknowledgment until now. Rolf Kalbermatter Download File:post-349-1136843760.vi

Mmmh, I think the path should not really matter. I'm not intimate with all aspects of OpenG tools such as Commander and Builder but the different OpenG tools and menu palettes should all use relative paths internally. Otherwise it couldn't work on non-Windows systems at all and as far as I can say (Linux) it seems to work fine. Rolf Kalbermatter

IVideoControl is an ActiveX control. LabVIEW had always problems to get the drawing of an ActiveX control across the network to other clients, since ActiveX really limits the control LabVIEW can have over the control. An ActiveX control normally draws on screen when it likes and without telling LabVIEW that it does do that. So LabVIEW has almost no way of knowing that it should copy the image data over to the client as well and even if it could it would be VERY slow. So an ActiveX control normally remains a black rectangle on a remote screen. Using a Picture Control instead would work a lot better but it likely would be slower than the ActiveX update on the host PC. The IVideoControl version 1.0 I tried a few years ago, had a bug in the type library for the method to retrieve the data into a pointer. This meant that you couldn't use it to get the image data into memory directly to convert then into a Picture Control image. Maybe that Logitech fixed this issue in the ActiveX controls for the newer cams. The latest driver suppporting my very old cam still contains IVideoPortal 1.0. I abandoned Logitech years ago, since they were very hostile to anyone wanting more information to be able to write a driver for non Windows platforms (and never reacted on my above mentioned bug report nor did fix it). I got the feeling that Logitech doesn't care about the user once they bought their product and at that time things did cost quite a bit more than nowadays. If I had paid 20 bucks for my cam I could understand that they can't afford to bother about anything once the product is released. Rolf Kalbermatter

The biggest problem is that Unicode is not Unicode. While Windows uses 16 bit Unicode most other systems use 32 bit Unicode characters. So having a platform independant Unicode library is almost an impossibility. If you don't believe me you should checkout the Unicode support that had to be implemented in Wine in order to support 16bit Unicode on 32 bit Unicode Unix platforms. This whole issue is even more complex when you consider wanting to read Unicode coded data files in a platform independent manner. Basically I would consider this almost impossible because you would have to support both 16 bit and 32 bit Unicode on all LabVIEW platforms. What I'm suspecting the NI solution will be is a Windows only Unicode function library for creating, saving, and reading Unicode strings. With a little work this can already be done with a Call Library Node calling Win32 APIs, as they do all the nasty work for you. I posted a while back a library to the NI forums to convert to and from Windows Unicode strings calling those Win32 APIs. Last time I checked the link to is was: http://forums.ni.com/ni/board/message?boar...uireLogin=False Rolf Kalbermatter Rolf Kalbermatter

No. There is absolutely and definitely no hardware in the parallel port circitry which would measure that voltage. And therefore no magic could allow Windows to provide a function to read this voltage. The power status is a specific analog circuitry present in all modern PC motherboards and supervising the internal power supply and Windows has a function to read this status since it wants to know when it should suspend operation before the battery is drained. But this circuitry has absolutely no connection to the parallel port. Rolf Kalbermatter

Yes, buy a DAQ card and install it in your computer ;-). Otherwise no, the parallel port is a digital interface with signals when going above 2.4 V meaning logic high and below 0.8V meaning logic low. There is no analog measurement built into the parallel port nor any other part in a normal PC. (This leaves out the temperature and CPU voltage level controls nowadays built into the power management of modern PCs but you couldn't use them for measuring arbitrary port signals anyhow). Rolf Kalbermatter

Don't you need to enable the TCP/IP access for VI Server of the executable application in order for the debug connection to succeed? The error message itself is quite likely not very accurate but something is going wrong. Rolf Kalbermatter

It also doesn't work with text in string controls. I assume that LabVIEW does something with the data part of a control that makes the entire string use the font setting of the first character on reopening the VI. Rolf Kalbermatter

You must be doing something wrong with endianizing or such. But this shouldn't be that difficult to figure out. Just go debug on the LabVIEW side! Look at the data you read from the TCP/IP socket and display it in a string control. Now play with the display mode of that string control and look at what you can see. In Hex mode you definitely should see a pattern you can then further trace to see what might be wrong. While endianizing in Java might be the solution I'm not sure that is actually the right way. Java being a platform independant (at least that is the intention isn't it ?) development platform may already do some endianizing on its own internally and in that case likely chooses the big endian or network byte order format which happens to be the same as what LabVIEW uses. Otherwise Java client server applications between Intel and non Intel platforms couldn't communicate seemlessly. Rolf Kalbermatter

Well, I do think Visual Basic does usually work directly on VARIANTS but am not sure. As such it would not need to convert a VARIANT array to another representation before doing some stuff on it. If using such a COM object is much faster in VB than from LabVIEW I don't know. Last time I touched VB is more than 10 years ago. COM itself does not mandate VARIANTS per se, but if it is going to be an Active X interface or a COM object which can be marshalled over network you need to limit yourself to the supported datatypes (and I'm not sure if Active X can marshall VARIANTS, I know that it can't easily do that for structures.) Basically COM was not designed with data acquisition applications in mind and trying to use it in such environments creates all sorts of problems and limitations. Using Visual C to build the COM component likely will speed up the execution time of such a COM component and you don't necessarily need to restrict yourself to VB supported datatypes (although wanting to allow such a component to be used in VB you probably want to at least provide alternate VB compatible access methods). VARIANTS definitely wouldn't be my choice of data transport if I ever would write a COM component. While a DLL interface may seem cumbersome at first it definitely is still the most flexible one and allows all sorts of fast and reliable data transfers. Also it is the most versatile in terms of interfacing as there are almost no software environments that can't link to a DLL (and if they can't link to a DLL they very likely can't link to a COM object either). The only advantage of COM or actually rather DCOM here is that it supports seamless networking (at least if you limit yourself to data types that it can marshall). Rolf Kalbermatter

You can do that but you will have to get acquinted with some low level GPIB details and API functions. Basically a GPIB bus always has exactly one system controller (this is called SC in GPIB speak). This is normally the PC but since you have two of them you will have to configure one of them to be the system controller (that is the default for a PC GPIB interface) and the other to be not so. Then at any time there can only be one interface a controller in charge (called CIC). A system controller can at all times request control over the GPIB bus and therefore be CIC, aborting any ongoing communication by another controller that has been CIC. In order for a non-SC to get a CIC it has to wait for the current CIC to pass control to it. This all can be done for sure using the old traditional GPIB functions and I'm sure there are still some documents on the NI site explaining that. I have no idea if VISA supports multi controller functionality in any way. Last time I checked it didn't seem to. Rolf Kalbermatter

Probably not. Visual Basic does everything that does not fit into a string or a single variable with VARIANTs. VARIANTs are not so fun to deal with directly and you need a whole bunch of Windows OLE functions that are not available on non Windows 32 bit systems. Therefore LabVIEW chooses to convert incoming variants into its own binary format (well not really its own but the format used by virtually any real compiler, which of course leaves out Visual Basic) and reconvert them back when handing them back. The only real solution to speed these things up is to not use Visual Basic and/or Active X for such cases (or do everything involving such arrays in Visual Basic). My choice would be the first as I try to avoid ActiveX at almost all costs for its famous stability, version interchange compatibility, and lean and mean runtime system, not to mention its unparalleled multi-platform nature :-). Rolf Kalbermatter

Well, without LabVIEW DSC you will have to write your own DDE server. Let me tell you that that is no fun at all, as DDE has a few drawbacks nowadays. First it is an old technology and in some areas rather strange to use for nowadays understanding. Second it has a few quirks including in the LabVIEW interface and there is NO support for it anymore. Nobody at NI is going to look into a problem if you can't get something to work and there very likely won't be a bug fix of some sorts if it turns out to be not working due to some obscure DDE incompatibility with your Windows system. That said an Excel example is more or less all that is needed. It should show you the service name as well as the topics. What you may be running into is the NetDDE setup that is needed for networked DDE communication. There have been tutorials on NetDDE configurations for LabVIEW DDE on NI's site, but they were written for Windows 3.1 and Windows 95. You may be likely running into access right problems on more modern Windows NT based systems and need to figure out how to setup your system right to get around them before being able to access a remote DDE resource. Do the Excel examples work over the network, because that would indicate that the NetDDE configuration is more or less correct. Rolf Kalbermatter

Could this be something delegated to the scripting feature now? Would seem to me that you could enumerate the diagram or whatever and as one of the properties of a control or wire get its new 32 bit type descriptor. As such it is of course basically not accessible anymore. Talk about removing features due to an update! NI seems to find with every new version new ways to make a power user wonder if an upgrade is really such a good idea. Rolf Kalbermatter

Oh well, a closed discussion board. I don't feel like signing up to view what you refer to, but I guess I have some ideas. Happy holidays Rolf Kalbermatter

You can strip the front panel, but for the VIs you want to call dynamically you shouldn't do that. In order for the dynamic parameter passing to work the VI really should have it's front panel otherwise you will get all sorts of errors when trying to load such a VI dynamically and/or call it. Rolf Kalbermatter

You bring up points which have been discussed already here on lava as well as info-labview. I don't think you really want to tie the project hierarchy to a disk hierarchy. This puts up a strong limitation to what the project hierarchy can represent which is IMO not necessary. Other development environments like MS VC don't choose to synchronize the project hierarchy with any disk hierarchy either and I feel this to be a good choice. SVN and all the other SCC systems are not directly supported in LabVIEW 8 but LabVIEW makes use of the MSSCC API. This is a closely guarded trade secret of MS and you only can get the specs by sigining a NDA. As such it is not very likely that there will be Open Source implementations of MSSCC interfaces soon. However you can get PushOk's SVN plugin (not open source or free though) discussed by Jim Kring in another thread on this board, which interfaces SVN to MSSCC compatible development environments and in this way LabVIEW is just as compatible to SVN as it is to other SCC systems such as MS VSS or Perforce. The project explorer view is quite something to get used too, and it does have certain quirks at the moment which are sometimes just not intuitive and sometimes simply a bug. I expect most of these things to be ironed out in LabVIEW 8.1 ;-) Rolf Kalbermatter

Oops is that one of the super secret VI properties? Nope doesn't seem! It is in Execution->AllowDebugging. Rolf Kalbermatter

Back in my days at NI, CAR stood actually for "Corrective Action Request" and probably still does. The guy who wrote that answer probably just was tinkering about the creativeness he could do in writing a LabVIEW program instead of answering a technical support. Working in technical support can have this effect on you! :laugh: Rolf Kalbermatter

I usually do this by toggling the debugging flag twice. Snooped it from some LabVIEW internal functions some versions ago. Rolf Kalbermatter

Please don't do that! The menu would get so cluttered it would be completely useless! LabVIEW has virtually thousend of options if you add everything together. Rolf Kalbermatter

You will have to call a Windows API function. Use the Call Library Node and configure it so that the library name is kernel32.dll, function name GetFileAttributesA, calling convention stdcall, return value numeric, unsigned 32bit integer, and one function parameter filenname of type string, C pointer. Now wire in the filename path to the parameter input after having it converted to a string with the Path To String primitive and the return value from that function contains a whole bunch of information encoded in the individual bits. Basically if the return value is 0xFFFFFFFF then there was an error such as the file was not present. Otherwise you can AND the return value with following values and if the result is not 0 the bit is set: #define FILE_ATTRIBUTE_READONLY 0x00000001 #define FILE_ATTRIBUTE_HIDDEN 0x00000002 #define FILE_ATTRIBUTE_SYSTEM 0x00000004 #define FILE_ATTRIBUTE_DIRECTORY 0x00000010 #define FILE_ATTRIBUTE_ARCHIVE 0x00000020 #define FILE_ATTRIBUTE_ENCRYPTED 0x00000040 #define FILE_ATTRIBUTE_NORMAL 0x00000080 #define FILE_ATTRIBUTE_TEMPORARY 0x00000100 #define FILE_ATTRIBUTE_SPARSE_FILE 0x00000200 #define FILE_ATTRIBUTE_REPARSE_POINT 0x00000400 #define FILE_ATTRIBUTE_COMPRESSED 0x00000800 #define FILE_ATTRIBUTE_OFFLINE 0x00001000 #define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000 Some of them are redundant since LabVIEW returns them also in the File Info primitive. Enjoy Rolf Kalbermatter

Talk about installation size! VISA is small compared to .Net 2.0!! The only reason not to use VISA was really the very restrictive licensing and runtime costs. NI changed this licensing recently and now I do not see a pressing need to replace VISA with yet another even bigger monster. Besides you are not allowed to install .Net on anything but a genuine Windows system anyhow and for .Net 2.0 I would guess it better had to be XP or better or it won't install anyhow. Rolf Kalbermatter