Web visualization IDE cooperates with industrial edge gateway to program control system and device

Abstract

The application discloses a Web visualization IDE and industrial edge gateway collaborative programming control system and device, and belongs to the field of industrial automation. A three-layer architecture is adopted: the Web IDE layer runs in a browser in an HTML file, and provides ladder diagram and Lua hybrid programming; the translation layer is bound through two-stage Lua metatables, converts the ladder diagram into Lua code, and generates a CRC fingerprint; and the gateway layer creates a Lua virtual machine on a RISC-V / ARM bare machine, and executes control in a period of greater than or equal to 5 ms. Code issuing, storage and online debugging are realized through HTTP / WebSocket and binary function code protocols; the gateway completes heterogeneous device normalization collection through a multi-protocol driver stack, and binds to I / Q / M variable areas; and variable caching and visual monitoring are realized through a double-layer linked list and LRU for debugging. The system has the flexibility of graphical and script programming, eliminates the dependence on special software, and realizes an industrial automation programming and debugging scheme with cross-terminal zero installation.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, and in particular to a web browser-based visual integrated development environment and industrial edge gateway collaborative programming control system and device. Specifically, it relates to a collaborative working method and device for ladder diagram visual programming, Lua script intermediate translation, bare-metal embedded execution engine, WebSocket real-time debugging communication, and normalized acquisition of data from multiple heterogeneous devices. Background Technology

[0002] In the field of industrial automation control, programmable logic controllers (PLCs) are the most crucial control devices. Traditional PLC programming and development suffers from the following technical challenges: First, there is the issue of dependency on dedicated programming software. Traditional PLC manufacturers all use dedicated programming software that only supports Windows systems. The installation packages are large, and they are incompatible between manufacturers. On-site debugging requires carrying dedicated equipment, making it impossible to achieve cross-terminal, remote programming and maintenance. Second, there is the limitation of a single programming paradigm. Traditional PLCs only support a single programming language according to the IEC 61131-3 standard, making it difficult to mix graphical and script-based programming. Basic logic control cannot be efficiently integrated with complex protocol parsing and data processing, resulting in poor programming efficiency and maintainability. Third, there are difficulties in remote debugging and maintenance. Traditional PLC debugging relies on field connections and dedicated software, resulting in extremely high maintenance costs in remote scenarios, making remote monitoring and debugging impossible through a general web browser; Fourth, the complexity of multi-protocol integration. Industrial environments often feature multiple protocols such as Modbus, Mitsubishi, Omron, and Siemens, lacking unified configuration management and data normalization capabilities, resulting in significant system integration difficulties and long development cycles. Fifth, the problem of low embedded resource utilization. Traditional gateways rely on operating systems, resulting in high resource overhead. They cannot efficiently implement PLC control, multi-protocol driving, Web services, and debugging functions on low-cost, low-configuration RISC-V / ARM bare-metal platforms. Therefore, there is an urgent need for a collaborative programming control system based on a standard Web browser, supporting mixed ladder diagram and Lua programming, featuring remote real-time debugging, multi-protocol data normalization acquisition, and efficient bare-metal operation. Summary of the Invention

[0003] 1. Technical problem to be solved: The technical problem to be solved by this invention includes: (1) Eliminate the dependence on dedicated programming software and enable cross-platform programming in any web browser; (2) Achieve seamless mixed programming of ladder diagrams and Lua scripts and automated code translation; (3) Establish a real-time bidirectional debugging channel between the Web client and the embedded gateway to realize variable monitoring and online debugging; (4) Efficiently run control logic in resource-constrained bare-metal embedded environments; (5) Realize the normalized collection of data from multi-source heterogeneous industrial equipment, unified memory binding, and standardized external data services; (6) Implement custom protocol-driven hot registration, resource reuse and three-level callback rollback scheduling.

[0004] 2. Technical Solution: This invention provides a collaborative programming control method and device for a Web visual IDE and an industrial edge gateway, which adopts a three-layer collaborative architecture: Web IDE layer (browser side), Lua script translation layer, and hardware gateway layer (bare-metal execution layer). It realizes a closed-loop process of editing, compiling, distributing, executing, monitoring, debugging, and data acquisition through dual-channel communication of HTTP and WebSocket.

