Use of MS access in Process control. (1 Viewer)

[mahenkj2]

I am just curious if an Access database could be used in process control equipments. Say, capturing some signals from sensors, recording etc.

If MS access as a whole is not preferred then could it be used with some other platform.

Being a process guy, just wants to make use of Access as much as possible.

Thanking you for any thoughts.

best regards.

 

[jdraw]

Interesting question.
I did quick google search and found this
http://www.manufacturing.net/articles/2012/07/expert-panel-automation-&-process-control

 

[ChrisO]

Process control is too large an area to make any definitive statement.

In general and to the point of control, Access is not suitable.
If we can break the question down to monitoring a process the answer is probably no.
If we can reduce the question to reporting on a process the answer is yes.

In their simplest form…

Control:
defined as a process input, algorithm and direct process output in a continuous loop in real time.

Monitoring:
defined as a process input, algorithm and output to something other than the direct process in a continuous loop in real time.

Reporting:
defined as using already gathered data, algorithm and output to human users not in a continuous loop and not in real time.



The definitions of control and monitoring may not be strictly correct and in fact may overlap in many cases.

Monitoring, for example, may simply be an alarm condition which is output to human users but does not directly affect the process. If the monitoring produces a process trip then it should be regarded as a control not a monitor. On the other hand, monitoring may involve taking time based analytical samples of the process and adjusting process setpoints to effect the process. This latter description of monitoring the process does not directly affect the process because, if the monitoring stops, the process should use the last setpoint supplied. (Jargon, but the process flunks to the last known valid setpoint. Even down to a thermocouple junction this may apply. Most thermocouple inputs have an upscale or downscale burnout setting. If three thermocouple inputs are feed to a median selector then the correct temperature can still be used even under a single fault condition.)


The point is, though, that reporting is not required in real time and indeed has no direct connection to the process, read or write.

I think it is important to understand something about Access here. Access is not a stand alone program; it is running under what may very well be described as a dirty environment. People may have Word, Excel, Outlook, Internet Explorer and many other programs the user may have downloaded and have open at the same time.

Who really knows under what environment Access may be running? Without the knowledge of the environment, I think it best to assume that Access is running dirty. This is in no way a fault of Access or even Microsoft; it is a fault of the openness of the system.

So, to use Access for process control or monitoring, no.
To use Access for process reporting, yes and I have on two different jobs.

Chris.

 

[The_Doc_Man]

My first "real" job was in the Supervisory Control and Data Acquisition (SCADA) field doing petroleum pipeline monitoring with manual control by the operator but automated alarm and report management by the computer. I know intimately what is required for process control work.

At first blush, I would say this is not a good field for inexperienced programmers. I see two rather ugly issues right away.

First, you have to find a suitable interfacing device to tie your sensors to your computer in a way that Access could read. I'm not going to say it can't be done, but you might have to write some specialized device drivers to make it work and that would be entirely outside the boundaries of normal Access programming. We had to fake out a serial device and tie in a serial port for each communications circuit because the remote devices weren't TCP/IP enabled. Oh, it worked, but it was a pain in the tush.

Second, the kind of reliability required for control systems - and the kind of speed - can be difficult for Windows to maintain. It has too many background services running besides your application. It wants to do things because Windows has a mind of its own and can act like a petulant child if things don't happen that it wants to have happen. Besides that, Access VBA is interpretive and can be maddeningly slow at times. Between having a ton of services and having slow primary application code, I would say it is NOT one of those "marriages made in Heaven." I'm thinking more of the relationship between Persephone and Hades as depicted in the Percy Jackson and the Lightning Thief movie.

Personally, if it were my project, I'd get a PC converted to LINUX or any other UNIX flavor and program that for my actual process control machine. Or if it was a big enough project, I'd get something like an HP rx2800 running OpenVMS, which has explicit real-time support and customizable device driver interfaces. (Stay with UNIX if it is small. You would have less expenses.)

Then I would allow the system to create files that could be networked over to the machine running Access, which would be great for after-the-fact report generation, both short-term and long-term. Access would give you the record-keeping and report management but I just don't see it as a good platform for real-time responsiveness.

 

[ChrisO]

Doc.

>>I know intimately what is required for process control work.<<

Please don’t go with that absolute assumption on such a limited scope of work with petroleum pipeline monitoring.

I’m retired now but was a 50 year man in process control. Between 1980 and 1988, both before and after indirectly, I worked for the Foxboro Company. I specialised in boiler firing and fluid mass balance, exothermic reactions (and to some degree {pun}) estimated thermal balance and dead time processes (integration of change over distance).

My particular speciality was the absolute prevention of first surg in radial pure Oxygen compressors and that was done as a joint venture with Sulzer and Foxboro.

Even given that experience, I doubt if I would ever say:-
>>I know intimately what is required for process control work.<<

That statement simply does not go down well with someone having intimate experience in any particular speciality.

Chris.

 

[mahenkj2]

I thanks all of you for sharing your experience and thoughts on this subject. I am not a programmer/Developer from any point and have brief experience of manufacturing process of Optical fibres.

I could grasp and understand regarding use of access in process control somewhat based on comments above. I think that direct recording (live) of process readings in access might not be either easy or doable. Although, one can do reporting of process data smoothly with access. In fact, I can not say much as I do not know much about this area.

Anyway, I would strive to do my best to use Access in my process applications and come back if I found some innovative usage of Access in process.

best regards.

 

[Lightwave]

I've come across QT creator a bit.

Which looks like its a gold standard product for dealing with process control environments. You will very probably have to learn something like Javascript or C++

Interestingly it's open source originally developed by Nokia.

QT Creator

The closest I've come to process control is measuring times of racers in athletics races. It works but I can only do up to certain number of competitors before things grind to a halt but that's probably as much an issue with the algorithms I use.

The weak part is that in most process control systems you need a constant calculator running in the background and this refreshing the screen. The background calculator can probably be constructed using SQL Server so you'll probably first have to move away from access as a back end then I'm not sure how you get round the idea of constantly refreshing the front screen. I think for very frequent refresh again you would want to move away from access. Hey presto your in a totally different environment. In the first instance work out the backend and see what information is being pumped out and then as a practice maybe get it displaying stuff in Access should be possible long term you might be better placed with something like QT creator.

This halfway house should give you a better indication of what you are looking for.