Historic Log File with only one sample

PAC Project
1

I want to have a PAC Display project write an historic log file every 30 seconds containing the latest values for a number of variables.

Every time the file is written, I want it to overwrite the previous file so that at any given time, this file (if it exists) will contain only one “line” of data, that data being the latest values for these variables.

The purpose of this file is to allow a separate program to look for, and read (if the file exists) these latest values without needing to scan down through an ever-lengthening file to find the last line and read that single line’s data. So naturally, this file needs to have the same filename every time.

This seems like it should be possible. I do it in Visual Basic in a number of situations as a way to transfer information over a network. But I just can’t figure out how to do it within Pac Display.

All I’ve been able to do is have it append to a file that gets longer and longer as new data is added with every “trigger”.

There’s probably something easy I’m overlooking.

Thanks everyone!

Jim

2

Something like this rewrites the file every time it runs. This is creates a file on the control engine that can then be transferred or read remotely. See Pg 276 - etc. in Doc 1700 “PAC Control Users Guide”.

OpenOutgoingCommunication(File_Comm_Handle);
SetEndOfMessageTerminator(File_Comm_Handle, ",");
TransmitNumTable(20, 1, ftRoomControl_Temp, File_Comm_Handle);
CloseCommunication(File_Comm_Handle);

file

3

That looks promising.

I was trying to do it out of Pac Display so that it would write the file directly to the HDD in the PC on which Pac Display is running. The main concern I have with constantly overwriting a file in the control engine is that this may be writing to flash in the controller, and with the finite write life of flash memory, it might wear that flash out very quickly. I want to have a new file every 30 seconds to keep the data up to date.

I’ll read up, though. It may be that what you’re suggesting would write that file to a remote PC over the ethernet connection. And that would accomplish exactly what I want. I’d just be programming the PAC Controller to create the files directly instead of relying on PAC Display to do this.

I will read that section of the manual.

Thanks!

4

Files are stored in volatile memory- if the power fails, or you restart the controller, you lose the data. So there will not be a flash wear out issue.

For those that want the files to persist, they have to call the SaveFilesToPermanentStorage command.

5

Thanks! That’s just what I need. Because these files will be read and then obsolete almost immediately, there’s no need for these particular files to be stored in any sort of non-volatile memory. I still need to do the reading once I get back to the site where this system lives.

I’ll need to write some code in VB or the like to interrogate the controller over ethernet, or I’ll need to set the controller up to write the files over ethernet to the PC that actually needs this information.

Thanks again.

6

The controller is an ftp server, so you can just access the files via ftp if you like.
As for the controller writing to a network drive. No. It is not a SAMBA server, so that is off the option list.
(Unless you use SoftPAC, in this case, it would be worth looking at for your file server - because it runs on the PC, it can see all network drives).

7

I really appreciate the help and suggestions.

The first thing I need to do is get all of the brains and controllers updated to the newest firmware. Then I can begin to use the new PAC Control and PAC Display software and some of the new features with this system. That will mean moving from the XP machine currently used for this work, as well. :wink:

One serious concern in all of this is security. I’m actually considering using an RS-232 module somewhere in the Opto system to just periodically transmit the data in question across to a PC that is on the network that is exposed to the internet. That will provide an impenetrable barrier at that point since there won’t be any way for any kind of hack to move data to the otherwise isolated network that the Opto system uses.

It’ll just be a one-way path. It’s easy to create serial communication code in VB to receive these data dumps and then write that out to the sort of file I need, right there on the PC in question. Perhaps I can learn enough Opto Script to do the transmitting side of things easily, too.

That’s kind of a brute-force way to achieve the security, but I can’t think of any way that sort of setup could ever be breached from the outside since the Opto end of things would never even look to receive any data over that link.

8

What kind of controller are you using? The R and S controllers both have onboard RS-232 capabilities - no module needed.

You could also put a second NIC in your PC to run on the Opto network if you wanted to maintain ethernet access to your devices without them being “on the internet”.

9

We’re using R1 and R2 controllers. And they do have RS-232 built in, but I got a bunch (like 20) of the RS-232 modules when we dismantled six brain/rack setups that an outfit was using purely to do distributed RS-232 interfacing. So I was planning on using one of those modules because with RS-232 being directly wired, rather than having any sort of transformer isolation (the way Ethernet hookups do), I’d get the electrical isolation of the module to protect both the Opto end of things and also help protect the PC end of things in the event of nearby lightning hits and such.

