解决方案:基于LabVIEW的自动条码数据采集系统

　　解决方案:基于LabVIEW的自动条码数据采集系统

　　基于LabVIEW的条码数据自动采集系统（天津工范学院，天津300222） [摘要] 基于LabVIEW平台，通过串口实现条码扫描器的控制和条码数据的读取，自动采集条码数据开发了采集系统，可以对现场条码数据进行快速采集和管理，并利用条码数据进行数据库访问。关键词：虚拟仪器；实验室视图；条码; 数据采集​​; 数据库，CLC 编号：F760.5；：2005!01!

　　在产品生产、运输、销售、跟踪等各个环节中，条码作为信息的载体，自始至终都发挥着关键作用，尤其是在企业信息越来越多，需要大量信息的情况下。被处理、信息采集

和处理已经被企业放在了越来越高的位置。本文采用LabVIEW图形化编程语言实现对条码扫描器的控制和通过串口读取条码数据，开发了一种条码数据自动采集系统，可以快速采集和管理条码数据现场，并使用条码数据访问数据库。LabVIEWLabVIEW语言是由美国国家仪器公司（NI）开发的一种基于图形的编程语言，其中收录

丰富的数据采集、数据信号分析、控制等子程序。生成的程序是方框图的形式。用户可以创建和调用子程序编程的方法使创建的程序模块化，易于调试、理解和维护，程序编程简单直观，特别适用于数据采集和处理系统。LabVIEW使用LabVIEW软件对串口进行操作。串口的操作需要初始化串口，并对串口进行读写操作。LabVIEW通过Seria子模板上的图标完成串口的设置并进行读写操作。“SeriaPortInit”图标为串口参数设置图标。设置参数包括串口号、数据位、停止位、奇偶校验位、数据流控制、波特率，如图1所示。 ,“SeriaPortRead”图标，读取串口数据图标，需要指定读取的字 基于LabVIEW的条码自动数据采集系统 条码技术是自动识别技术的一个分支，在众多的自动识别技术中，条码技术因其具有快速、准确、成本低、制造容易、可靠性高等优点，迅速渗透到计算机管理的各个领域。在当今信息社会，条码技术显示出广阔的发展前景。

　　

" />

　　条码扫描器条码扫描器是自动化生产线必备的自动控制设备之一。该设备可以摆脱繁重的人工抄录录入工作，减少人为失误，提高产线工作效率，为产品和产线提供精准准确的数据统计。详细资料。采用先进的条码扫描和数据远程通讯技术，90%以上的用户操作都可以通过远程系统完成，最大限度地实现了工作现场系统数据的实时、快速、准确的录入、查询和更新。本系统中的条码扫描器采用美国SYMBOL公司的微型激光条码扫描器，型号为LS-l220I300A。条码扫描器采用串口进行数据传输，外观如图2所示，串口的引脚定义及功能如表1所示。在本系统中，引脚1、2、3、5、6分别连接到PCI65l4的a0通道，控制条码扫描器的工作。当引脚 1 的电平由高变为低时，扫描仪开始扫描。将引脚电平设置为高电平以准备下一次扫描。2和3是信号发送和接收，5个脚接地，这3个脚接电脑的串口。该引脚连接+5V电源，为条码扫描器提供工作电压。条码扫描*敏*感*词*外​​形图 Fig.barcodecannerappearanceBarcode scanner 串口管脚定义及功能 默认值为高电平 TXD输出 发送数据 RXD输入 接收数据 目标输入 正常扫描时置高电平 Ground ground Power+5V电源 CTS输入 辅助通道清零发送 RTS输出 辅助通道请求发送 Beeper输出 驱动蜂鸣器信号，输出频率条码扫描器工作模式设置条码扫描器的工作模式有两种方式：一种是编程方式，通过串口发送命令控制字来设置条码扫描器的工作模式；另一种是使用条码扫描器扫描具有特定含义的条码来设置其工作方式。set high level Ground ground Power+5V 电源 CTS 输入辅助通道清除发送RTS 输出辅助通道请求发送Beeper 输出驱动蜂鸣器信号，输出频率条码扫描器工作模式设置条码扫描器工作模式有两种方式：一种是编程方式，通过串口发送命令控制字，设置条码扫描器的工作模式；另一种是使用条码扫描器扫描具有特定含义的条码来设置其工作方式。set high level Ground ground Power+5V 电源 CTS 输入辅助通道清除发送RTS 输出辅助通道请求发送Beeper 输出驱动蜂鸣器信号，输出频率条码扫描器工作模式设置条码扫描器工作模式有两种方式：一种是编程方式，通过串口发送命令控制字，设置条码扫描器的工作模式；另一种是使用条码扫描器扫描具有特定含义的条码来设置其工作方式。

