Abstract: With the development of automated testing, the programmability of instruments has been challenged. Under this premise, the emergence of the SCPI (Standard Commands for Programmable Instruments) protocol has driven the development of standard programming languages ​​and was eventually accepted by the industry. This paper presents the programming of the lower-level machine based on SCPI. Keywords: Automation, SCPI, Standard Programming Language [b][align=center]The Development of the Bottom Machine in the Direct Current Electric Resistance Instrument Teng Da-zhu, Cheng Ming[/align][/b] Abstract: Along with the development of automatic testing, the challenge of instrument programmability was put forward. Under this premise, the negotiation of SCPI (Standard Commands for Programmable Instruments) aroused the development of the standard programmable language, and was finally accepted by the industry. This thesis is designed for the bottom machine based on the SCPI. Keywords: Automation, SCPI, Programmable Language 1. Introduction In the past, the complex instruction structure and cumbersome programming language in instrument control made the instrument's programmability very poor. Over time, people longed for a unified programming standard. To meet this challenge, HP Corporation of the United States first implemented a unified standardized programming language, TMSL (Test and Measurements System), within the company. After a period of experimentation and improvement, it was accepted by the industry and defined as the standard for the instrumentation field, and renamed SCPI (Standard Commands for Programmable Instruments). SCPI is widely used, but in China, programmable instruments and automatic testing systems are still in the development stage. Therefore, I believe we should try to skip the non-standardized stage of programmable commands and vigorously promote SCPI to keep up with the global trend of standardized programmable commands. In this paper, we mainly use a subsystem to illustrate how SCPI is implemented. The host computer sends commands through the RS232 serial port, and the slave computer receives and performs loop parsing to obtain the function that the command is expected to achieve. After executing the corresponding function, it returns data. The slave computer verifies whether the host computer's command has been parsed by returning the corresponding data. If it is correct, it returns the corresponding data; if it is incorrect, it returns an error message. 2. Design Overview 2.1 SCPI Command Tree Structure The SCPI command adopts a tree structure, which can be three levels down. Here, the highest level is called the subsystem command. Only when a subsystem command is selected are its subordinate commands effective. SCPI uses a colon (:) to separate high-level commands from low-level commands. 2.2 Serial Communication Communication between a PC and a microcontroller is usually achieved through the RS-232 serial bus. Therefore, a communication interface circuit based on RS232 is adopted. This interface circuit is suitable for designs where one PC communicates serially with multiple microcontrollers. Its block diagram is shown in Figure 1: In this block diagram, the RS-232C communication interface circuit plays a crucial role. It is the hub for information transmission between the host computer and the slave computer; all data transmission must be completed through it. The host computer directly uses its RS-232 serial port to send commands and receive return values. [align=center] Figure 1 Block Diagram of Communication Principle between Microcontroller and PC[/align] 3. Implementation of SCPI in DC Low Resistance Meters 3.1 Function of DC Low Resistance Meters DC low resistance meters are mainly used in high-end machines such as computers. Since they are DC resistors, resistor heating is unavoidable. Using low resistance values ​​can reduce heat generation, saving energy and greatly extending the lifespan of the instrument. The function of a DC low resistance meter is to detect the quality of resistors on a production line, ensuring that the resistance value is within the allowable error range. This allows for real-time monitoring around the clock and records the resistance change curve, making it convenient for engineers to check whether the instrument is working properly. 3.2 Modules of DC Low Resistance Meters The standard instruction set of programmable instruments can also be implemented in DC low resistance meters. A typical DC low resistance meter includes: a FUNCTION subsystem and a COMPARator subsystem. 3.3 Command Parsing 3.3.1 Introduction to Library Functions When building modular systems, calling library functions to complete corresponding functions is very convenient. The following library functions are provided in this SCPI parsing protocol: CheckFloat.c: Its function is to check if the number is a floating-point number; CheckInteger.c: Its function is to check if the number is an integer; CommandEntry.c: This library function is very important; it is the program entry point. The computer sends data to the microcontroller through the RS232 serial port, and receives instructions through this entry program; NewToken.c: Its function is to convert the character, symbol, or number pointed to by a pointer into an identifier, such as converting "set" to "TOKEN_FLAG_COMMAND" and "50" to "TOKEN_FLAG_NUMMBER"; RS232_Close.c: Its function is to close the RS232 serial port; RS232ErrChr.c: Its function is to display character errors; RS232ErrStr.c: Its function is to display string errors; RS232_Open.c: Its function is to open the RS232 serial port; RS232Print.c Its function is output; RS232PrintChar.c outputs a single character; RS232PrintError.c outputs errors; RS232PrintLine.c outputs strings; RS232Send.c sends RS232 commands; SeekParameter.c searches for parameters; SubsystemError.c contains functions of the ERR subsystem; Translate.c is a library function that will be discussed later as a loop-call parsing function. 3.3.2 Command Parsing Function The parsing function is the soul of the entire SCPI protocol. The SCPI protocol parsing is achieved through such a loop-call function to parse commands, then parse the parsed commands again, until the last layer, and finally call other functions. In the loop parsing, it plays the role of splitting commands, and then parses and splits the split commands until the last layer. In this function, the NewToken() function is used first. The function of this function is to judge the object pointed to by the current pointer m_pInBuffer and return the corresponding type. If it points to ":", it returns ":"; if it points to "set", it returns "TOKEN_FLAG_COMMAND"; if it points to ";", it returns ";"; if it points to "50", it returns "TOKEN_FLAG_NUMMBER". The specific parsing process is as follows: 1. If it is "TOKEN_FLAG_COMMAND", it is compared with the command defined by itself. If they are not the same, the error message "BAD COMMAND" is returned. If the comparison result is the same, bFound is assigned true and the while() loop is exited and the if operation is executed. There are two situations here: (1) If there is no subordinate execution function, compare whether m_pInBuffer is ":". If it is, perform the "++" operation to retrieve the next symbol. Here, the if operation is performed. If there is no subordinate command, return the error message "BAD COMMAND". If there is a subordinate command, assign the command to pToken and set bNeedCommand to true. If m_pInBuffer is not ":", return the error message "INVALID SEPARATOR" and return to the main function. After this program is executed, exit the loop and wait for the next loop. (2) If there is a subordinate execution function, assign the subordinate command to pToken and execute the subordinate execution function. After the function is executed, it will return an identifier. Here, the identifier is judged again: ① If it is ":", then check whether the command has a subordinate. If not, return the error message "INVALID AEPARATOR". If it does, assign true to bNeedCommand and exit. ② If it's ";", check if m_bCommon is true. If it is, set it to false and set bNeedCommand to false before exiting. ③ If it's "TOKEN_FLAG_RESTART", set m_bCommon to false, return to the root command, and return true. ④ If it's "TOKEN_FLAG_COMMON", check if m_bCommon is false. If it is, set it to true, assign the value of pToken to m_pTokenSave, and return true. ⑤ If it's "END", return false. ⑥ If none of the above apply, return an error message and return false. 2. If it's "*", it represents a common command, and m_bCommon is set to true. 3. If it's ":", exit. 4. If it's " ", check if bNeedCommand is true. If it is, return the error message "SYNTAX ERROR" and return to the main function. 5. If it is "TOEN_FLAG_NUMBER", return the error message "BAD COMMAND". 6. If it is "TOKEN_FLAG_END", return to the main loop. 7. If neither is true, return the error message "INVALID SEPARATOR" and return to the main loop. To make it easier to understand, here's an example: Enter the command "set:red 50;:set:yel?" in the computer. This command sets the red light duration to "50" and queries the current yellow light duration. First, the main program pointer points to "set", and the function "NewToken()" returns an identifier, which is assigned to "cToken". Then, "cToken" is evaluated. Because "set" is a command identifier, "NewToken()" returns "TOKEN_FLAG_COMMAND". The program executes its operations, comparing the user-defined command. A matching command is found in the command abbreviation form, the "if" operation is exited, and the program pointer is incremented. Since we defined "set" with a subordinate instruction "M_tSetup", "el" is executed. The `se` operation checks if the main program's pointer is ":", indicating a follower command "red". It assigns the command to "pToken" and exits the program. The pointer now points to "red". The program continues execution by checking if the identifier is of type "TOKEN_FLAG_COMMAND". It compares custom commands and finds a matching command, incrementing the program pointer. Since the defined "red" instruction doesn't have a follower command but has a follower function, an `if` operation is executed. Here, the `SetRed()` function is called, writing the time "50" into it. The program pointer then increments by "+". The plus sign (+) points to ";:", which is a data type "TOKEN_FLAG_RESTART". It executes the command tree restart operation, waiting for the next call to the main function "CommandEntry()". After the call, it continues executing commands, and the pointer again points to "set". Since the return type is "TOKEN_FLAG_COMMAND", it executes the operations inside, comparing the user-defined commands. It finds a matching command in the command abbreviation form, exits the "if" operation, and increments the program pointer. Because we defined "set" with a subordinate instruction "M_tSetup", it executes... The "else" operation is executed, checking that the main program pointer is ":", indicating a follower command "yel?". This command is assigned to "pToken" and the program jumps out. The pointer now points to "yel?". The identifier type is "TOKEN_FLAG_COMMAND", and the program continues execution, comparing custom commands. A matching command is found, and the program pointer is incremented. Since the defined "yel?" instruction has no follower command but a follower function, an "if" operation is executed, calling the "SetYellowQuery()" function to perform the query. The instruction ends here. 3.4 In the design of the delay timer, I encountered the following problem: Initially, I used a microcontroller for the experiment, and after success, I switched to a simulator. The digital tube speed slowed down, and the original one second became longer. After thinking about it, I realized it was due to the difference in clock frequency between the microcontroller and the simulator. Upon comparison, the microcontroller's clock frequency was 20MHz, while my simulator's frequency was 12MHz. Having found the problem, I began to rewrite the timer definition function. First, locate the file define.h where the delay timers are defined. Find: #define RELOAD_H_10MS 0x7d #define RELOAD_L_10MS 0xcb. The time definition here is based on 20ms. The time calculation formula is as follows: x = 65536 - T/t. Then, convert x to hexadecimal and assign it to RELOAD_H_10MS and RELOAD_L_10MS respectively, where T is the delay time and t is the time of one cycle. For example: 12MHz@12CLK: t=1us/circle 12MHz@6CLK: t=500ns/circle 40MHz@12CLK: t=300ns/circle For example: x = 65536 –T/t 1ms = 65536–1000=64536 (converted to hexadecimal 0xFC18) 50ms = 65536–50000=15536 ​​(converted to hexadecimal 0x3CB0) In this design, a 12M@12CLK chip is used, and a 10ms delay timer is used. Therefore, modifying the values ​​of RELOAD_H_10MS and RELOAD_L_10MS is sufficient. x=65536-10ms/1us=55536, modified as: #define RELOAD_H_10MS 0Xd8 #define After modifying `RELOAD_L_10MS 0Xf0`, the program ran successfully, and the time was correct. 3.5 Test Results: In the design, you can set the red and green light durations in two ways: one is by pressing buttons directly on the template using `KeyEntry()`; the other is by communicating with the template via the computer's serial port and inputting commands to set the traffic light duration using `CommandEntry()`. Both methods are implemented on the template. The button-based method has fewer functions, only allowing time setting and pausing. The serial communication method includes querying, setting the time, and restarting. The interface programmed on the computer communicates with the template. Inputting "set:red 50" returns "50", and the red light's set time changes to "50". Inputting "set:gree?" returns "30", indicating the green light's set time is "30". Inputting "rst" returns "waiting for 3s...", restarting after 3 seconds. This test demonstrates that the SCPI concept I used is implemented. 4. Conclusion Functional deficiencies in control can be addressed by adding instructions, which is an advantage of SCPI. The standard instruction format ensures consistency in mnemonics, parameter formats, execution methods, and functional expansion strategies, reducing test software development time and facilitating instrument interchangeability. Programs written with SCPI are not only more readable but also more intuitive, allowing users to spend less time learning the instrument and more time solving practical application problems. Furthermore, SCPI is scalable, enabling it to expand with instrument capabilities. In the future, users can purchase multimeters with more functions than current instruments, whose basic functions can be programmed just like the older instruments currently in use. Therefore, in this design, we adopted the SCPI protocol as our guiding principle, using SCPI instruction mnemonics, hierarchical structure, and multi-command structure to achieve the purpose of controlling the instrument template. When the computer sends control commands to the template via the RS232 serial port, the template receives the commands and responds accordingly. The returned data matches the actual data, successfully applying the SCPI concept to the lower-level computer programming with excellent results. The innovation of this paper is that the SCPI protocol has been successfully written, and the commands sent by the computer have been received, correctly parsed, and executed by the microcontroller. This demonstrates that SCPI can also be implemented in DC low-impedance meters. References [1] Li Yuhui, Guo Qunshan, Zhou Xiongwei. Design of an automatic test system software platform [J]. Microcomputer Information, No. 5, 2005. [2] Ou Yangguang, He Guangming. Keil_c Programming Tutorial [M]. Beijing: Renmin University Press, 2004. 23-39. [3] Wang Xiaolong, Lei Hejing. The prospects of programmable instruments [J]. Micro Instruments and Applications, 2001, (6): 16-18. [4] HAWheeler. SCPI: The Next Step in the Evolution of ATE Systems. Electronics Test [M]. New York: Industry Publisher, August 1990: 12-15. [5] JWDuncan, and VPMinerva. SCPI Instruments Will Ease ATE Development [J]. Instrument, October 1991: 4-6.