Rolf Kalbermatter

The easist possibility would be to get the Crypto-G Toolkit from http://www.jyestudio.com/visecurity/cryptg.shtml. It's pricing is VERY reasonable and definitely cheaper than spending even one or two hours of your time. It contains functions for AES encryption and decryption. Since AES is a standard it should be not a problem that the encryption is done by a different library than the decryption. If you still are here and want to persuade the DLL path, reading the online reference manual about External Code in LabVIEW is an absolute minimum to do to be successful here. And unless you have a sound understanding of C you really will have to go to www.ni.com and do a search on external code to get some good references about what to watch out for. Most of that information is not even LabVIEW specific, but without knowing quite a bit about pointers, datatypes etc. you simply can't hope to get something reliable, using the Call Library Node or Code Interface Node. One obvious indication that you may miss some basic understanding about C is that you leave out some important information here. Without knowing about the type definition for AES_KEY, nobody can possibly give you a ready made example as to how to implement this in LabVIEW. On the other hand if you would know that, the solution most probably would have presented itself to you already without any extra help. You definitely don't want to use a CIN here, believe me, since that will absolutely and without any way to avoid it require you to write C code, so look at the Call Library Node (CLN)! While your information is not really enough to tell you a step by step plan to go with the CLN, you will have to create two VIs with a CLN in there each. Another bit of information that is absolutely not clear is the calling convention that might or might not be defined with the EXPORT keyword. It is probably stdcall but cdecl would be quite likely to if the DLL you try to call is designed for multiplatform use. Trying this one out however is quite easy. If you get it wrong you will immediately crash LabVIEW so restart and try again, switching the calling convention before running the VI. What remains are the "(const) unsigned char *" types and the "AES_KEY *". The first is easy as it is just a C string pointer. So you will have to configure the corresponding CLN parameters to a String type, pass as C string pointer. For the input strings you will pass in the string as required by the function but for the output string you have to allocate the string, since this is a standard convention in C: the caller of a function has to allocate the memory for any parameter that function is supposed to write into. To allocate memory in LabVIEW is easiest by creating an array of unsigned 8 bit integers with the Initialize Array function, and since we need really a string here we convert it then to a string with the Byte Array to String function. How much of memory you have to allocate for the function not to crash is however function dependant and should be documented by the developer of that function (if it is not documented in any way you should kick the developer in his ###### if you get a chance). For the AES_KEY * I can only make wild guesses. It is likely a pointer to a structure. What size this structure has is unknown. As long as that structure does not contain variable sized elements (strings and arrays) you can create an according LabVIEW cluster, and configure the CLN to use Adapt to Type for this parameter. There is a possibility that your cluster uses a certain byte alignment. This is maybe visible in the C header file for your DLL by some #pragma pack() statements but just as likely it might be something only known by the developer. LabVIEW always uses byte packed structures so you might have to experiment here. But considering all this I really very much would recommend you to look at getting Crypto-G. It will give you a ready made solution and definitely cost you less unless you value your time absolutely nothing. Rolf Kalbermatter

The problem with that VI is that it prints the panel as documentation, that is with a header. To create reports for instance it is usually not desirable to have any other information on the printout than what is on the actual panel that is to be printed. This printout of panels without any additional information works very fine if you set the VI properties to "print when completed". But you have to create your own custom print dialog because the one discussed earlier will not indicate a user cancel. Rolf Kalbermatter

The data could be binary as you say and in that case there is really no way to get something intelligent out of it without a good manual describing the actual data format. Another possibility as already mentioned is, that it is actually ASCII but you are not using the right baud rate, data bits, stop bits, and/or parity settings. Rolf Kalbermatter

I was considering this approach as well. But the problem is that it does only allow to select the printer itself and not any of the print properties for the particular printer such as paper selection etc. I'll have to look into the possiblities. Rolf Kalbermatter Well, at least until now, not so here Rolf Kalbermatter

This can happen with ActiveX controls. LabVIEWs control of them is very limited and in combination with Tabs there has been a bug in LabVIEW that made the ActiveX control not be aware that it shouldn't paint at all. On the other hand support for partial cover of ActiveX controls is very limited and that means that an ActiveX control in LabVIEW is either fully visible or not at all. Overlapping will ALWAYS result in the ActiveX control drawing over anything else independant of the Z order. Rolf Kalbermatter

Hmm, I never had my hands on the Lego Robolab development system but I believe that it is a special version of LabVIEW in such a way that the VIs are somehow signed to only work in the Robolab software. On the other hand normal VIs will also not run in the Robolab software, much like the limitations of VIs with earlier evaluation versions of LabVIEW. Probably not something you couldn't overcome with some digging, but well.. Rolf Kalbermatter

And you don't need a heating anymore ;-). But boy will that suck next summer with temperatures above 30 degree Celsius outside. Rolf Kalbermatter

Your comment seems a little harsh, but I have to admit that I'm not really understanding what the OP describes. Must be my poor English I guess. Rolf Kalbermatter

My functional globals almost always turn out to be intelligent globals to some degree ;-). In fact they are not really globals anymore but intelligent data storage containers. But I think Functional Globals pretty much covers all of these aspects. 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