Rolf Kalbermatter

I had this same problem starting in November 2004 and going on until February 2005 when NI told me that NI-Serial 1.8 would be going to fix it but won't be released before second half of 2005. It took quite some time to get a prelimenary fix which came with the warning that it "might" fix the problem. Unfortunately it didn't fully and no matter what I tried including disabling hyperthreading in the BIOS did not help so we had to find an older non-hyperthreading machine and install everything on there. I haven't since bothered with that machine. Rolf Kalbermatter

This code looks a little hairy and I have no interest in trying to research what it does exactly. Just use the SMTP VIs that come with LabVIEW under Communication->SMTP Email instead. Rolf Kalbermatter

Wine won't allow you to access plugin hardware or such. So I think it is not a good idea. If you can't find a manufacturer that has native Linux drivers for its hardware, you have only two choices: Either you go with an intelligent external datalogger that interfaces to the PC over TCP/IP or serial and then you won't need to run Windows software in order to get it working, or you have a plugin DAQ hardware and then you need the according device drivers, but Wine can't be used as gateway for Windows kernel drivers and as I see their policy probably never will support a Windows kernel subsystem that could do that. Rolf Kalbermatter

They are very nice, but if you happen to have a Hyperthreading machine, you definitely need to install the latest drivers. We were having some problems begin of last year with those Enet-232/4 on a Hyperthreading machine after the older computer had died, and no matter what we tried we had to dust of some other non-Hyperthreading machine to run our application without intermittant crashes. It took about half a year before a new driver was available. However I haven't tested it until now, since the old machine is runnig just fine and I don't like to make modification to a running production system. Rolf Kalbermatter

Here it is, no guarantee that it works the same in LabVIEW 7.0 though. Rolf Kalbermatter Download File:post-349-1140707964.vi

Receiving email is done with the POP3 protocol (or some more advanced one). There authentification is always necessary since you can look into the mail box of a person. To send emails you are using an entirely different protocol called SMTP. SMTP is completely independant of POP3 and had traditionally no need for authentification before the sh*theads of spammers started to poisen email.I'm not sure where you got the POP3 VIs though, maybe the Internet Toolkit or OpenG, because LabVIEW does NOT come with POP3 VIs out of the box. The LabVIEW email VIs implement the SMTP protocol but without support for authentification. But since you get error 62 I think it is likely that you don't even get the the point where authentification is required but rather that a firewall or something like that is dropping your connection immediately. This is: 1) A problem most likely entirely out of control of LabVIEW, eg. your network setup. 2) Something you will need to investigate by debugging into the LabVIEW VIs (single step mode, etc. etc.) 3) By going into the email subVIs you can also see what the server is answering if any and only with that detailed information is any chance that someone else here can help you. Rolf Kalbermatter

What I did once in an application was using the enclosed VI. Use the alias array to initialize the strings of a Ring Control. Then use the selection of the Ring Control to index into the adress string array and pass this to the VISA Open. Rolf Kalbermatter Download File:post-349-1140556159.vi

Considering that the SMTP VIs are with full source code you could certainly go a little deeper and single step into them to see what the problem is. The SMTP VIs as they come with LabVIEW 7.x and higher work very good but have a few limitations. First they have no support for authentification. If your SMTP server requires authentification then you will have to look for alternatives. Second they can NOT make a hole into your firewall on their own, both on your computer nor some gateway on the way to your SMTP server. You will have to configure the firewall(s) to allow the SMTP traffic to go through. Sending SMSs is a completely different story. You can directly communicate with the GSM modem through VISA and the serial port but not every GSM modem has exactly the same command set. Also to get a reliable communication with a GSM modem that does always work independant of the initial state of the modem is quite some work. I have done it in an alarming and messaging application for Wismo GSM chip based modems (Wavecom and Maestro) and it wasn't trivial. Our company also sells a Toolkit to talk to these modems http://www.citengineering.com/pagesEN/products/sms.aspx Another possibility is to buy some ready to run SMS application and install it and interface to it through ActiveX, TCP/IP or whatever it supports. If your messaging and alarming should be reliable writing your own solution won't be a very straightforward and fast way to do it. Rolf Kalbermatter

But LLBs already used a moderate compression algorithme. Not as good as zlib but still around 15 - 30%. Rolf Kalbermatter

You probably tried to do some fancy datatype here. Just treat the handle as uInt32. In the Logon function this parameter is passed as Pointer to Value. In the CloseHandle case just as Value only since it is not a parameter by reference here. Rolf Kalbermatter

This was an addition to LabVIEW 6.1 exactly because you couldn't rename a Tab in a TabControl. Making a TabControl behave like a RingControl instead was no option as that would have caused problems with backwards compatibility and in fact removed some functionality and ease of use from the TabControl. Rolf Kalbermatter

Hey, don't tell me you have white hair! In my age that is something that comes to men naturally but for you I had thought that will take some more time :-) Good luck and may IVision still bring you some compensation for whatever you've put into it. Rolf Kalbermatter