[0005] 2.1 Cooperative programming control method: including the following steps: Step S1: The Web IDE stores a single HTML file in the gateway's external SPI Flash, which is then streamed to the browser by a bare-metal HTTP server; it provides ladder diagram visualization editing and Lua script embedding functions, forming a hybrid programming mode; the address parameters adopt an I / Q / M three-zone addressing system; Step S2: The compilation and translation module traverses the ladder levels, translating the ladder diagram logic into Lua source code, and uses two-level Lua metatable binding to implement address mapping; it automatically inserts debug markers and generates a CRC32 fingerprint after compilation. Step S3: The communication management module sends Lua code to the gateway in pages via the WebSocket full-duplex protocol and a custom binary function code protocol. The gateway then persistently stores the data in the SPI Flash. Step S4: The gateway PLC execution engine creates a Lua virtual machine in the bare-metal environment, loads the runtime library, registers the data area, protocol driver, and debug module, configures two-level metatables for the I / Q / M area, and compiles and executes Lua bytecode to complete environment initialization; Step S5: The PLC execution engine scans cyclically at a fixed cycle of ≥5ms, sequentially executing input update, logic execution, and output update; Lua scripts transparently access I / Q / M data through metatables, and multi-byte data is protected by interrupt critical sections to ensure atomic access; Step S6: The Web IDE performs CRC32 fingerprint verification. Upon successful verification, debug mode is activated. Device status, I / Q / M data, and debug variables are acquired via a polling cycle of ≥50ms. The gateway uses a two-layer linked list to cache debug data, supports an LRU eviction policy, and serializes the data for real-time visualization back to the Web client. In this invention, the gateway uses a multi-protocol driver stack to achieve normalized acquisition of multi-source heterogeneous industrial equipment data. It uniformly binds device data of different protocols and formats to the I / Q / M memory variable area, completing global normalization of data format, address space, and access interface. It also provides consistent data interface services externally through MQTT and Modbus Slaver standard protocols.

[0006] 2.2 Collaborative Programming Control Device: Includes: Web IDE module, compilation and translation module, communication management module, PLC execution engine module, protocol driver management module, storage management module, and debug data management module. The protocol driver management module enables normalized acquisition of data from multi-source heterogeneous devices, uniformly binds I / Q / M memory, and provides standardized data services externally; it supports no fewer than 200 Lua custom protocol slots, enabling hot driver registration, name reuse, three-level callback rollback, and resource isolation sharing; the PLC execution engine module runs a Lua virtual machine in a bare-metal environment, using a fixed scan cycle of ≥5ms to achieve efficient and atomic access to I / Q / M data; the debug data management module uses a two-level linked list structure to cache debug variables, with the number of nodes adapting to the hardware memory capacity, and supports LRU memory reclamation.

[0007] 3. Beneficial effects: (1) Zero installation and cross-platform compatibility: Based on a general web browser, no special software is required, and it supports remote programming and debugging on PCs, tablets and mobile phones, reducing tool costs; (2) High efficiency of hybrid programming: Ladder diagram visualization logic and advanced Lua script functions are seamlessly integrated, taking into account both ease of use and flexibility; (3) End-to-end browser closed loop: Editing, compiling, distributing, executing, and debugging are all completed in the browser without switching tools; (4) Remote real-time debugging: WebSocket full-duplex communication + lightweight debugging and data acquisition to achieve near real-time variable monitoring; (5) Multi-protocol normalization: Unified protocol framework, supporting standard protocols and custom Lua drivers, to realize unified collection and external publication of data from heterogeneous devices; (6) High-efficiency bare-metal operation: On a RISC-V / ARM platform with a main frequency of ≥72MHz and ≥64KB SRAM, Lua virtual machine, Web services and multi-protocol stack can run efficiently without an operating system; (7) Intelligent resource management: custom protocol slot reuse, debug data LRU eviction, and atomic memory access improve embedded resource utilization and system stability; Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the overall three-layer architecture of the system of the present invention.

[0009] Figure 2 This is a flowchart illustrating the complete process of the collaborative programming control method of the present invention.

[0010] Figure 3 This is a schematic diagram of the layout of the functional modules of the Web IDE interface of the present invention.

[0011] Figure 4 This is a timing diagram of the real-time debugging communication interaction of WebSocket in this invention.

[0012] Figure 5 This is a flowchart illustrating the ladder diagram translation of Lua source code in this invention. Detailed Implementation

