Network architecture to send email?

So it is getting late, and I could use a sanity check on my understanding of how to set up my network.

I want my strategy to send a daily status email. The problem is my controller is currently only on the machine network, and can’t see the email server.

Each machine has an attached Windows computer running PAC Display that has dual NIC’s, one on the corporate network and one on the machine network. However, the PAC Display email functionality is sort of limited, sending only alarm points. Emails sent by a controller appear to be easier to customize, with more formatting and content control.

The primary ethernet port of the R1 controller is on the machine network. The second ethernet port is available. However, to wire it, I’d need to add a switch for the corporate network to the machine because there is only a single hard line dropped (connected to the computer). The existing machine network switch is unmanaged, so even if I had spare ports, mixing traffic in the switch probably wouldn’t be the best. The cost of swapping out the unmanaged switches for something better (VLAN support) would add up quick. Also, I’m already approaching the limit for simultaneous charts running in the strategy. Adding the email functionality to one already running would be a logical hack, but I don’t want to spend one of my chart allocations on a chart that will barely run.

Another alternative might be to run SoftPAC on the PAC Display computer to handle email requirements. If I want SoftPAC to see the tags in the controller to populate an email, what is the best way to do that, given PAC Display is also running on the same computer… OptoOPCServer? The computer’s resources are substantially used to run a vision inspection program, but if SoftPAC isn’t too heavy, that could be a clean solution.

Any thoughts? Wifi is not an option.

Current state:

[U]Machine network architecture[/U]
PAC Display Computer
R1 Controller+I/O modules on the rack
8+ TCP/IP or Modbus TCP controlled devices

[U]Machine Windows Computer responsibilities (right now)[/U]
PAC Display
Vision inspection (fed by two dedicated gigabit NIC’s)
FTP (for file transfer with the controller)
TightVNC (remote admin via corporate network)

How about installing an SMTP server on your HMI machine that could relay (smart host) the mail to your corporate mail server? I use hMailServer. This is more than just SMTP, but it shouldn’t take too much in machine resources - I run it on an 8+ year old laptop for some personal stuff.

Thanks for the suggestion. On further reading, if I wanted SoftPAC to act as an email controller, with access to tags from the R1 controller, OPCServer is not a viable bridge. The controllers (Soft and R1) could be programmed to read and write the necessary tags to scratchpad space and share information that way, or an intermediate scratchpad could be introduced as the go-between (OptoMMP Server). If all the information needed to populate the email was available from the I/O directly, mirroring would work, but it doesn’t give access to strategy tags. Because many of my devices communicate via TCP/IP, looking at only the I/O doesn’t give the whole picture. The Peer-to-peer thread is helpful (before it ran off the tracks on synchronization)

In other words, I don’t see a way to do this without modifying the strategy currently running on the R1, except maybe groov? It looks able to interact with the controller tags without any re-programming on the controller side. Is my understanding right? As I’ve been thinking through this, I’m seeing how beneficial it would be to build the reporting system without interrupting the primary function of the machine for debugging during development.

You can always use the Forth (see what I did there :)) to get the tag value from the R1 into SoftPAC. There isn’t any documentation for this that I know of, but Mary has posted here and there about it and has some subroutines for it. I’ve downloaded those subs a while back to try out, but have yet to play with it.

The goods are here:

Wow… nice find. Thanks!


If you’re okay writing a program in .net and can’t wait for new and exciting features, then another method you could use to get the data out of the R1 is to use the .net SDK that was released last year. It handles group reads of data if you have a lot of tags to poll. Once you have data in .net, then you can pretty much do anything you want with it. Obviously, this will take some effort to get done though.

BTW, how many strategy variables do you need to grab? From what I know of the RESTful interface, you will probably be able to grab a large chunk of your variables at one time, so if you have A LOT of them to grab, and this isn’t urgent, you may want to wait and see how it shakes out verses using the dark side of the forth.

I’ve actually taken down that “dark side of the Forth” example, since the COMING SOON RESTful interface will provide a better/simpler option. But philip is correct, the SDK is a good option especially if you have LOTS of data.

A RESTful interface to read tags? This day keeps getting better! I can wait, and will open each email from OptoNews like a Wonka Bar that might have a golden ticket inside.

Forum strangeness - sensij made his post last Friday, but it is now dated today and is after mstjohn’s??

A blow to the empire! Happy I downloaded it already! :slight_smile:

There was a wormhole in the space-time continuum. (And we’ve been fighting w/this OptoForum tool, which will soon be replace, maybe it knows??)

Here’s the full text from my post last Friday, since you’re paying attention:

Actually, I would NOT recommend using those subs (except in certain rare/exotic circumstances) ESPECIALLY since our new RESTful interface to the hardware PACs is coming very soon! The RESTful interface will be much simpler, and officially supported. Also secure so you could use it over the Internet!