Rolf Kalbermatter

You do not want to disable unreadable characters but instead go in a while loop and abort at the first occurrence of a NULL character and then resize the byte array to this length - 1 and then put it through a Byte Array To String node. The string in there is a zero terminated string, as all C strings are so and once you encounter \00 it is over and the rest is only garbage that happened to be in memory before the function filled in the information. Rolf Kalbermatter

I'm not 100% sure but I thought the earliest version that had Save with Options->Save for previous version was 5.1. So there would be a problem to go back to 4 with this feature. On the other hand the only reason not to upgrade to a newer version would be that your driver is in compiled form without diagram. In that case and I'm sorry to say it, but you are in deep shit. Rolf Kalbermatter

If the data is in binary form already there is no need for any conversion. Just use a Typecast function to change the incloming string into an array of integers. Hopefully you are using Network byte order because that is what the Typecast function will assume at the incoming stream side. Of course you could write a C code function to receive the data and get it directly into LabVIEW as an integer array and if the data is in Little Endian format this would get rid of the inherent Byte and Word Swap in the Typecast function but if receiving the data already is the bottle neck, that C function most likely won't be much faster than what you have now when receiving that data as a string. After all 50MB is not peanuts for a PC system and typically will require several tens of seconds to be transmitted over a 100 Base TX connection and only slightly less when 1000 Base TX is used, loading the system CPU as well considerably during this time.

In FIrefox you simply click on the picture to toggle between the scaled version and the unscaled one. Rolf Kalbermatter

It depends on the LabVIEW version. Before version 7 you had to close every VI server reference to avoid leaking memory. Since version 7 you only have to close VI server references that you explicitedly open with an Open function. But LabVIEW is forgiving if you try to close VI references you retrieved from property nodes for instance and recognizes that that are owned references and does nothing on them. So as a matter of fact I usually still use the Close Reference function on all VI server references independant if they are explicitedly or implicitedly opened VI references. Rolf Kalbermatter

I haven't tried this but if it does work then of course only with Rosetta. Still there are a myriad of things that might go wrong. Forget probably about any DAQ or other hardware IO other than standard OS channels such as File IO, and hopefully TCP/IP and serial. Maybe I try to find one of those inofficial MacOSX86 development installations and see if it would run on my Sony notebook. 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