[0013] 1. System Overall Architecture: The system is divided into three layers: Web IDE layer: runs as a single HTML file in the browser, enabling editing, translation, communication, debugging, and visualization; Lua translation layer: ladder diagrams and Lua scripts are uniformly translated into Lua code, serving as an intermediate adaptation layer; Hardware gateway layer: based on the RISC-V / ARM bare-metal platform, running Lua virtual machine, PLC engine, multi-protocol drivers, and HTTP / WebSocket services.

[0014] 2. I / Q / M Three-Zone Addressing System: - I Zone: Discrete Input Zone, read-only, supports bit / byte / word addressing, capacity ≥ 2 bytes, dynamically expandable; - Q Zone: Coil Output Zone, read-write, supports bit / byte / word addressing, capacity ≥ 2 bytes; - M Zone: Intermediate Register Zone, read-write, supports bit / byte / word / double word / 64-bit / 32-bit floating-point / 64-bit double-precision addressing, capacity ≥ 128 bytes; The three zones are mapped to the underlying C functions through a two-level Lua metatable to achieve zero-copy access.

[0015] 3. Two-level Lua metatable binding mechanism: A global Lua table and a first-level metatable are created for I / Q / M respectively, and the byte index triggers the creation of dynamic sub-tables; the sub-table is configured with a second-level metatable to realize bit-level read and write mapping; atomicity of multi-byte data access is ensured by disabling global interrupts.

[0016] 4. Custom binary function code protocol: - 0x00: Batch read of I area - 0x01: Batch read of Q area - 0x50: Flash paging read - 0x51: Flash paging write - 0x52: Debug variable query protocol reuse class Modbus addressing structure, carried in WebSocket binary frame.

[0017] 5. PLC execution engine: Fixed scan cycle ≥5ms; sequentially executes input sampling, LuaMain logic execution, and output refresh; multi-byte data execution address alignment verification: 16-bit / 2-byte, 32-bit / 4-byte, and 64-bit / 8-byte alignment, returns a default value of zero in case of abnormality, and does not trigger hardware failure.

[0018] 6. Debug Data Management: Adopts a DebugMaster-DebugNode two-level linked list structure; the number of nodes adapts to the processor memory; after reaching the upper limit, the oldest node is replaced by an LRU strategy; supports custom format queries and comma-separated string serialization and return.

[0019] 7. Protocol Driver Management: Pre-allocate no less than 200 Lua custom protocol slots; support overriding and reusing drivers with the same name, and automatically release memory; adopt a three-level callback fallback mechanism: Lua callback first → basic protocol C implementation → default error code; custom drivers and standard drivers share the I / Q / M memory pool for unified data interaction.

[0020] 8. Flash Storage Partition: - 0x0000: 4-byte CRC32 code fingerprint - 0x0004 Start: Ladder diagram JSON data - Subsequent area: Lua script data - 0xE002: Debug enable flag - 0xF000: Device operating status identifier. In this embodiment, the minimum hardware platform configuration is: main frequency ≥ 72MHz, SRAM ≥ 64KB, internal Flash ≥ 128KB, and support for Ethernet and multiple UARTs.

Claims