First: GetIndirectFunctionHandle and friends were only meant and available for LabVIEW for Windows 3.1. Second: In order to call a function over a pointer variable, this pointer variable must be properly typed either through the declaration itself or a typecast at the point of call. Otherwise the C compiler can't know how to pass the parameters and what to expect as return value. if (!(UsernameCStr == (char *)DSNewPtr(*Username)+1)) {cinErr = mFullErr; goto out; } will allocate not what you think it does. It will use the pointer value in the handle as length indicator and attempt to allocate potentially a huge amount of memory running out of memory quite soon. You should make this read if (!(UsernameCStr == (char *)DSNewPtr(LStrLen(*Username))+1)) {cinErr = mFullErr; goto out; } and even better would be to allocate a cleared memory area with DSNewPClr(). Instead configuring a CallLibraryNode with advapi32.dll, LogonUserA, stdcall calling convention, the string parameters as C string pointers and the two constants as uInt32 and the last one as an uInt32 passed as pointer, simply should work fine. Last but not least you will leak a handle here with LogonUser returning the phToken that never gets closed. Rolf Kalbermatter Download File:post-349-1140011772.vi

I didn't now that you didn't know about LabSQL then. To me it had seemed the most efficient way to build on LabSQL and improve and extend on that one, seeing that you have mostly the same licensing philosophy as the original author of LabSQL. Would have saved you quite some time ;-). And improving and extending an existing Toolkit probably just as much gets you into learning the basics of it. Rolf Kalbermatter Why should anybody want to do that? Database Access over ADO works well, is supported on many more machines than .Net (.Net only working under Windows 2000 after installing an update) and most database drivers are either ADO or ODBC based. Using .Net would just add an extra complexity level to the already involved picture of ODBC driver->ODBC manager->ADO-ODBC gateway->ADO system->ADO->ActiveX interface. I can think of many better ways to spend CPU cycles, memory, and HD space. Rolf Kalbermatter

I can think of a few not so complicated runtime checks that would disallow the workaround found by Stan and if I can think of it, the guys at NI can for sure as well. If they find it necessary to worry about that one, I'm however not sure. Rolf Kalbermatter

While the registry might hold this number somewhere it is not terribly difficult to hook the registry access and return to a specific applciation different information than to the rest of the system. It definitely gives an attacker an extra angle to get in, and if you consider HD serial numbers not secure enough you must envision a dedicated hacker and not just the joe average user that knows little more than how to start an installer. Of course you can even fool a tool that gets the information directly from the BIOs but that really requires some assembly and protected mode knowledge, although that knowledge is not something strange among real hackers. Rolf Kalbermatter

Id2x I have just a question? Isn't LabSQL (and incidentially the Database Connectiivity Toolkit from NI) not also using ADO? If so what does your solution add to this? Rolf Kalbermatter

What has this to do with the original post? Thread hijacking is not nice! Rolf Kalbermatter

I for one don't but I happen to have played with the functions in LabVIEW 7.1 recently and probably come across a possibility similar to what Stanislaw has done in his other thread where he handed us the ladder to reach the toys, NI in its universal wisdom had put on a very high shelf. But I also can envision that NI might try to close that loop hole too, putting even the execution of certain nodes behind the licensing. Rolf Kalbermatter

Yes, scripting is now not anymore controlled with an ini file setting, but through the license manager. (In fact it seems LabVIEW still wants to have an ini file setting but it will only check this setting after you have installed a valid scripting license, and no it is not the same ini file setting as in the past :-( Rolf Kalbermatter

The MAX API is private and undocumented. Nobody outside of NI can write drivers that integrate with MAX directly (aside from the standard OS drivers such as COMM for serial ports) that integrate in MAX. I doubt that there are many manufactuerers that have such an integrated and feature rich configuration interface for thier hardware as what you get with MAX. Rolf Kalbermatter

Not exatly sure as it is a long time ago when I investigated scripting. But if my memory serves right you will have to walk through the rather large LabVIEW object hierarchy to get to the wire in question and then using a Method (or was it a Property) node you can set the breakpoint on that wire. As to how to walk the object hierarchy of a VI, there have been several examples here on Lava but it is a pain indeed. The problem is, I can not see another possibility to implement this object model in a way that would be much easier to walk and understand without loosing tons and tons of possibilities. Personally I think this is the main reason NI has not decided to make this feature available to outside people since they can envision a load of support requests if that feature gets made public. Rolf Kalbermatter

I'm posing a possible explanation to the problem. It seems that your error message contains a path that is only partly complete (breaking at the space in National Instruments). Obviously at some place the path construction is not done correctly and if you pass a path to a command line tool containing spaces and that path is not embedded in double quotes the command line tool will see the path as multiple command line arguments resulting in each argument to be an invalid path. I wasn't saying that this is something you did wrong but that it is something with lvmetadiff and or other tools involved. Since they are however all Open Source and available in source code there is no reason why you shouldn't be able to go and try to fix the problem for yourself. Rolf Kalbermatter

This won't work. The CIN node or shared library is still running in the application context and as such has no direct access to the protected kernel resources to whom the Port IO adresses belong. You have to extend your kernel itself to allow port access either by a port IO kernel driver that translates your port access requests to the actual hardware access on behalf of your application or by an expansion to the kernel with a system call to manipulate the IO permission map. In the first case you call your device driver and pass it the IO adress, access mode and data and it does then do the actual port read or write for you and in the second case you do a system call to that new kernel function to tell it to modify the port IO permission map for your process to allow direct access to specific IO adresses from your application process. Rolf Kalbermatter

An IMAQ runtime is