　　本系统采用第二种方法设置条码扫描器的工作模式。使用条码扫描器扫描图3所示的条码，我们将其工作方式设置为默认方式。其默认设置为：波特率：9600bp；数据位：7 停止位：2位；奇偶校验位：EVEN；触发方式：电平触发。设置条码扫描器为条码默认工作模式 图barcodecanneretdefaut 条码扫描器串口控制 本系统采用LabVIEW图形化编程实现对条码扫描器的控制和通过串口读取条码数据，以及利用LabVIEW控制条码扫描器前面板如图4a所示，控制流程图如图4b所示。前面板变量与流程图一一对应。各项参数设置完成后，按下运行键即可实现条码扫描器的数据采集。读书。在图4b的流程图中，SeriaPortRead.vi图标从串口读取数据放入缓冲区，并将数据发送给显示控件进行显示。运行结果如图4a所示。如果在运行过​​程中出现错误，比如读取数据的时间超过了串口默认的数据等待时间，系统会弹出对话框告诉用户错误代码，让用户选择是停止还是继续读取运行，如图5所示。条码扫描器串口控制图.eriacontrobarcodecanner系统数据库访问及远程控制LabSL使用MicrooftADO语言完成数据库访问，

　　本系统使用LabSL实现本地数据库的访问，实现双向打包工程PACKAGINGENGINEERINGVo.26错误显示对话框。LabVEW具有强大的网络通讯功能，使LabVEW用户可以轻松编写具有强大网络通讯功能的LabVEW应用软件，实现远程控制。此外，LabVEW还拥有远程面板访问技术，用户可以在互联网上直接控制远程服务前面板。但是LabSOL还没有开发远程数据库访问的功能。LabSOL在研究Microsot AD控件的远程数据库访问功能后，成功实现了对远程数据库的访问。本系统利用LabVEW强大的网络功能，实现远程控制和各种联网。终端的访问或控制功能通过网页浏览器实现对V的远程控制。基于虚拟仪器技术的自动条码数据采集系统适应检测自动化的需要，充分利用现代计算机技术和软硬件资源的优势，实现了检测系统的自动化、*敏*感*词*和高度灵活性，解决了检测自动化的问题。劳动强度大，效率低，影响产品质量，实现生产数据与管理业务的无缝对接，减轻管理人员的工作量，提高企业生产效率，增强企业竞争力。

　　

" />

　　南京金东康条码系统*敏*感*词* 条码检测技术及条码检测器金卡项目，2003（12）：3032 李洪波。条码扫描技术在现代工业中的应用（一）[J]．中国物流与采购，2003（13）：46 48 快递实用技术教程[M]．北京：中国铁道出版社，2004 二维条码在仓储中的应用[J]．包装工程, 2003, 24(5): 62 63 杨乐平, 李海涛, 赵勇, 等．LabVEW高级程序设计［M］．北京：清华大学出版社，2003 Virtual Instrument and LabVEWTM Express Program Design 2004（上接第39期） 粘合剂的粘度和剪切强度相应增加，这是由于随着反应时间的延长，改性等反应，接枝和交联继续，PS大分子上接枝的极性基团和交联度增加，因此结合强度增加。当反应时间达到1h时，粘度和剪切强度没有明显增加。反应2小时后，粘度继续急剧增加。反应3小时后，粘度达到12. 0Pa·s，但剪切强度反而下降。原因是反应时间过长，胶水的流动性、润湿性、渗透性因过度交联和团聚而变差（胶液稳定性差），导致胶液的流动性下降。改性PS粘合剂的粘合强度。综合考虑，修改时间为1小时。时间对剪切强度和粘度的影响

　　PS胶固含量大于40%，旋转粘度大于3.4Pa，室温剪切强度大于3.Mpa。游离醛、甲苯、*敏*感*词*等有害物质限量低于标准要求；单体BA、MAA、改性时间、交联剂、填料等都会对胶粘剂的剪切强度和粘度产生很大的影响。利用废聚苯乙烯泡沫制备防冻胶［J］. 淮海工学院, 2003, 12 (2): 47 48 再生聚苯乙烯的化学改性及应用［J］．化学工程师，1999，（3）：32 废聚苯乙烯的化学回收[J]．化学环境保护, 1998, 18 (6): 332 337 科学与粘合, 2004, (1): 5052 废聚苯乙烯泡沫塑料回收制备防冻胶的研究［J］.化学与胶粘剂, 1999, (1): 42 43 利用废聚苯乙烯泡沫塑料制备改性现场胶粘剂的研究 胶粘剂, 1998, (4): 910高强耐水瓦楞纸板淀粉粘合剂的研制［J］．包装工程, 2003, 24(6): 30 31 绿色纸塑胶粘剂的研究[J]．包装工程, 2004, 25(3): 7

