Control Application Debugging for Device-Independent Code Generation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing control systems face inefficiencies due to device dependency in development environments, making it difficult to debug executable code for target hardware before conversion to a high-level language, and limiting engineering efficiency.
Innovation Solution
An engineering apparatus that converts control logic and data from a first programming language into a second programming language, allowing for the generation of executable code that can be debugged before conversion, using an algorithm converter, type management unit, instance management unit, and build controller, along with a symbol analyzer and instance/type list database, to separate and manage control logic and data.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the control application is converted to a high-level language program before debugging, then the device dependency of the development environment is reduced, but the ability to debug the control application directly is lost
Solution Approach 1:
The patent introduces an intermediary debugging system that receives the control application in the original programming language, converts it to an intermediate representation, and enables debugging before final compilation to target-specific executable code. This intermediary layer preserves the ability to debug while reducing device dependency.
Solution Approach 2:
The compilation process is segmented into multiple stages: initial conversion to intermediate representation, debugging phase, and final compilation to target executable code. This segmentation allows debugging to occur at an intermediate stage rather than requiring conversion to the final high-level language or target code.
2Reliability
If multiple device-specific development environments are used to control different target hardware, then each environment can be optimized for its specific hardware, but the operator needs to be proficient in multiple environments which reduces engineering efficiency
Solution Approach 1:
The patent creates a universal development environment that can handle multiple target hardware types through a common intermediate representation and unified toolchain. The system maintains hardware-specific optimizations while providing a single, consistent development interface for all target devices.
Solution Approach 2:
The system changes the parameter of the development approach from device-specific programming languages and environments to a unified intermediate representation that can be compiled to multiple targets. This parameter change enables cross-platform development while preserving hardware-specific optimizations.
3Reliability
If the control application is debugged after conversion to executable code, then the code can be executed on the target hardware, but modifications require recompilation and redeployment which time-consuming
Solution Approach 1:
The patent performs preliminary debugging actions on the control application in the intermediate representation stage, before final compilation to executable code. This allows most debugging and modification work to be completed beforehand, reducing the need for time-consuming recompilation and redeployment cycles.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
An engineering apparatus (10) according to the present disclosure generates generating executable code, which causes target hardware (20) to operate, from a control application. The engineering apparatus (10) includes an algorithm converter (102) that converts control logic included in the control application into control logic code, a type management unit (103) that outputs a type definition code corresponding to a data block structure of data held by a function block included in the control application, an instance management unit (104) that outputs a memory allocation code that allocates an instance of the function block to memory, and a build controller (104) that generates the executable code based on the control logic code, the type definition code, and the memory allocation code. Executable code for execution by target hardware is debugged while the executable code is in the form of a control application before conversion to a high-level language.