Rolf Kalbermatter

PICT is an old vector graphic format used on the Mac. LabVIEW supports PICT directly and can import them and use them and I do believe PICC is a similar but a little bit modified format for LabVIEW's native internal vector graphics. Rolf Kalbermatter

NI has an OCR add-on to IMAQ Vision. That works usually quite well. But: even with the best OCR software the biggest problem often is to get an image that has enough information to allow a software program to analyze it. Things like cameras used, and even much more important the lighting conditions are often the part where you will spend more time with experimentation, than getting the program to analyze the data and do something useful with it. Rolf Kalbermatter

IMAQ Vision comes to my mind here! But, to display the image it has to be decompressed and it for sure will use a lot more than those 1MB it takes on disk. Rolf Kalbermatter

As has been already mentioned in some ways, Toolkits installed (especially those that add a nice icon to the startup splash screen such as DSC, RT/FPGA, or IMAQ will cause LabVIEW to load additional VIs in the background that take up time too. So a clean LabVIEW is quite a bit faster in starting up than one that is loaded with every Toolkit there is. And a dirty Windows system partition certainly makes a huge difference. LabVIEw depends directly or indirectly on a lot of system libraries and they all have to be loaded and mapped into the process space of LabVIEW before LabVIEW can start to even initialize itself. A clean Windows installation will always startup processes significantly faster than one that has been loaded with 100ds of small little shareware programs, games and other little gadgets. Not to mention of all those little programs that show up in the status bar in some form or the other. A new installation of Windows is in general necessary about once a year unless you use your computer exclusively for one specific task and are not installing and uninstalling all kind of software frequently. Rolf Kalbermatter

Why! Just make sure you add those dynamically called Vis as such to your build script or Project. Or as alternative if you do this for plugin VIs that should remain outside of the application make sure you compute the right path when trying to load it. Of course there is the possible problem of plugin VIs using subVIs that were getting out of sync with the same named VIs used in the main application. This can be managed a little easier by using an All Project VIs.vi that contains all the dynamically called VIs as well as the main Top level VI. For editing the project you load this All VIs VI but you do not include that in the application build at all. Rolf Kalbermatter

No, it won't be possible. ActiveX is entirely based on COM/DCOM and that is one huge subsystem that has not yet been implemented by anyone outside of Micrososft. Wine as a project is trying to do that but they are still quite a stretch from a near full implementation. The only implementation of COM/DCOM I know of that has existed at least in the past outside of MS, was a DCOM implementation for Unix systems from Software AG. They had licensed the relevant code from MS and ported it to Unix and sold it for quite big bucks as a solution for big integrators doing banking applications and such. Not sure this is still maintained or sold. .Net is yet another rather huge subsystem that is probably build in parts on technology from ActiveX too. Trying to integrate both COM/DCOM and/or .Net in a RT system is IMO a rather useless exercise. Many things would interfere with the RT nature of the underlying OS and render it more or less to a "normal" OS. Also the foot print of the OS itself would get bloated extremely and would increase the cost for additional system resources. I think that if you do need COM/DCOM and/or .Net for something, an RT system simply is not the right choice for you. Rolf Kalbermatter

And what would be the problem with that? Move works both for files and directories. Move is simply the logical combination of Move and Rename into the same function. If a move happens on the same volume, the file data is not moved at all, but just the directory entry is changed. If it is on different volumes, rename would simply fail and move will correctly move the file or directory. This is how the modern OS'es do it at least and the old DOS rename and move functionality are just remainderes of a time when disk management was a lot more complicated and still had to be done partly by the application using it. The according commands in the Command line shell under Windows are simply built on the OS functions and written to emulate the old behaviour eventhough the OS functions underneath would be much more versatile. Rolf Kalbermatter

Either your TCP/IP address/name is not valid, your email server is not setup to listen at the standard SMTP port number or your network setup does not allow LabVIEW to connect to the computer where your server is installed. error 56 means timeout error so LabVIEw sends out a request for computer xy to accept a connection at port zz and never gets a reaction from there. This definitely is an error completely outside of LabVIEW. Try to ping the computer your SMTP server is installed on with exactly the same TCP/IP adress/name. If this doesn't work your address is wrong or a firewall disallows the traffic. If pinging works then again a firewall may be the problem disallowing specific traffic such as through SMTP ports or your SMTP server is not running or it is listening on another port than the standard port 25. Rolf Kalbermatter

That of course works if you use the standard analysis functions that were already available in earlier LabVIEW versions and as long as NI didn't change the actual function call itself. It won't work for newer analysis functions added in the latest LabVIEW releases or functions where NI added an extra parameter to support new behaviour. As mentioned just for a Mean calculation doing it in LabVIEW is actually faster, and avoids the external DLL/shared library ;-) Rolf Kalbermatter

LabVIEW has its own window manager building on the native window handling API of every respective platform. Most probably LabVIEW does maintain its own size attributes and also does some specific clipping on its own to increase performance or work around certain difficulties on some platforms. A lot of those manager functions are actually exported by LabVIEW (with the prefix W) but totally undocumented. For instance void WMove(Wind h, int32 h, int32 v); moves a window around and void WSize(Wind w, Rect *bounds); sizes it. The type Rect is documented in the extcode.h file. The difficulty is that the parameter Wind h is a specific LabVIEW datatype and does only indirectly correspond to the underlying platform datatype such as the HWND on Windows. LabVIEW seems to store this Wind handle at the 0 offset of the additional window specific data in the Windows window handle so doing: typedef void *Wind; Wind h = (Wind)GetWindowLong(hwnd, 0); should work in all Windows versions I have seen, but of course this is highly under the hood, undocumented and suspect to changes at any new LabVIEW version. Rolf Kalbermatter

But drag and drop from outside of LabVIEW is a big pitta to do right. An applciation can provide whatever format it thinks is right for the data and the receiver can only try to ask for another format but essentially has to deal with what is provided and that means a lot of potential conversion types. Asking for the disk path only is rather useless for anything but a path control and asking for the real data can give text, and image, formatted data etc. etc and then it is a big task to figure out how to convert that data to something you could use. Even more complex is the fact that Drag & Drop should work not just on Windows and with MS Office applications only but on MacOS, Linux and Windows with just about any applcation. This means that Drag & Drop events would need some multiplatform D&D manager in LabVIEW, which probably isn't fully there yet, and the D&D events will give you a somewhat complicated interface where you have to handle the recursive query of specific data formats until you get one that is provided by the data source and its conversion to something more suitable eventually. Rolf Kalbermatter

It is a good idea to always close any explicitedly opened refnums! Rolf Kalbermatter

Greate advice Warren! I second your warnings with the strongest possible meaning. Motion Control is not something you can do insecure at all. After all a finger is lost way to easily and for bigger motion systems worse things can and have happened. Rolf Kalbermatter

Are you now using the standard SMTP VIs that come with LabVIEW? What error do you get? In what low level VI (connection, when writing which command, when receiving after which commmand)? What LabVIEW version, which OS version, what email server,...... ? 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