　　解决方案:API 快速开发平台设计思考

　　点击上面的“芋头源代码”，选择“”

　　她在乎前波还是后波？

　　会浪的浪才是好浪！

　　每天8:55更新文章，每天掉百万根头发……

　　源码精品专栏

　　之前讲API网关的时候讲到快速开发平台，就是把API快速开发的一些内容放到API网关里面。次元状态。

　　对于API网关来说，更多的是解决运行状态的问题。API网关本身应该轻量级设计，不要做过多的协议转换、适配、数据映射等工作。这些任务应该在API开发平台上完成。API开发平台最终开发出来并暴露了一个标准的Http API接口，并将该接口注册并连接到API网关。

　　从API生命周期管理的角度，整个子系统划分如下：

　　简单来说，这部分可以分解为四个子系统，分别是API开发平台、API网关引擎、API监控运维平台、API全生命周期管控平台。

　　对于传统ESB总线中的适配器，协议转换等相关繁重的内容可以转移到API快速开发平台来完成，即API开发平台对外暴露标准的API服务接口，注册并连接到API网关引擎. 对于API监控平台，从引擎采集日志信息，用于API性能监控和日志监控分析。

　　API全生命周期管控平台实现了API接口从设计、开发、测试、部署到上线的全生命周期管理。也可以理解为底层三个子系统的统一管理入口，实现与以下三个子系统的集成。

　　针对API开发平台开发配置的微服务API接口，可以支持自动部署到微服务运行平台。

　　在整个API开发平台的实现中，核心思想应该还是以对象建模为驱动。通过对象建模，很好的实现了接口与底层数据库、数据库表的解耦，也方便实现底层多库多表的支持能力。

　　目前很多API快速开发平台都是基于数据库对象或者表，直接发布类似CRUD的API接口服务。但是在直接发布数据库表的基础上，我们还是推荐反向对象层，方便后续在对象层进行相关组合。规则扩展等操作。

　　对象建模和 API 接口契约

　　可以直接在API开发平台上创建对象，定义数据项。该对象是一个多层树结构实体。一个对象可以生成多个表到数据库。对于已有的数据对象，也可以将它们组合起来形成复合对象结构。

　　对象的好处是一个完整的对象属于同一个生命周期，可以一起用于事务控制。

　　一个设计良好的对象可以默认生成标准的POST、GET、DELETE等接口操作方法。类似下图，整个对象接口契约的生成应该也是自动的。

　　定义对象可以直接生成RAML、YAML、WADL等接口契约文件。

　　与Swagger工具类似，完成的对象建模本身也可以直接导出不同语言不同开发框架下的客户端消费框架，服务端提供框架代码。

　　对象适应数据库

　　前面提到过，它既可以直接逆向数据库的对象，也可以在对象建模完成后，将对象适配到数据库中。完成对象与数据库表的映射。一个对象可以映射到多个数据库表，所以在映射过程中除了要完成数据库表和字段的映射外，还需要完成主外键关联的映射操作。

　　完成对象模型与数据库表的映射适配后，基础版本的API接口已经可用。

　　API接口发布

　　对于完成的对象定义，您可以选择发布哪些API接口服务能力。比如只能选择发布查询接口，或者只能选择发布数据导入的POST接口等。

　　注意API接口的发布，具体是基于全局对象建模，配置需要发布到接口的具体数据项信息。很多时候，我们对数据对象的操作并不是对整个对象集合进行操作，而只是对某些数据项进行操作。

　　API接口模拟测试验证

　　发布的API接口可以进行模拟和测试验证，因此需要提供在线API测试工具，方便对API接口进行在线测试。同时，可以保存测试过的用例和测试数据。

　　API接口文档生成

　　支持自动生成API接口文档的能力。这个地方可以直接对接开源的Swagger等工具，实现API接口文档的自动生成功能。

　　对象定义完成后，可以根据对象自动生成相关的API接口。这里简单罗列一下常用的基于对象的接口方法，主要包括添加一条数据，根据主键更新、查询、删除数据。还有一些是基于条件查询对数据进行查询相关的操作。