1. A method for collaborative programming control between a Web-based visual IDE and an industrial edge gateway, characterized in that: The edge gateway adopts a bare-metal environment of a RISC-V / ARM microcontroller without an operating system; Under the constraints of limited on-chip storage and memory resources, a single-threaded super loop architecture is adopted; The single-threaded superloop simultaneously supports the HTTP server, WebSocket server, Lua virtual machine, multi-protocol driver stack, and PLC execution engine; The gateway uses a multi-protocol driver stack to achieve normalized acquisition of data from multi-source heterogeneous industrial equipment. It binds the acquired data from different types of equipment to the I / Q / M memory variable area, completes the global normalization of data format, address space and access interface, and provides consistent data interface services to the outside world through MQTT and Modbus Slaver standard protocols. The method includes the following steps: S1: The Web IDE module is stored as a single HTML file in the external SPI Flash of the edge gateway; The bare-metal HTTP server streams the single HTML file to a web browser for loading and execution; The single HTML file embeds a ladder diagram visual editor, a Lua script editor, a compilation and translation engine, and a WebSocket communication module, without relying on an external CDN or application server. The Web IDE provides a visual editing interface for ladder diagrams, allowing users to drag and drop ladder diagram elements and configure address parameters. The Web IDE supports inserting Lua script editing areas between ladder diagram steps, forming a mixed programming mode of ladder diagrams and Lua scripts; The ladder diagram elements include normally open contacts, normally closed contacts, output coils, timers, comparison instructions, data movement instructions, and function call instructions; The address parameters adopt a three-zone addressing system of I zone, Q zone, and M zone; S2: The compilation and translation module traverses all ladder levels and converts the graphical logic of each ladder level into equivalent Lua source code according to preset translation rules. The translation process employs a two-level Lua metatable binding mechanism to implement address mapping; The first-level metatable dynamically creates subtables based on byte indexes using the __index metamethod. The second-level metatable uses the __index and __newindex metamethods to transparently call underlying C functions based on the bit index to complete bit-level read and write operations; The translated Lua code uses PLC-like addressing syntax to directly manipulate hardware registers without calling explicit API interfaces; Normally open contacts are translated into logical expressions; Normally closed contacts are translated into the inversion of logical expressions; The output coil is translated into a Boolean variable and assigned a value; Timers are translated into timer function calls; The function call is redirected to a call to the corresponding LUA function; Comparison instructions are translated into comparison expressions; Data move instructions are translated into variable assignment expressions; The ladder diagram's serial connections are translated into a logical AND operation; The parallel connection of a ladder diagram is translated into a logical OR operation; Each step is encapsulated as an independent Lua function; All hierarchical functions converge at the same top-level LuaMain entry function and are called in sequence; Insert debug marker function calls within each ladder function for runtime variable collection; After compilation, calculate the CRC32 fingerprint of the Lua source code; S3: The communication management module is based on the WebSocket full-duplex protocol and uses a custom binary function code protocol to paginate and distribute Lua source code to the edge gateway. The custom function code protocol multiplexing class Modbus address addressing architecture is carried on top of WebSocket binary frames; The gateway persistently stores the received service data to an external SPI Flash memory; S4: The edge gateway PLC execution engine module creates a Lua virtual machine instance in the bare-metal environment; Load the basic runtime library, and register the PLC data area access module, protocol driver module, network communication module, and debugging module in sequence; Create global Lua tables for I, Q, and M regions respectively, and configure two-level metatable binding relationships; The received Lua source code is compiled into internal bytecode and executed, completing the initialization of the global runtime environment; S5: The PLC execution engine module enters a fixed-cycle scanning loop; Each scan cycle executes three stages sequentially: input update, execution of LuaMain entry function control logic, and output update. The input update samples the GPIO pin states and writes them into the I-area array; The output update synchronously writes the Q-area array data to the GPIO pin; Lua scripts use a two-level metatable binding mechanism to transparently access I / Q / M zone data with PLC-like addressing syntax; The meta-table __index and __newindex meta-methods convert syntax-level table index operations into direct memory reads and writes of the underlying C data area; S6: When the Web IDE enters online debugging mode, it first reads the 4-byte CRC32 code fingerprint stored in the gateway's Flash via WebSocket; Perform a consistency check between the read device fingerprint and the locally compiled fingerprint; After successful verification, activate the internal debugging switch on the gateway. The Web IDE uses WebSocket to poll for device status, I / Q / M area data, and debug variable values ​​at preset intervals. The gateway serializes the collected debugging variable data into a comma-separated string format and sends it back. The Web IDE displays the current running values ​​of variables in real time on the ladder diagram canvas and script editor interface.

2. The method according to claim 1, characterized in that: In step S1, the three-zone addressing system is transparently mapped to the underlying C data zone for access through Lua metatables; Area I is a discrete input area and is set to read-only. Bit addressing, byte addressing and word addressing are supported through the metatable __index metamethod. The Q area is the coil output area and is set to be readable and writable. Bit addressing, byte addressing and word addressing are supported through the metatable __index and the __newindex metamethod. The M area is an intermediate register area and is set to be readable and writable. It supports bit addressing, byte addressing, word addressing, double word addressing, 64-bit addressing, 32-bit floating-point addressing and 64-bit double-precision floating-point addressing through the metatable __index and the __newindex metamethod. The I zone is configured with a capacity of ≥2 bytes, corresponding to ≥16 bit addresses, and its capacity can be dynamically expanded. The Q area is configured with a capacity of ≥2 bytes, corresponding to ≥16 bit addresses; The total capacity of the M area is ≥128 bytes; The three-zone addressing metatable mapping makes the Lua script table index syntax consistent with the traditional PLC address access syntax. The underlying implementation uses C functions to achieve zero-copy access to the bare-metal memory data area; Data collected from multi-source heterogeneous industrial equipment is uniformly mapped to the I / Q / M memory variable area to achieve normalized data storage and unified access.

