Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP and OLE for Process Control (OPC) Servers
Message
From
14/04/2002 18:34:49
 
 
To
13/04/2002 18:59:51
General information
Forum:
Visual FoxPro
Category:
COM/DCOM and OLE Automation
Miscellaneous
Thread ID:
00644765
Message ID:
00644878
Views:
14
>I need to access devices information (controllers, counters, etc.) from my VFP application, connecting to an OPC Server. I would be grateful if someone could send me an example showing how to do this. Probably someone is using an ActiveX control for this purpose, so I would like to know where can I buy the control and how can I implement it into my application.

Unfortunately, there's no universal interface for external device interfaces; I'd suggest that you start by identifying the external devices and the data interface(s) they support. A number of companies sell both data collectors and programmable controllers for specific devices; I'd generally suggest trying to pick specific hardware which supported a single common interface such as USB, HPIB or RS-485, and once you know your requirements for actual data rates required, interface lengths, number of devices being handled and the like, investigate what's available commercially, and what types of software interfaces currently exist for the product(s). Having built products that managed and monitored control systems, we found VFP lacked many low-level service interfaces and interrupt dispatch facilities; eventually, we separated the control and monitor tier, which we implemented in C++, from the logging, job scheduling and job programming modules - the low-level, low latency tolerance functions tied strongly with the operational hardware were written in C++ using the HPIB API supplied with the controller hardware, and published a COM interface which raised events and wrote process logs out to a named pipe; a VFP app monitored events from th COM object and managed production line work strategies, logged jobs, recorded and edited job procedures for the low-level engine, translating the human-readable code into usable p-code, scheduling jobs, providing reporting, etc. C++ was ideal for the low-level work - structures, pointers, low-level functions, free threading, a strong object model that included a considerable range of user-definable types, great speed of execution of individual instructions and the ability to interrupt execution of a process at will made it a superb choice for doing this part of the job. VFP's native database, rich UI, ability to interact with COM events and present its own COM interface, and great performance allowing both its native file system and a wide range of powerful backend products, with the option of minimal code changes initially to switch between local and remote views, which may allow time to recode the data tier to better take advantage of SPT or ADO.

I would not recommend attempting to implement the real-time control interface using VFP unless relatively few devices are involved and the process is not time-sensitive.

>
>Thanks in advance
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Reply
Map
View

Click here to load this message in the networking platform