　　在GtiHub开源了另外一个xmysql工具，可以直接将整个mysql数据库中的数据库表发布为RestAPI接口，可以安装试用。

　　

" />

　　npm install -g xmysql<br />xmysql -h localhost -u mysqlUsername -p mysqlPassword -d databaseName<br />http://localhost:3000<br />

　　注意需要提前安装Node.js。部分接口方法列表如下：

　　由于生成的API接口没有相关权限控制，本开源工具仅用于测试验证。但是生成的方法和API可以作为API开发工具时的参考。

　　实际上，对于API接口的生成，我们不建议所有复杂查询条件下的查询都通过GET方式实现。更好的想法是使用 POST 方法将查询条件作为 POST 输入进行处理。

　　复合对象只生成一次

　　例如，以订单为对象，实际上收录

了订单表头和订单明细表，在生成API时，可以一次生成基于订单对象的插入和查询操作。最终查询的是一个订单复合实体Json数据。对于订单插入，也是先准备好整个订单实体信息，调用一次API接口完成数据插入，也方便实现API接口时的交易控制。

　　复合对象生成的API接口更类似于领域对象暴露的API接口服务能力。

　　分页支持

　　对于查询API接口服务的生成，需要支持分页能力，具体页面的大小，本次查询访问的具体页数等信息都可以设置为API接口的查询输入参数。

　　我们讲了基于对象发布API接口服务，但是还有一些业务规则逻辑接口，复杂的管理数据查询接口等，不能简单的通过对象自动生成。

　　因此，也需要能够基于方法发布API接口服务。

　　即API快速开发平台可以自定义API接口，详细定义API接口的输入参数和输出参数信息。同时，用于定义接口实现和后台方法的绑定。

　　实现与JAR包中API接口的绑定

　　可以实现与JAR包中方法或函数的绑定，将方法或函数发布为Http API接口方法。这种实现在目前很多公有云的云服务总线产品中都能看到。

　　实现和动态 SQL 绑定

　　定义好的API接口方法可以绑定动态SQL。其中，动态SQL本身有特定的动态输入参数，这些输入参数与API接口定义中的输入进行映射。同时将SQL语句查询的输出结果与API接口定义的输出字段进行映射。

　　如果动态SQL是插入或更新类，也可以通过参数化变量来进行数据映射和绑定操作。

　　与存储过程绑定

　　数据库存储过程实际上是一个方法函数，所以API接口定义的输入输出可以与数据库存储过程的输入输出进行映射绑定。

　　需要注意的是，不同的数据库存储过程在schema信息的获取和适配上是有区别的，这也是为什么上图中要建立一个独立的统一数据库适配层的原因。

　　API接口开发过程中，可以进行一些简单的规则处理。详情如下：

　　输入数据完整性检查

　　检查输入数据的完整性，包括场景的数据类型、长度、范围约束，这些都比较容易通过配置实现。

　　数据项之间的规则处理

　　可以对多个数据项进行简单的规则处理，包括场景数据映射、数据丰富、数据截取等，这些也是主流的传统ESB总线产品所支持的。

　　自定义脚本语言

　　API快速开发平台本身可以作为低代码开发平台的子类。因此，如果能够支持自定义脚本语言进行规则处理，整体的扩展性和灵活性将得到极大的提升。

　　消息头和输出保留

　　对于API开发平台发布的API接口，需要事先约定输入消息头、输出异常类型、异常代码、信息等字段。

　　输入的消息头往往收录

用户名、Token等访问安全验证的字段，以及路由、寻呼等相关的扩展字段信息。对于输出字段，需要约定返回的异常类型、编码、异常信息等，尤其是涉及到数据CUD操作时，需要按照约定的输出字段进行输出。

　　API开发平台可以进一步提供服务组合和服务编排能力。该能力的实现不适用于API网关，需要在API开发平台上实现。

　　服务组合编排就是服务组合、服务组装等，希望这些东西都可以通过服务编排来完成，而不是简单的完成单个服务的设计开发。它是将多个原子服务组合或组装在一起，形成一个新的服务并提供它的能力。让我们用一个例子来说明。

　　比如有A、B、C三个原子服务，我们通过服务编排形成一个新的D服务。

　　

" />

　　三个原子服务都是查询服务。希望组装一个新的服务，同时返回A、B、C三个服务的查询结果。

