Abstract: This paper introduces a method for online functional expansion of a monitoring program using plug-in technology based on dynamic link libraries. The feasibility of the solution was verified by implementing monitoring of an S7-300 PLC using Siemens' PRODAVE software and VC++. Keywords: Dynamic link library, plug-in, PRODAVE, VC++ 1 Overview In process control systems, the supervisory control and data acquisition (SCADA) program has become an indispensable component. Controlling the system through a SCADA program significantly reduces the difficulty and complexity of operation. With the increasing power of computers, monitoring programs can perform more and more functions, and in some cases, the SCADA computer can assist the slave computer in completing control functions. Currently, there are two main ways to design SCADA programs: one is to use specialized configuration software, such as WinCC and KingSCADA; the other is to develop the program using a programming language. The first method is simple to operate, efficient, and has relatively low requirements for developers, but it is more expensive; the second method is relatively more complex, requiring developers to have a higher level of programming skills and a longer development cycle, but it has the advantages of flexibility and lower cost compared to the first method. For smaller projects, the second method can be used to reduce costs. The second method requires addressing additional technical challenges. For example, after the system is operational, additional equipment or modules may need to be added due to increased production scale, requiring corresponding modifications to the monitoring program. Programs developed using this second method typically encounter problems such as large modification workloads and the need for system downtime for upgrades. This latter issue, in particular, should be avoided as much as possible when the host computer assists the slave computer in completing control functions. This paper proposes a plug-in technology-based solution to this problem. 2. Plug-in Background Knowledge 2.1 Plug-in Principle A plug-in is a program that follows a specific application programming interface (API). A plug-in can be understood as a new function. Implementing plug-in functionality requires consideration of both the plug-in container and the plug-in itself. The first problem to solve is that the plug-in container doesn't know what functions the plug-in to be installed will perform, while the plug-in itself may need information about the plug-in container to better integrate with it. Based on this consideration, specific interfaces (generally interface functions) need to be defined between them. The actual functionality of the interface depends entirely on the plug-in itself, as shown in Figure 1. [align=center]Figure 1 Plugin Structure Diagram[/align] The main purpose of using plugins is to extend the functionality of the monitoring program without modifying the monitoring program (plugin container). Therefore, the parameters and return types of the interface functions should be considered at the beginning of the program design. Furthermore, since plugins are generally installed during program execution, it is desirable for the program to automatically add the already installed plugins upon the next program startup. Therefore, the monitoring program should manage the installed plugins uniformly. 2.2 Dynamic Link Library (DLL) A DLL is a library file containing several functions, classes, or resources, built on the concept of client/server communication. Functions and data are stored on a DLL (server) and exported and used by one or more clients, which can be applications or other DLLs. Microsoft Visual C++ supports three types of DLLs: Non-MFC DLL, Regular DLL, and Extension DLL. Non-MFC DLLs refer to DLLs written directly in C language without using the MFC (Microsoft Foundation Classes) class library structure. Their exported functions are standard C interfaces and can be called by applications written in either MFC or non-MFC environments. Regular DLLs, like Extension DLLs (described below), are written using the MFC class library. A key characteristic is the presence of a class that inherits from CWinApp in the source file (note: although these DLLs derive from CWinApp, they lack a message loop; the exported functions are C functions, C++ classes, or C++ member functions). Applications calling regular DLLs do not need to be MFC applications; any application capable of calling C-class functions can use them. These can be applications developed using DLLs in environments such as Visual C++, Delphi, Visual Basic, and Borland C. Regular DLLs can be further divided into those statically linked to MFC and those dynamically linked to MFC. Compared to regular DLLs, Extension DLLs are used to export functions or subclasses that enhance MFC base classes. This type of dynamic link library can be used to export a class inherited from MFC. Extended DLLs are created using the dynamic linking version of MFC and are only called by applications written with the MFC class library. Unlike regular DLLs, extended DLLs do not have objects of classes inherited from CWinApp. Therefore, developers must add initialization and termination code to the DllMain function within the DLL. 2.3 Plugin DLL Characteristics The most significant characteristic of plugin DLLs is their fixed structure. Once the monitoring program, acting as a container, is released, the plugin's structure cannot be changed. Therefore, a well-designed plugin structure is crucial for future functional expansion. To improve development efficiency, choosing a DLL that supports MFC is a good option. It's important to note that if you need to export objects of classes inherited from MFC from a DLL, it's best to use an extended DLL; otherwise, discrepancies may occur between the objects in the DLL and the exported objects. 3 Example Programming The following example simply implements the expansion of the monitoring screen. The main monitoring program monitors only one PLC. Subsequent plugins can monitor more PLCs without affecting the main program (here, only one PLC is being expanded). 3.1 Plugin Part In the AppWizard of VC 6.0, select “MFC AppWizard (dll)”, and in the next step, select “MFC Extension DLL” (because in this example, we need to export objects of classes that inherit from MFC). Insert a dialog template in the resources, set the properties to “Child”, “Thin”, “Title bar”, and create a new class CPage with CPropertyPage as the base class for it. The next step is to design the data acquisition and monitoring interface. PRODAVE is a toolbox for data link communication between PC and S7 series PLC. Through the PC’s MPI communication processor, such as CP5511, CP5611, or PC/MPI adapter (PC-Adaptor), a data link can be easily established between PLC and PC [3]. It is worth noting that since MFC extension DLL is used, the PRODAVE DLL file must be dynamically loaded. The method is as follows: ① Define a function pointer typedef int (WINAPI *Ploadtool)(char,char *,adr_table_type *); ② Load the DLL and obtain the function pointer hProdave=LoadLibrary("W95_s7.dll"); Ploadtool loadtool=(Ploadtool)GetProcAddress(hProdave,"load_tool"); Punloadtool unloadtool=(Punloadtool)GetProcAddress(hProdave,"unload_tool"); ③ Call the function loadtool(1, "S7ONLINE", &adr_table); After completing the specific functions of the plugin, the exported function also needs to be implemented: void showprop(void**dlg) { *dlg=new CPdlg; } 3.2 Monitoring Program Because the plugin DLL exports a property page, this property page can be added to the monitoring program. Based on the preceding text, the main functions that the monitoring program needs to implement include the main monitoring function, loading plugin DLLs, and automatically loading plugins at startup. ① The main monitoring function implements most of the functions of the monitoring program, such as the design of the main monitoring screen, but this is not the focus of this article. ② Loading the DLL plugin. This function is implemented in the function BOOL CTestdllDlg::CreateObjectFromPath CreatePlugPage(CString name): BOOL CTestdllDlg::CreatePlugPage(CString name) {BOOL brt=FALSE; PAGE temp; if(name){ temp.hdll=LoadLibrary(name); if(temp.hdll){ fun func=(fun)GetProcAddress(temp.hdll,"showprop"); if(func){ func((void**)&temp.page); s.AddPage(temp.page); brt= -1!=pagelist.Add(temp); } } } if(!brt) FreeLibrary(temp.hdll); return brt; } Creating a directory and saving the DLL file: CreateDirectory(m_strPlugFile, NULL); // `m_strPlugFile` specifies the directory name. `if (!CopyFile(filename, m_strPlugFile, TRUE)) // filename is the plugin DLL filename { return; }` ③ Automatically load the plugin at startup. This function is implemented in the function `BOOL CTestdllDlg::CreateObjectFromPath(LPCTSTR szPath)`: `BOOL CTestdllDlg::CreateObjectFromPath(LPCTSTR szPath) { CString strPath = szPath; CString strFindFile = szPath; strFindFile += "\\＊.dll"; WIN32_FIND_DATA wfd; HANDLE hf = FindFirstFile(strFindFile, &wfd); if (INVALID_HANDLE_VALUE != hf) { CreatePlugPage(strPath + "\\" + wfd.cFileName); while (FindNextFile(hf, &wfd)) {` CreatePlugPage(strPath + "\\" + wfd.cFileName); } FindClose(hf); } return TRUE; } 4 Summary Many documents have introduced the development of monitoring software[4], but few have covered the online modification function of mature development software, which limits the application scope of monitoring software. The method proposed in this paper is a necessary supplement to this deficiency. The example program successfully implemented the monitoring of more PLCs on the basis of the main monitoring program through the plug-in method, which shows how the monitoring program copes with the increase of production equipment. This method can not only successfully solve the problem that the self-developed monitoring program needs to be shut down for functional expansion, but also does not require any modification to the main monitoring program, thus greatly reducing the workload. References: [1] Wang Yan. Making Dynamic Link Libraries with VC. Beijing: Microcomputer Information. 2003.5: 70～71. [2] Liao Changchu. Application Technology of S7-300/400 PLC. Beijing: Machinery Industry Press. 2005. [3] Jiang Jianfang, Su Shaoyu, et al. Research on Communication Implementation between Siemens S7-300 Series PLC and PC. Manufacturing Automation. 2003.1:52～54. [4] Wang Yamin, Chen Qing, et al. Configuration Software Design and Development. Xi'an: Xi'an University of Electronic Science and Technology Press. 2003. [5] MSDN Library online. Microsoft corporation.