3. The method according to claim 1, characterized in that: In step S2, the specific implementation of the two-level Lua metatable binding mechanism is as follows: Create global Lua tables for I, Q, and M regions respectively, and configure first-level metatables for each global Lua table; The first-level metatable __index metamethod receives the byte index parameter, dynamically generates a temporary subtable, and configures the second-level metatable for the temporary subtable; After receiving the bit index parameter, the second-level metatable __index metamethod calls the underlying C function plc_read_bit to read the corresponding data area bit value and returns a boolean result; The second-level metatables corresponding to the Q and M areas are also configured with the __newindex metamethod; After receiving the bit index and write value parameters, the __newindex metamethod calls the underlying C function plc_write_bit to write the corresponding data area bit state. The two-level metatable structure ensures that when a PLC-like addressing expression is executed, the first-level metamethod is triggered to create a subtable, and then the second-level metamethod is triggered to read and write the corresponding bit values, making it completely transparent to Lua script developers. Set up separate global Lua tables for byte-level, word-level, double-word-level, and floating-point-level data access; Each independent global Lua table is mapped to the underlying C data area access functions through the corresponding metatable __index and __newindex metamethods; When accessing multi-byte data, atomicity protection for data read and write is achieved by disabling and enabling global interrupts within the meta-method; The normalized device data enables transparent interaction between Lua scripts and the underlying hardware memory through a two-level metatable.

4. The method according to claim 1, characterized in that: In step S3, the custom binary function code protocol frame structure and address mapping configuration are as follows: The first byte of the WebSocket binary frame payload is defined as the function code, and subsequent fields are defined differently based on the function code type; Function code 0x50 is set as a Flash paging read instruction. The request frame contains a 2-byte start page address and a 1-byte read length. The response frame echoes the function code and carries the corresponding page data. Function code 0x51 is set to Flash paging write instruction, and the request frame contains a 2-byte start page address and a single write data payload of no less than 100 bytes; Flash address space is stored in partitions according to business functions; Address 0x0000 stores a 4-byte CRC32 code fingerprint; Address 0x0004 starts storing ladder diagram JSON data; The subsequent area of ​​the ladder diagram JSON data stores Lua script data. Address 0xE002 stores the debug enable flag; Address 0xF000 is the storage device's operating status identifier; The Web IDE uses function codes 0x50 and 0x51 to achieve unified read and write scheduling for different functional partitions of Flash. Normalized device data and control configuration data are uniformly stored persistently in Flash partitions.

5. The method according to claim 1, characterized in that: In step S5, the PLC execution engine is set to a fixed scan cycle of ≥5ms; When the Lua virtual machine executes control logic to access multi-byte data, it employs an interrupt critical section protection mechanism. Before calling the underlying C function to perform 16-bit, 32-bit, and 64-bit data area read / write operations in the metatable metamethod, global interrupts are disabled using the RISC-V / ARM machine mode CSR instruction. Immediately after data read / write operations are completed, enable global interrupts. In a bare-metal single-threaded architecture without an operating system, ensure the atomicity of data access between the application layer and the interrupt service routine; Perform address alignment validity checks before data access; 16-bit access requires 2-byte address alignment; 32-bit access requires 4-byte address alignment; 64-bit access requires 8-byte address alignment; When alignment verification fails, a default value of zero is returned without triggering a hardware exception; Normalized equipment data is updated in real time and synchronized for consistency during the scanning cycle.

6. The method according to claim 1, characterized in that: In step S6, the real-time data transmission mechanism of the I / Q / M area of ​​the WebSocket custom function code protocol is as follows: The Web IDE reads data from area I using function code 0x00; The request frame carries a 2-byte start address and a 2-byte register count. The gateway reads the corresponding discrete input state from the I_area array and sends it back in binary frame format. The Web IDE reads Q-area data using function code 0x01; The request frame carries a 2-byte start address and a 2-byte register count. The gateway reads the corresponding coil output status from the Q_area array and sends it back in binary frame format. Data in the M zone is read in batches using Flash paging via function code 0x50; The request frame specifies the starting page address, and the gateway reads the corresponding range data from the M_area array and sends it back in binary frame format; Function codes 0x00 and 0x01 frame structure reuse Modbus addressing logic, which is carried in the WebSocket binary frame payload; The frame payload always contains 1 byte of function code, 2 bytes of start address, and service data fields; The Web IDE is set to a polling cycle of ≥50 milliseconds, and performs batch reading of I-area, Q-area, M-area and debug variables in a loop. Under the constraint of bare-metal scan cycle, near real-time synchronization of data in I / Q / M zones is achieved; Normalized device data is monitored remotely in real time through a unified data interface.

