Restore trends after restarting PAC Display Runtime

Every time the PAC display runtime is closed, then re-opened, I lose the trends that were already traced. Is there a way to restore this after a restart?

Diobado1,
You need to use SuperTrends to log to the hard drive. Look in Pac Display user guide for super trends.
If youā€™re using supertrends, make sure you have configured for combined real and historical. Then, if all thatā€™s good, then you simply need to click the little button at bottom of chart that looks like a file folder and it will open a list of files that have been logged and you open them one at a time and you can then get the historical.
Pac Display saves the data as per your config to files abd once you close Display, you have to open the logged files that have been closed. Check out the Setup tab of the SuperTrend setup.

Barret,

We are using supertrends and logs are being saved to the hard drive. The feature we would like to have is to be able to see the historical (at least to fill the trend time span) without having to open the logged file.

Yes I agree, that is a really really old whine for me.

Like the old paragon trendsā€¦ Those were pretty great. Configurable on the fly (add/remove pens, change scaling, etc.), actual combined historical and realtime dataā€¦

Oh so you were also an old Paragon guy too? Yes those were good 'ol daysā€¦that was my first system ever, 5 display workstations connected via netbui and eventually 2 - 486 PCā€™s running the processes on over 300 classic IO and 1 - LC4 out on the floor running a web process. That was funā€¦

Not directly. Iā€™m technically the ā€˜plant engineerā€™ at a cold storage. When I started (6 yrs. ago) it was running paragon controlling ~30 B1/B2 boards full of I/O plus a few Modbus RTU devices. I learned how to manipulate the program, but never got into the actual programming myself. A few years later I started setting up a Snap PAC system to take over the packing shed controls from an assortment of GE & Direct Logic controllers. The old programmer was slow to respond, hard to get onsite in a timely fashion, and expensive.

Last year we converted the cold storage over to Snap PAC simply for compatibility/replaceability. The Paragon control PC was on itā€™s last leg and my understanding was we were lucky to be running Win7. Well, if that PC died we would be SOL. Not a good situation with potentially $millions in product sitting in storage.

I still miss the Paragon trending. They were very powerful/configurable.

I was doing the Paragon thing back in '93 when it was unheard of to have a fully Ethernet networked control system, albeit 10 meg was still way better than 115k serial. Its amazing only 6 years ago you still had a working Paragon system. I still have some keys floating around hereā€¦
I had to tear down a 1000 block program and rebuild it completely and I had never even worked on a PLC or any control system before that.
It was way before itā€™s time because in addition to the overall sophistication including an SPC function block, you could build a process graphically and download it directly to an Opto22 LC4 controller, it was very cool. The LC4 had a ROM chip that you could get from Opto22 that had the Paragon programming in it. There was a version of Paragon that came along in their late stages that split up the CPU on a PC and created a separate OS environment that had direct connection to the hardware and was very very fast.
Ok, so you are doing the cold storage thing, eh? I have been doing the Cargill Turkey plant refrigeration system in Waco, TX for about 12 years. It was interesting enough, but working for Cargill has itā€™s issuesā€¦they are pretty much an AB shop now, mostly because of one mechanical outfit that installed a whole bunch of Opto over the years there and essentially screwed it all up. Of course Cargill did not help, because they are way too cheap to hire appropriately skilled techs either.

1 Like

I, too, wish the super trends would self-populate with the data to re-draw the graphs after a restart.

Back in the early '90s, I designed the hardware and wrote the software for a data logging, alarming, control, and automated report-generating system for municipal drinking water treatment plants. This ran under DOS, written in MS PDS ( Glorified QuickBasic).

I later wrote a fancier user interface and data viewing, report generation program that reads the data from that original system in VB6.

To this day, we still use this system at the plant where I work, and the logging and graphing is so much nicer than what we can do with OptoDisplay that what Iā€™m now trying to do is set up the opto systems to log their data in the same format as my old DOS data acquisition system so we can use the existing VB6 UI for viewing graphs and extracting data as well as generating our EPA-required reports, etc.

My VB program lets the user draw a selection box around an area in a graph, and it zooms the view to that selection, automatically scales the time and units legends, displays averages and totals for the selected area, and always lets you view the instantaneous values wherever you place the cursor, etc.

So the plant operators are always disappointed with the optodisplay graphs that canā€™t do these things. And, of course, they lose all of the previous data in a graph after a restart of their PCs and cannot view ā€œliveā€ data and data from before the restart together the way my old DOS data acquisition system does. My old program just checks for, and if available automatically loads up any available data from the last-saved log files when the program launches to fill in the graphs. If there is some missing data, it just puts in gray areas in the charts to indicate that the data for those points is missing.

I really love the Opto system in general, but I do wish the graphing and logging setup in Optodisplay was more sophisticated. Iā€™d share my old VB and QB code with opto if they could implement some of these features in optodisplay.

I hear ya brother, I agree completely. That is one spot where it needs some help. Some time back I thought about using ActiveX driver Opto has as a transport for all logging data into Excel and then use VBA to make come pretty cool graphing systems.
If youā€™re an expert in Excel charts, this could be a really cool system. Have you ever tried using the ActiveX driver? It works pretty good and pretty simple to set up.

Iā€™ve never tried the ActiveX driver. But that sounds like it could work for me. Iā€™ll have to look into it and learn what it can do and how to make it work.

Iā€™ve not used Excel too much myself. What I learned was VB6 over the years and got to be fairly productive with it. Some guys I worked with at a different job were masters with Excel and VBA. They wrote all of the user interface stuff for an enormous SQL Laboratory Information Management system in Excel/VBA. Weā€™d often share code back and forth, and it was great that VBA was almost identical to VB6.

I suspect that if the Opto 22 ActiveX driver works with Excel, itā€™d also work directly with VB6, too. So I should look into it, for sure! And using Excel might prove to be a very productive way to do a lot of this as well.

Yes well like I said, VBA is essentially VB6 with extensions into Excel. I built a spread sheet that I used VBA on and when Pac Control date and time script said it was end of month, Pac Control would execute Excel and it would open, then pull in a data file from Pac, rename it based on strings from Pac then save it as an excel file, the print a formatted version of the data out, and close itselfā€¦that really a simple example of what you could do.
Any the ActiveX driver is simple, you download the sdk kit and follow the instructionsā€¦essentially once you have it set up, you can receive and send data to Pac Control from any cell.