Bug? SMTP send hangs LabVIEW

[Joel-I]

Hi Matthew,

Can you link the example you're using?

Regards,

[Dionay]

Hello,

Have you found a solution ?
I send emails for several years with Labview and I have always been forced to correct their SMTP functions that contain either an infinite loop if the server does not give the correct answer, either TCP functions with timeout equal to -1!

To believe that the SMTP functions are made by beginners. Today NI found the solution ! 2013 version could not be more correct their code , you need a password. Yet the huge bugs are still there. This is a real step backwards , but what ...

I think we can afford to hide a code when it is robust and foolproof, but unfortunately this is far from being the case, as they have absolutely not considered a SMTP server (or whatever) just send that one does not necessarily expect him .... the basic programming !

I hope developers will read this message NI , because I have the deepest respect for this company for over 20 years , but sometimes it's really pissed , it seems that s' really away from the heart of business .

Alain Carbonnel
Technical Director
Elit'Concept
France

[PhillipBrooks]

I've never had problems using the NI SMTP Send, but at my previous employer we were only using LV 8.6 and Windows XP. Our SMTP server was internal.

I haven't looked at the 2011 implementation, but my new employer requires email authentication, so I would probably use something like this:

Gmail using LabVIEW 

The title is a bit of a misnomer, the VI should work just as easily with any SMTP server that requires authentication. The only drawback is this uses .NET which limits it's use to Windows.

[Dionay]

You just said your server is internal. This operation is a case study , but it is not the ground.

In applications that we develop for our clients, emails are sent to transmit data or alerts directly online.
Internet connections are via dialup or DSL , or satellite. In fact as soon as a means of communication does not correctly answer the system switches to another .

These connections are made at least 2 times per hour , and it should work in any country .
We have no room for error , unless it comes from a provider.

The developers at NI SMTP functions are not faced with the reality on the ground , they do not have access to them and it would take too long. Result , they develop with an SMTP server on the local network or very good network connection .

All I can say , supporting evidence is that the SMTP functions Labview 2012 have nothing robust and are buggy . Even the function that returns the list of recipients allowed, does not work due to a misinterpretation of the SMTP error code !

Labview 2012 until we have corrected all the SMTP functions provided by NI . Since the 2013 version of Labview can not correct the SMTP functions , and I can assure you they are buggy .

All this is really damaging to Labview community because we did not ask better than to participate see bug fixes for these functions. But the policy of NI exchange .... what good is it to provide bogus functions by preventing developers to correct them and make them available to the community ?

I forgot, of course we know the solutions net, but it is not reliable enough and far too dependent on Windows.. If you want a flawless operation, foolproof, configurable, providing all traces of desired activities: one is never better served than by oneself. But again, this is to the detriment of the community.

Very cordially.

Alain Carbonnel
Technical Director
Elit'Concept
France

[Dave_Thomson]

   I'm seeing the same problem originally posted in this thread.  LV 2013 32bit on W7-64.  I have the email sending VI in an independent loop.  I've tried setting it to a different priority and a different execution system.  I've tried setting the other loops in my program to different priorities and different execution systems, all to no avail.  Sending a two line text e-mail with no attachment is hanging every LabVIEW loop for 3 to 6 seconds.

   I don't see how this is just due to a blocking dll, since putting it in a different execution system/thread should resolve it.  Even if it is in the user thread, putting other loops at a high priority in other threads should keep them going, but it doesn't.

   The one thing this reminds me of is when you try to do a print screen programmatically in LabVIEW.  When the OS is connecting to the printer, all of LV can hang.  (Or at least it did several versions back.  I've avoided doing this for years now.)  So I'm wondering if this is due to some call to an OS resource.  I would have guessed that NI would have written their own TCP-based primitives for sending SMTP messages, but maybe they're just connecting to something in Windows?

    If Matthew can post a link to the alternative method he found, that would be great.  I've done a search and hadn't found anything that worked with authentication before.  I upgraded this project to 2013 partly just so I could use the new NI SMTP functions that support authentication.  I've tried the GMail example already without luck too.

Thanks,
   DaveT

[rolfk]

I wouldn't really call the SMTP VIs that use the SMTP Client VIs native. They obviously make calls to a DLL quite early on rather than using the native TCP nodes. And that is most likely also the culprit here. Either the call to the SMPT Send method in the Call Library Node is set to run in the UI thread, or the DLL itself is somehow blocking the UI thread for whatever reason. Since the SMTP Client VIs are password protected I can not check which of the two things is the problem, but most likely it is the Call Library Node in there.

But quite likely just chganing the Call Library Node to not use the UI thread is going to cut it, since the underlaying DLL may not be written to be thread safe.

[Matthew_Kelton]

Dave,

I had forgotten to come back and post an example that demostrates the problem.

I believe the code i used was based on code found in this thread:

http://forums.ni.com/t5/LabVIEW/ogic-smtp-library-example/td-p/454028

I had to make some modifications.  I think most were cleanup of code, but there were one or more bugs that affected my email server.  I think the main one was that the original code did not work with a server that required authentication.

Matthew