1. Introduction
As we all know, PLCs have played an irreplaceable core control role in various industries of automatic control since their invention. PLCs are reliable and suitable for various harsh industrial environments. Compared with industrial PCs (IPCs), PLCs are more reliable, have better scalability, are easier to connect electrically, and offer more professional control. However, the superior human-machine interface and ease of use of high-level languages of IPCs are unmatched by PLCs.
Configuration software is used in many control applications, but the PLC is often still the core of the entire control system, with the configuration software (host computer) playing a relatively minor role. Human-machine interfaces (HMIs) are generally used for simple motion control, process parameter programming, recipe setting, etc. Although conceptually within the control domain, they don't truly play a core control role because long-term automatic operation control is handled by the PLC. We don't frequently use industrial PCs as the core control component for two reasons: first, industrial PCs are not suitable for harsh environments; second, the Windows systems commonly used in industrial PCs are not reliable, and their long-term performance is poor.
Although PLCs and IPCs play different roles in automation control, in many situations with short continuous operating times and relatively good environments, people still prefer to use IPCs for core control. There are many ways to implement core control using IPCs, and the simplest method is of course to use configuration software.
This article discusses common problems encountered by users when using configuration software for control. Many users find that automatic control by configuration software, especially when using serial port connections, affects data acquisition speed. This article focuses on how to solve this problem—by mimicking the control method of a PLC and applying it to the serial port control of a host computer.
2. Reasons for slow data acquisition after users control the system using configuration software . This is a problem many configuration software users encounter when writing host computer automatic control programs. What are the causes? Are there any good solutions?
Let's first briefly describe the principle of data acquisition and control in configuration software. Under normal circumstances, the configuration software periodically sends read commands to the lower-level computer, waiting for a response to capture the desired data. This cycle repeats continuously, and the data is dynamically displayed on the upper-level computer, achieving "real-time data acquisition." Therefore, when we need to control the lower-level computer, the configuration software will write corresponding commands, enabling "real-time control" of the lower-level computer by the upper-level computer.
On the surface, this seems reasonable, but why does slow data acquisition occur? It turns out that everything is "attributed" to the read/write mechanism of the configuration software. To achieve rapid control, the configuration software gives write commands the highest priority. That is, when there is a write (control) command, the configuration software executes the write command first, and only resumes the normal read (acquisition) cycle when there are no more write (control) commands.
Therefore, it's easy to see why users often experience slow data acquisition. If users frequently issue control commands, the system will allocate very little time to data acquisition, leading to slower or interrupted data acquisition. Repeatedly assigning a value to a variable within a loop instruction (e.g., y0=1) will also cause the above problems. Therefore, our solution is to control only when necessary and release control when not needed. To achieve this control method, we can refer to the operating modes of a PLC.
3. PLC Operating Principle
Without interruption, the PLC operates in a "sequential scanning, continuous loop" mode.
1) Each scan process involves sampling the input signal and refreshing the output signal.
2) Input refresh process. When the input port is closed, if there is a new state at the input port during the program execution phase, the new state cannot be read in. The new state is only read in during the next scan.
3) One scan cycle consists of input sampling, program execution, and output refresh.
4) The contents of the element image register change as the program executes.
5) The length of the scan cycle is determined by three factors: <1> the speed at which the CPU executes instructions; <2> the time occupied by the instruction itself; and <3> the number of instructions.
6) Due to the centralized sampling and output method, there is an input/output lag, i.e., input/output response delay.
4. Summary <br />As mentioned above, in configuration software control, we adopt the method of calculation before output. That is, when there are complex cyclic calculations on IO variables, we use intermediate variables for calculation, and then assign values to the IO variables after the calculation results are obtained. This solves the problem of slow data acquisition in control.