　　这就是我们所说的服务组合能力。例如，我们可以将合约基本信息查询、合约条款信息查询、合约执行信息查询这三个基本的原子服务组合起来，最后返回一个综合服务信息查询的服务，一次返回三个查询。结果。

　　在这种场景下，我们需要考虑查询结果应该并行返回还是分层返回。

　　两个查询类的原子服务最终需要返回两个数据集关联查询的结果集

　　微服务架构中底层数据库拆分后经常会遇到这种情况。例如物料基础信息的查询和采购订单明细的查询，是在两个独立的数据库中提供的。而我们要返回的查询结果集是物料代码、名称、型号、单位、价格、采购数量的复合结果集。

　　在这种场景下，往往是在前端功能开发时组装的。其实可以考虑在服务编排层能不能解决这个问题。写代码很容易解决这个问题，但是需要是可视化的服务编排配置方式。做起来其实挺难的。

　　裁剪和丰富单个现有服务以形成新的服务输出

　　这个也暂时收录

在服务编排的范围内，即仍然是一个输入服务，但是输出是提供一个新的服务。

　　即对单个已有服务进行剪裁和丰富，比如过滤掉一些数据项作为输出结果，固定加入一些数据项作为输入等。这些简单的服务剪裁、丰富，或者简单的数据转换都可以在服务编排时完成并提供新的服务。

　　多个原子服务的进程式串行连接和表单服务提供

　　这是我们经常看到的一种服务编排场景，即直接编排A、B、C三个服务，即服务A的输出直接成为服务B的输入，服务B的输出成为输出服务 C . 如果这只是上面的假设，那么这种基于流程的服务编排还是非常简单易实现的。

　　但实际的难点在于服务A的输出本身需要是服务C的输出，同时服务A和服务B的输出也可能是整体输出的一部分，这本身就增加了难度服务编排的可视化设计。

　　单一业务服务为主，但安排多个业务规则逻辑处理服务

　　这也是经常遇到的场景。比如我们在导入合同信息时，首先要调用合同有效性校验服务，同时调用预算信息查扣服务进行相关的完整性和业务规则校验。这些校验完成后，调用实际的合约信息导入服务。如果验证失败，则直接返回失败结果。

　　这种服务编排往往是我们在实际开发前端功能时的服务组装逻辑。

　　多个导入服务组装成一个导入服务合并导入并形成新服务

　　这个场景其实对应的是场景一，既然可以将多个服务组合起来形成一个组合的结果返回，那么自然是将多个导入服务组合成一个导入服务，一次性完成数据导入。

　　比如有项目信息导入和项目WBS信息导入两个原子服务，那么我们可以提供一个新的项目信息导入服务，一次性完成项目基础信息和项目WBS信息的导入。

　　在这些场景中我们可以看到，其实服务编排就是常见的服务串接、服务并联下的输入输出合并、服务内容的丰富和裁剪等场景。在理想的场景下，我们最希望达到的是，一个业务功能点的实现，可以完全通过服务编排的可视化设计来完成。

　　有关服务编排的详细信息，请参考以下内容：

　　从 ESB 服务组合编排到 NetflixConductor 微服务编排

　　对于快速的API开发平台，复杂的业务规则编码难以实现。因此，当有复杂的业务规则实现时，还是建议开发者自己开发代码来完成。因此，整个平台应该提供源码导出功能，导出的源码应该可以直接编译，不需要API开发平台就可以部署运行。

　　对于导出的源码，考虑到后续API接口变更的场景，建议约定扩展部分。

　　比如一个标准的API接口服务实现方法，可以在前后添加扩展处理。

　　//BeforeDo();<br />//ProcessAPI();<br />//AfterDo();<br />

　　这样可以在接口实现之前进行额外的业务规则处理和完整性验证，在接口返回数据之前可以对输出的数据做进一步的处理和处理。

　　微服务应用

　　可以将多个对象或多个API接口服务打包成一个微服务应用进行部署和发布。所以这里引入微服务集的概念，对微服务API进行封装。

　　打包后的微服务可以导出为独立的JAR包进行部署，也可以直接托管部署在API开发平台上。对于API开发平台本身，应该是对接微服务运行平台的。

　　欢迎加入我的知识星球，一起探讨架构，交流源码。要加入，请按住下面的二维码：

　　知识星球上已更新源码，分析如下：

　　最近更新的系列《太郎SpringBoot 2.X入门》20多篇，涵盖MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo 、RabbitMQ、RocketMQ、Kafka、性能测试等。

　　提供了一个近3W行代码的SpringBoot实例，以及一个4W多行代码的电商微服务项目。