业务开发实践中，发现开发业务逻辑为了便于调整要么是走可配置方式要么是走脚本支持方式，可配置方式当前没见到有完美的，用起来都很别扭，而脚本方式的确很多商业软件就是这样的，但是无形当中要求了业务开发人员的脚本语言能力；为了做第一个纯配置方式的复杂业务开发，我实现了这个通过函数名调用任意用户后增加dll里未知函数的功能，实践测试了一下，相当风骚，先备份一个源码在这里；后续基于这个有很多玩法。 具体代码如下:

上位机框架雏形介绍20221126yes@she.vin一、雏形原始目标：实现通用硬件管理系统；实现业务逻辑管理系统；实现环境语言：qt5；实现周期2个月；实现模式单人； 实际实现细节：实际实现已完全达成目标，并增加很多周边配套功能，基本可以用于项目开发，有待项目验证。a.硬件管理系统具体功能 实现硬件以插件方式替换的功能，在业务功能不变情况下随机更换底层运动卡硬件插件，而无需做任何编程工作即可完成对整个项目硬件层面的调整；减少对各种卡的熟悉时间成本，及卡本身的成本，使开发使用人员不用关心硬件层面的实现，能专注于业务功能实现，快速应对项目；（当前仅实现运动控制卡及io卡的上层管理，后续将增加PLC，扫码枪，机器人，光源控制器，CCD，高速模拟量模块等）； 在项目硬件未确认情况下即可用虚拟卡进行项目的业务逻辑开发，而无需关心控制硬件是否已选定，便于早期调试，业务验证，可以改变传统的选硬件出电气图，确认轴，气缸等的接线后才能开始编程的模式，以一种全新的姿态去做项目，可以高节奏高效率的去开展工作；（本人曾经用自己写的PYTHON 版的上位机框架同时做5个项目，这在几年前是不敢想也不敢操作的）； 支持硬件配置文件的一键导入导出功能，整个能快速打通电气与软件之间的壁垒；电气在整理BOM表的时候字段按我们提供的excel格式即可一次操作多方使用;无论是硬件确认没确认给硬件一个符号代号即可；也可以减少部门间因为叫法定义偏差而造成的沟通成本； 支持硬件调试，可以将硬件管理模块独立输出成小工具供电气处理阶段的调试辅助，便于快速对IO，调电机等；配置信息可在后续直接使用，便于将整个开发过程串通起来，减少低效沟通带来的时间成本；硬件插件可默认采用通用界面，后续留有扩展可自动识别用户自定义界面，便于特殊硬件的特殊处理； B.业务管理框架1.为完善本模块又编写了一套变量管理系统，支持实时监控，变量，同时为业务插件间交互提供了可靠的方式；2.业务模块可随编写者心意，自由定义功能、功能涉及实现步骤排序、跳转、监控、旁通、单步等；3.每个业务模块只需要实现组成不用关心业务控制，系统会自动分配线程池去关联并组织运行； C.整体特点1.所有项目开发不用公开任何框架源码实现，仅依靠头文件和功能介绍即可，减少耦合与实现的弊端。开发者可以将整个框架当作一个全功能的函数库，按常规模式开发，不用框架的业务管理自己按底层支持函数，开发自己的业务管理部分，自己的硬件管理界面；完全做到无任何限制，任意定义自己的软件框架结构；如果想偷懒就用系统默认框架，如果想玩界面就自己写界面插件，如果不认可所有已有框架界面就当个全功能函数库来用，自己写配置界面和软件整体界面，以及其他任意界面；可大可小伸缩性极强；2.支持32位，64位，release,debug模式的自动调用，只需要编译不同模式的主引导程序即可，环境适配性强；3.如果用自定义界面可以不用开放ZKHY.exe，按规则写好界面插件放置到UI目录后则自动调整为用户的自定义界面； 具体项目开发步骤导入电气按格式输出的项目元器件到项目；创建虚拟控制卡，匹配导入硬件命名即可；进行业务模块开发（进行无实卡模式调试）；待开发完成后，修改虚拟卡配置为实际使用卡；上机验证（由于基于接口方式，虚拟卡能正常的，实体卡在封装正确的情况下一定正确，几乎验证不花时间）；业务逻辑单步测试；单个任务整体测试；整机任务测试；交机；