Hope there is a simple solution! Still a relative neophyte updating others code.
We have been operating our vacuum system using SNAP-PAC modules and code. We have been using Supertrends to record several pressures every 5 seconds. This has been acceptable, but we have much tighter requirements becoming effective soon and higher resolution is required during transition cycling. (Pumping down or venting.) The actual pressures are measured every 350ms, but this may be decreased to every 250ms.
I considered starting a timer when a transition event started and save the required pressures as well as the time it occurred to an array. Example: a 312 deep array covers 109.2 seconds, the longest time we take is 100. At the end of the cycle, trigger saving the array to a log file. However, I have been told that the array must be captured by PAC Display at a higher rate so it is available to be saved when triggered to be saved.
Is there a good way to do this?
How expensive (resource wise) is it to capture pressures every 0.5 seconds or 0.25 seconds?
I cant really set anything up here to test this myself, so I am just going to throw the idea out there and hopefully you can test it on your end easily…
I would use the PAC Display Historical Log rather than a SuperTrend.
It should have less overhead.
Do note that you will need to edit your refresh groups to add the times you need (you don’t need to edit group 0, you can make your high speed group the last one for example).
Now here is the test bit… do you store the data to the controller at the rate needed and then dump that out at the end, or do you log the data on the PC as the event is happening?
Duno. Both have pros and cons.
You could / should also think about the option of saving the data in a csv file on the controller and use an FTP program to pull it as required… That would save a lot of network and hard disk writes.
That is what I meant when I said “At the end of the cycle, trigger saving the array to a log file.” I meant a history using a Start Trigger and a sample of 1. However, that would mean sending the entire array every refresh time and saving the one in memory when the Trigger hits, I think.
I’ll read a bit on saving locally to a .csv file and upload periodically. I prefer that since our network is vey busy during operation and I don’t want to increase the load dramatically.
If you don’t have any FTP stuff on site, you can also have the controller email it to you (there is a PAC Control command along the lines of ‘email with attachment’).
Lots of options I guess is what I am getting to.
Lets know if you want to brainstorm some more.
The historical log will not request the logged data until the Start Trigger is true. With a sample of one, the data will only be requested once after PAC Display sees the Start Trigger. Obviously your logged data’s time domain is going across columns and the time stamp from PAC Display has less meaning, but there are ways around that.
You can also have PAC Display clear the trigger value using the Notification feature on the historical log. The Refresh Time for the historical log will not matter when only logging one sample.
The only refresh time that will matter is the one set on your Start Trigger. You would want this to be faster than the time between the end of one cycle and the start of the next.