7. The method according to claim 1, characterized in that: In step S6, a lightweight acquisition, caching, and transmission mechanism is used for debugging variables in the bare-metal environment; The compiler / translate module automatically inserts the addDbgTag debug tag call into each ladder function; The call carries the current ladder function name, variable name, and variable runtime value; The gateway-side C layer receives Lua layer debug tag calls through the lua_add_debug_tag interface; Cache debugging variable data in a two-level linked list structure; The first level of the doubly linked list is the DebugMaster node linked list, which uses the function string hash as the search key; The second level of the doubly linked list is a list of DebugNode nodes, with variable names as the search keys; Each DebugNode node compactly stores the variable name string, a 1-byte variable type identifier, and an 8-byte union variable value; Variable types include Boolean, 64-bit integer, and double-precision floating-point; The number of DebugMaster and DebugNode nodes can be adaptively configured according to the memory capacity of the processor. When the node capacity reaches the limit, the LRU eviction policy is used to traverse the linked list, remove the least visited node and immediately release the memory. Avoid memory fragmentation in bare-metal environments; The Web IDE sends a debug variable query string via function code 0x52; The query string can use semicolons to separate multiple function queries, colons to separate function and variable lists, and commas to separate multiple variables under the same function. The gateway parses the query string using the build_debug_text function, traverses the doubly linked list to match the target variable, and serializes it into a comma-separated string format before returning it. Normalized equipment variables and control variables are uniformly incorporated into the commissioning data acquisition system.

8. The method according to claim 7, characterized in that: The debugging mechanism includes a complete process of CRC32 fingerprint verification, debugging activation, and periodic polling visualization. Fingerprint verification phase: The Web IDE reads the 4-byte CRC32 fingerprint at Flash address 0x0000 using function code 0x50; The fingerprint is generated by the compilation and translation module based on the entire Lua source code and is written to Flash along with the business data; The Web IDE compares the local fingerprint with the device fingerprint. If they do not match, it will prevent you from entering debug mode and prompt you to download the code again. Debug activation phase: The Web IDE writes a 1-byte debug enable flag to Flash address 0xE002 via function code 0x51; After receiving the data, the gateway sets the global Lua debug enable variable __DEBUG_ENABLE__. After enabling, the addDbgTag acquisition logic within the cascade executes normally; Periodic polling phase: The Web IDE is set to execute five queries sequentially, including device status, I zone, Q zone, M zone, and debug variables, every ≥50 milliseconds. The device status is obtained by reading Flash address 0xF002 through function code 0x50 to obtain the running, stopped, or restart indicator; Trapezoidal canvas visualization: Contacts, coils, timers, comparison instructions, and connecting lines are dynamically rendered with colors and status animations based on real-time variable values; Visualization of the Lua script editor: Displays the real-time running values ​​of collected variables as inline comments between or at the end of the code lines; Normalized device data is presented in a unified manner on the visualization interface.

9. The method according to claim 1, characterized in that: In step S4, the protocol driver module configures the Lua custom protocol driver multi-slot hot registration and lifecycle management process; The system pre-allocates no less than 200 consecutive Lua custom protocol slots in the protocol enumeration; When a Lua script calls the registerDriver interface to register a custom protocol driver, it iterates through the existing slots to match the names. When a driver with the same name is matched, the slot is reused after releasing the original Lua registry reference and context memory via luaL_unref. Allocate an empty slot when no matching driver with the same name is found; The same-name driver reuse mechanism supports repeated iterative registration and avoids exhaustion of slot resources; After registration, a three-level fallback chain callback bridge mechanism is built; Supports five types of Lua callback functions: buildReadRequest, buildWriteRequest, parseResponse, encodeAddr, and parseAddr; The three-level rollback scheduling logic is as follows: prioritize calling callbacks already registered in the Lua layer; If not registered, it will fall back to the C language implementation of the underlying protocol specified by base_proto; When base_proto is set to -1, it is a fully custom mode with no underlying fallback. If no callback is registered, it will directly return an error code. The multi-protocol driver stack supports access from various industrial devices and provides protocol adaptation capabilities for data normalization.