I’ve seen far too many PC motherboards cooked by the differential between ground points during transient events (mostly nearby lighting hits) when people directly connect RS-232 between PCs and/or various gadgets that aren’t, at the least, plugged into the same outlet or outlet strip. This has been especially true where folks connect a PC in an office to a CNC mill or lathe out in their machine shop. Everything is dandy until a thunderstorm, and then poof. Both the PC and the machine’s RS-232 interfaces get popped.

So using the module is just a way of having that electrical isolation (which I’m not sure exists if you use the RS-232 built into the controller). And if I do lose one of these modules, I’ve got 19 more of them laying around that I probably will never need for anything else. :slight_smile:

I do have extra NICs on a couple of the PCs I use. I’ve just used external Ethernet interfaces that plug into USB ports, and they’ve worked very well. It’s nice to be able to have both our office network, which is exposed to the internet, and the OPTO systems’ networks available on the same PC. But I still worry that having a PC that is connected to both the internet-connected network and to the OPTO network might provide a route of attack. If the PC gets a virus, why wouldn’t it be able to spread to all of the networks to which the PC is connected? Ever since stuxnet showed what can be done, I’ve had worries.

This location is a municipal water treatment plant (drinking water plant). We try to make things as secure as possible.

While the RS-232 method is crude, slow, and without a lot of capability, that is actually all I need for this, and seems like it would be completely bomb-proof in terms of someone being able to hack into the OPTO side of things. The beauty, for me, of the RS-232 setup would be that it would be incapable of doing anything except what I explicitly program it to do - in this case, transmit data only, from the OPTO side. It won’t even know or care if the blasts of data are received by the PC side. And I’ve had excellent luck, in the past, with the serial comm tools built into VB. So I feel comfortable with the PC side of a setup like this. I’d just have to do some learning to be able to do serial port comm with the Opto gear.

I might be being too paranoid, but the truth is that when it comes to the ethernet connectivity of all of this, I just don’t know enough about all of it to be certain that I’m not leaving some means of access unguarded. With the serial setup, I’m more confident that there could never be any way for a bad actor to gain access between the internet side of things and even a separate network when both are running on the same PC. It always seems like things we believe to be secure are found to have vulnerabilities that need patching or require us to take additional measures.

Back in the days of DOS, I felt like I actually had a decent grasp on most of what went on behind the scenes in the OS, the hardware, and everything down to the register and bit levels in the PCs. Ever since NT and beyond, I have no confidence at all that I really understand what’s going on behind the scenes. And I get the feeling that there are no individuals who actually understand it all. We just learn the bits and pieces that we need to make things work, and have to take it on faith that everything that supports what we do is solid and secure.

Too much information, and off topic, I guess, but that was just to explain why this serial port business seems somewhat attractive to me.

I do need to learn a lot more about the whole OPTO system and its inner workings. As with most of what I end up doing, I never seem to have the time to delve into any aspect of it deeply enough, so everything I do is based on my weaknesses and lack of knowledge. I make things work, but never feel like I know enough to do things the correct, or even easy ways!

I should take some sort of Opto-22 training. I just hammer away at things and try to get the bits that I need right then to work, and then move on to some other fire that needs to be put out! :slight_smile:

So I do appreciate all of the help you folks give me on here. It’s great!

10

I’ve read that this is most likely due to the manufacturers silly requirement for the CNC machines to have their own ground rod. So the PC is connected to the buildings ground system, and the CNC is connected to a ground rod at its location, lightning strikes nearby, and all of a sudden there is a million volts between the two grounds - difficult to survive that.

Your logic with regards to security is certainly sound. Good to see someone thinking about security like this!

Sending data over serial is relatively simple in Opto (open the port - send the data). Not sure if you have used the serial modules before, but be aware that the serial modules are really IP to serial gateways of sorts - so you will open your comm handle as if it is a TCP (or UDP) connection. Also, be aware that any device on the Opto network can do the same (You’re still using ethernet when using a serial module!) Since you are keeping your Opto network isolated, this should be fine - just don’t forget to have physical security on all your Opto and network equipment.

I think you will do fine - just document your “protocol” so the next guy/gal has a fighting chance of figuring it out.

1 Like