I am currently using LabVIEW 2012 and my application is to FTP files from a cRIO and sends it through an email using the NI_SMTP send file VI from a TPC-2212 device. I am using both ports of the touch panel, the first port is to a internal network which speaks to a cRIO through a data stream. The second port is plugged into a wireless module and is the port I will be transmitting the emails through on the company mail server.
I have managed to achieve what I want but I’m running into timeout errors on both the FTP and the SMTP VI’s. When I attempt to send an email from the wireless module, I’ve found after a few minutes I receive error code 56 which is due to a timeout. I’ve found that I’m able to reinitialize the SMTP if I physically unplug the network cord or cycle the wireless module but my desire is to reset this system through labview.
I’m getting stuck trying to clear this error without resorting to resetting the wireless module. The following shows my code and a description of what is happening.
The email file is sent through a feedback loop to act as a rising pulse and is ANDed with the following conditions; the system needs to be connected to the cRIO, an email must be selected, a file needs to be selected.
In the following section I’m able to trap the errors based on the code and what I’m attempting to do is force close the session. I’m using a open session to give me the connection ID but this was really a shot in the dark attempt at fixing the issue.
As for the FTP session on the cRIO, I have experienced an error 66 but not as often as the SMTP error. Because the two seem to overlap closely I figured I should mention it here too. I’m also curious as to how to clear this error if my network stream is still functioning well.
Thank you for any replies!
I am also seeing the 54 error. This is once again cleared after I reset the wireless module. I'm starting to wonder if the wireless module was set up correctly or being on port 2 of the HMI is having a effect.
Actually let me add error 54 to the error trap and see if force closing the network will make any differenece. I mean I get the system to email for a short while...
The attempt I made to trap the 54 error didn't workout. Once again the only way to clear this error is by resetting the wireless module.
Have you considered trying to use the SMTP VI's directly to:
1) Open Handle,
2) build message (many sub steps: set recipient, set message, set attachments)
4) close handle.
(This may be more or less whats happening in that "one size fits all" VI that you show in your jpg picture that sends the e-mail? Can you open and share the block diagram of that VI?)
If you make an "engine" or module that does these things, you can more readily expand on fault recovery and fault tolerance scenarios by trapping and handling errors internally to your own SMTP module. For example, if "Send" returns a time-out, you can optionally choose to retry the transmission a max of "n" times, and/or you can "close handle" and start over from 1) in the list above, or maybe even a combination (re-try 2 times, if still error, close and start over). Depending on how you set it up, and other requirements, you may need to also build in a max number of retries on the "Start over" before it simply gives up and tells the user it can't send the message.
You should strongly consider splitting out your user interface code from the actual smtp/ftp/other stuff code. I would probably consider a simple Queued State Machine that I would think of as "SMTP Engine" that you can send requests to, then it attempts to send messages in the background, that way you stand much more feely to expand with various features as you need them (such as automatic retries) without locking the UI.
Caveat: I have 2013 installed, I can't remember if the smpt palette changed significantly between 2012 and 2013?
Thank you for responding and sorry for the late reply. I took your advice and created a state machine capable of performing an FTP to the cRIO based on data needed and then emailing out data as need be. This system also performs an error recovery which will perform a ping to the network under an email error to try to reconnect to the server. It monitors a queue file which will record the type of email that needs to be sent out. For example; if the user needs a statistics file of the system on a specific day, the item will be added to the queue and directed to the appropriate data file needed.
For the ongoing issue that I was experiencing with the wireless module, after I built the e-mail state machine as described above, I presumed the issue of the server timeout would be irradiated. This however, was not to be, as the system once again timed out after a few emails. For testing purposes, we set up the machine to FTP an arbitrary piece of data every ten minutes and email it out. We then connected the HMI directly to the server bypassing the wireless module which worked great. We then decided to change the original wireless module with a USB wireless module to try and narrow down the issue. With the new USB wireless module, the system managed to perform emails flawlessly, over two days
As of right now, I am working with the companies IT and the manufacture of the wireless module to determine what could be the issue. Once we have determined the issue I will post a solution. However, I can move forward with the project.
I have one more issue with the FTP error 66. Digging through the FTP close function, the error 66 states that the connection was closed before the FTP command acknowledged the QUIT command. I thought I could solve this by performing a manual close by opening the FTP server again using the FTP Open Session then immediately closing the session using the FTP Close Session. This however, didn’t seem to fix the issue. I’m going to keep digging to see if I can work out how this issue can be resolved. The problem with this error is it is quite irregular.
Thank you for posting this update, I would be interested in how it all plays out in the end for sure.
Not sure if you can or want to share, but what is the make and model of the wireless module you keep refering to?
-Also, and just in case you are exploring alternate transfer mechanisms: I recently (2 days ago) found and proved a memory leak when using webDAV "put.vi" to transfer files FROM a cRIO device. I only have vxWorks devices so while I was able to prove the leak on two different models, it is possible this is a vxWorks issue only.. I'm working this issue with NI support. WebDAV can offer some pretty significant benefits vs FTP file transfers (part of http protocol, fewever/no firewall issues, client IT staff happier about port 80 or 443 vs port 21, option to do transfers as https encrypted streams, Windows (xp and later) comes with basic webDAV server from MS vs 3rd party ftp server, etc. etc.), however, my experience with it on the cRIO indicates possibly higher CPU cost (hard to meter since the cRIO FTP server is not running in our code scope, but the WebDAV client transfers are, so getting an accurate comparison is difficult). Also, the error messages are a bit cryptic and lacking in detail and some behavior is unexpected, such as "open session" not returning an error if the remote server is not available (CAR# 494409, use "Get Path info" to test session as it will error out (56 timeout) if server is not available).
Thanks again for the reply. I'm still working with LabVIEW 2012 at the moment and I'm not sure if WebDAV is avaliable for use. You're right though it does look a lot more reliable way to transfer files. It will definately be something to look into when I update.
Sure thing. The wireless module we're using is a Phoenix Contact 2701169 with a 2701362 antenna.
Interesting, I've never had any issues with Phoenix gear in the past, but that said, I also have not used any of their wireless products, just the occasional mGuard (for office to deployment site VPN tunnel) and wired switch series (the 2891003 FL SWITCH SFNT 5TX to be exact) due to the wide -40 to 75C operating range that nicely complements the cRIO).
[EDIT] WebDAV became available with the RIO drivers for LabVIEW 2013, that said, I would think the VI's for webDAV are installed alongside the drivers? -maybe not, but if you use newer RIO driver versions, you may already have them on your pallete. Note that NI supports 3 versions back in the drivers, so you should be able to use the later drivers even with LabVIEW 2012, so I think that means you should be able to use the latest RIO drivers even in 2012, though please check me on that before you install them. 🙂