10. The method according to claim 9, characterized in that: Lua custom protocol driver configuration for user data encapsulation and resource isolation and sharing mechanisms; Each registered custom protocol driver corresponds to an independent driver context structure; The structure includes a driver name, a basic protocol type identifier, a slot index, and a Lua registry reference field. The lifecycle of callback functions is managed through luaL_ref and luaL_unref, supporting normal garbage collection and release. The driver object is encapsulated as fully user-defined Lua data and configured with a dedicated metatable. Metatables expose read-only attributes such as error, timespan, timeout, and ticks through the __index metamethod for communication status monitoring. Lua custom drivers and standard C protocol drivers share the same I / Q / M memory register pool; The I area should be configured with ≥2 bytes of contiguous memory, the Q area with ≥2 bytes of memory, and the M area with ≥128 bytes of contiguous memory. Multiple protocols drive data exchange and aggregation within the same physical address space; Communication ports are scheduled and allocated by a unified port management layer; Multiple logical driver instances can be bound to the same UART physical port, and bus conflicts can be avoided through polling scheduling; Device data collected by various protocols are uniformly imported into the I / Q / M memory area to achieve global normalization.

11. A web-visual IDE and industrial edge gateway collaborative programming control device, characterized in that: The edge gateway uses a RISC-V / ARM microcontroller without an operating system as its hardware platform. Under the constraints of limited clock frequency, on-chip SRAM, and internal Flash resources, a single-threaded super loop bare-metal architecture is adopted. The single-threaded super loop carries multiple business functions in parallel. The device includes a Web IDE module, a compilation and translation module, a communication management module, a PLC execution engine module, a protocol driver management module, a storage management module, and a debug data management module; The protocol-driven management module realizes the normalization of data acquisition from multi-source heterogeneous industrial equipment, binds equipment data of different protocols and formats to I / Q / M memory variables, and provides consistent data services to the outside world through MQTT and Modbus Slaver standard protocols. The Web IDE module is stored as a single HTML file in the external SPI Flash of the edge gateway; A bare-metal HTTP server streams content to the browser for loading, with an embedded editor, translation engine, and communication module, requiring no external dependencies; The Web IDE supports drag-and-drop editing of ladder diagrams and embedding of Lua scripts, enabling a hybrid programming mode; The compilation and translation module is embedded in a single HTML file and runs on the browser. Translate the ladder diagram logic into Lua source code according to the two-level Lua metatable binding rules; Automatically insert debug markers and generate CRC32 fingerprints; The communication management module constructs a dual-channel communication architecture using HTTP and WebSocket. The HTTP channel carries static HTML resources and configuration distribution; The WebSocket channel is based on a custom binary function code protocol to enable code pagination and distribution, debugging interaction, and device monitoring. The PLC execution engine module runs in the gateway bare metal environment; Create a Lua virtual machine and configure a two-level metatable data area access interface; Load and execute Lua bytecode, and cycle through input sampling, logic execution and output refresh at a fixed period. The protocol-driven management module manages multiple industrial protocols based on a unified ProtoOps interface. A fixed number of Lua custom protocol slots are reserved, supporting hot registration, name reuse, and three-level callback fallback; The storage management module coordinates the external SPI Flash, FRAM ferroelectric memory, and internal Flash to achieve persistent storage of code, configuration, and process data. The debug data management module uses a two-level linked list structure to cache debug variables under the constraint of bare-metal memory. The number of DebugMaster and DebugNode nodes can be adaptively configured according to the memory capacity of the processor. When a node overflows, the LRU strategy is used to reclaim memory. Respond to Web IDE queries and serialize them into comma-separated strings to return real-time variable data.

12. The apparatus according to claim 11, characterized in that: The microcontroller is configured with a main frequency of ≥72MHz, ≥64KB SRAM, and ≥128KB internal Flash. The Web IDE module integrates a complete front-end interactive interface into a single HTML file; It includes an element toolbar, a ladder list panel, an HTML5 Canvas drawing canvas, a Lua embedded code editor, and a log output panel; The interface elements, drawing engine, styles and interaction logic are all embedded in a single HTML file, without relying on external JS and CSS resources; The Web IDE provides a unified configuration and monitoring interface for normalized device data.

