Agv调度系统通用版

介绍

基于.net 6.0编写的版本，区别于之前的java版本，本系统可以直接查看项数据，不用侦听Redis，对内存要求低。

项目说明

WinFormsApp是基于winform+BlaorWebView的，本文撰写时blazorwebview尚处于预览版，只是一个demo，要换成web也可以。不建议IIS，可直接用kestrel！！ Dispatch 为核心类库，目前是.net6.0，有兴趣的小伙伴可以自己改为.net framework4.8（语法上有小差异），或者配合kestrel，只要Launch对象作为单例不被框架释放即可

Dispatch类库结构简要说明

DispatchData

所有的数据和算法核心，AGV调度也算高并发项目，写入高频，数据库容易达到写入瓶颈，不建议使用数据库来做数据的保存，可使用Redis和Mongodb等内存数据库来缓存实时数据，用于程序更新或者崩溃重启后的场景恢复。

Model

数据库基本信息的映射类，可自己进行扩展和修改，不管你使用ef,还是sqlsuger,还是freesql，还是dapper，或者mongodb，都可以。

Receive

这一块涉及的方面比较多，AGV消息的解析和指令（AgvEvent)，端口的侦听（***Listener)，各设备的解析和指令（IDeviceEvent是事件的定义，DemoDevice是示例类） Dispatch开头的是协议解析后的具体的处理。 之前在使用java版本时使用的是spring框架，每条消息进入时都创建线程去处理，线程池和gc的开销都不低，一个线程从处理到反馈，可能耗时超过了两条消息之间的时间差。 .net的异步操作在这一块很有性能优势

DataInit

初始数据和场景恢复类，可自行扩展

Config

一些常量的定义，比如AGV的尺寸，与前方AGV保持的距离等。

AGV业务描述说明

有图有真相

1. 左上角是Marker和Route之间的关系，不同的厂商有不同的说明，有些叫点位和路线、路径。两个marker之间连起来的就是Route。虚线框为区域，相当于公路的十字路口，只要AGV存在相碰撞的可能，就要划这样的区域。区域不一定是矩形，本程序支持多边形，只要区域不存在重叠。

2. 中间大图是AGV处理大致逻辑

3. 传输坞，也可以叫机台，反正是各厂商的设备。但是一台设备存在多个料口的情况，这里指料口。机台发送过来的协议里面，必须体现是哪个料口，结合IP就能知道是哪个口。之前的项目就遇到过20个设备40个料口共用2个IP的情况。 模式和之前java版本不一样。之前是调度为主动，各机台被动。 之前的流程： AGV到达=>申请传输直到传输坞允许=>转动电机=>传输完成后申请离开=>传输坞同意后离开 现在的流程： AGV到达传输坞并通知传输坞=>传输坞满足进出料的时候询问AGV是否还在=>传输坞要求AGV转动电机=>AGV转动电机=>（传输完成后告之传输坞）=>传输坞通知AGV离开 从PLC工程师的角度和传输控制上，现在的流程更合理，机台满足收发料的时候直接给消息AGV配合就行，AGV处于被动模式，事故责任清晰。

4. 前方区域内检测有无其它AGV，有则需要停，没有就继续进行。这是之前java版本里面没有的。这一块知识涉及三角函数和线性代数，有兴趣的可以去研究研究

其它

代码中存在大量的注释，也存在方法（不确定性），小伙伴们自己去增减。个人建议现场linux + nginx + asp.net core + supervisor的方式部署，更新程序相当的方便（不用停止程序再手动启动），如果能上AMD的CPU会更好（CPU核多还便宜） 如果是windows10，也不坏，不过记得关闭自动更新。能上asp.net core就上asp.net core，对外开放数据接口相当的方便。 项目中没有存日志，如果需要日志的，推荐mongodb和seq，真的不要太简单太爽。ELK什么的，真的不是首选。

切记：网络不好的车间，先保证网络的稳定性。网络越好工作压力越小。