13. The apparatus according to claim 11, characterized in that: The two-level Lua metatable binding rules of the compilation and translation module are as follows: The first-level metatable __index metamethod maps I / Q / M area byte index access to dynamic subtable creation; The second-level metatable __index metamethod is mapped to the plc_read_bit underlying bit read function; The second-level __newindex metamethod is mapped to the plc_write_bit underlying bit write function; Configure separate global Lua tables and corresponding meta tables for byte-level, word-level, double-word-level, and floating-point-level data access; Multi-byte data access is protected by disabling global interrupts; Ladder diagram timer elements are translated into TON / TOF / TRST standard function calls; Normalized device data is addressed and accessed through a metatable mechanism.

14. The apparatus according to claim 11, characterized in that: The WebSocket channel of the communication management module adopts a custom binary function code protocol; Function code 0x00 is used for batch reading of area I; Function code 0x01 is used for batch reading of the Q area; Function code 0x50 is used for Flash paging reading; Function code 0x51 is used for Flash paging writing; Function code 0x52 is used for debugging variable condition queries; The protocol frame multiplexing class Modbus address addressing structure is carried in the WebSocket binary payload; Normalized equipment data and debugging data are transmitted through a unified communication channel.

15. The apparatus according to claim 11, characterized in that: The PLC execution engine module is set to a fixed scan cycle of ≥5ms; The Lua virtual machine provides multiple addressing access interfaces for I-area read-only, Q-area read-write, and M-area through two-level metatables. Area I, Area Q, and Area M are configured with contiguous memory data areas of ≥2 bytes, ≥2 bytes, and ≥128 bytes respectively; Multi-byte memory accesses all employ a dual verification mechanism of interrupt critical sections and address alignment; The normalized equipment data is refreshed and output synchronously in real time within a fixed scanning cycle.

16. The apparatus according to claim 11, characterized in that: The protocol-driven management module is based on the ProtoOps unified interface and is compatible with Modbus series, Mitsubishi FX series, Omron HostLinks, Siemens S7Net, NTP, HTTP and no less than 200 Lua custom protocol slots. All protocol drivers uniformly implement standard interfaces for initialization, connection establishment, request construction, response parsing, and resource release; No fewer than 200 custom Lua slots support driver overwriting and reuse with the same name, automatic memory release, and three-level callback fallback bridging; The protocol driver stack provides comprehensive protocol adaptation capabilities for the normalized acquisition of data from multiple sources.

17. The apparatus according to claim 11, characterized in that: The debug data management module includes a memory data interaction unit and a variable acquisition unit; The memory data interaction unit completes the batch data request and response for the I / Q / M areas through the corresponding function codes; The variable acquisition unit adopts a two-level linked list structure, and the number of nodes in DebugMaster and DebugNode can be adaptively configured according to the memory capacity of the processor. Each node stores the variable name, type identifier, and an 8-byte combined value. When overflow occurs, the LRU strategy is used to evict old nodes and release memory immediately; Match variables to the query string and encapsulate them into a comma-separated string for return; Normalized equipment variables and logic control variables are uniformly incorporated into the debugging management system.

18. The apparatus according to claim 11, characterized in that: The Web IDE module is configured with a debugging visualization display unit; After the CRC32 fingerprint verification is successful, the system enters online debugging mode. The trapezoidal drawing canvas renders the on / off status and color animation of contacts, coils, timers, and connecting lines in real time according to the bit value; The Lua script editor uses inline comments to annotate the real-time runtime values ​​of variables; Normalized device data is presented intuitively in a unified visualization interface.

19. The apparatus according to claim 16, characterized in that: The hot registration mechanism for no less than 200 Lua custom protocol slots includes a driver registration unit, a callback bridging unit, and a resource sharing unit. The driver registration unit matches drivers with the same name, reuses slots, and releases old reference memory. The callback bridging unit implements a three-level fallback logic: Lua callbacks take priority, basic protocols take second, and default behavior is the last resort. The resource sharing unit enables Lua custom drivers and standard C protocol drivers to share the I / Q / M register memory pool; The driver object is encapsulated as complete Lua user data, exposing read-only communication statistics attributes to the outside. Multi-protocol driven systems achieve standardized data collection and unified publishing of device data through resource sharing.

Images