简介面向贴装生产场景这份C#机器视觉框架源码以VM Pro 2.7为基础整合机器人流程控制、多任务调度与视觉处理模块适合有C#和Halcon基础的自动化设备软件工程师二次开发算法底层采用Halcon输入输出参考Cognex VisionPro设计便于迁移理解。资源共615个文件压缩包约204MB主体为240个cs源码、55个dll依赖库另有73个resx界面资源、30个cache编译缓存、11个xml配置及sln/csproj工程文件结构完整可直接打开编译。框架已集成海康威视、大恒、AVT等相机SDK并适配雷塞DMC1000B与IOC0640运动控制卡覆盖视觉定位、多任务协作与运动控制联动源码框架按模块拆分含机器人流程框架、多任务流程框架等目录可按需裁剪或扩展。目前已有63人学习下载适合用于快速搭建自动化产线视觉系统原型或作为课程设计基础框架。1. 植板机源码到底在集成什么为什么值得当成框架来搭一套 SMT 植板机源码真正值钱的不是那几千行 C#而是把机器人流程框架、多任务流程、C# 源码框架和机器视觉源码框架揉在一起的那层关系。植板机本身动作不多接板、夹紧、搬运、定位、送出但放到产线里它要同时伺候 PLC 信号、伺服运动、相机拍照和异常恢复任何一个环节卡住整条线就停。集成相机 SDK 和运动控制卡提供灵活的硬件支持正是这套源码框架存在的理由。它适合的人很具体做自动化上下板、视觉对位、机器人搬运的软件或应用工程师卡在硬件联调、想抄一套可靠架构的人。下面不聊空概念直接按“框架拆开、视觉接入、控制卡驱动、联调避坑”这条落地路径讲。2. C# 源码框架与机器人流程框架先让软件结构扛住产线节拍2.1 机器人流程框架为什么从状态机开始而不是写死动作顺序植板机的机器人流程我一般会先画一张动作图进板到位、抱紧、抬升、搬运、放下、通知下一工站。很多第一版代码就是按这个顺序从上往下写看起来最直白。但产线设备最怕的恰恰是流程走一半出异常比如板子卡在轨道上、真空吸不住、视觉超时。顺序代码在这种时候没有退路只能整段重来而重新启动前还有可能触发一次误动作这是现场最容易出事故的地方。状态机是行业里更稳的做法。它把流程拆成一组离散状态和合法转换每次只允许从当前状态跳到预先定义好的下一个状态非法跳转直接拒绝。这意味着异常可以显式进入 Alarm 状态再从 Alarm 单独定义恢复路径中途急停、断电后代码能确认当前状态而不是从第一步盲目重跑每一步触发条件清楚传感器、到位信号、视觉结果方便单步测试。这是 C# 里最简状态机骨架适合作为机器人流程框架的起点public enum FlowState { WaitBoard, // 等进板传感器 ClampBoard, // 抱紧板边 Transfer, // 搬运到下一工站 VisionCheck, // 视觉拍照定位 SendOut, // 通知下游设备 Alarm, // 异常状态 Finished // 节拍完成 } public class RobotFlowMachine { private FlowState _current FlowState.WaitBoard; private static readonly DictionaryFlowState, ListFlowState Transitions new() { [FlowState.WaitBoard] new() { FlowState.ClampBoard }, [FlowState.ClampBoard] new() { FlowState.Transfer, FlowState.Alarm }, [FlowState.Transfer] new() { FlowState.VisionCheck, FlowState.Alarm }, [FlowState.VisionCheck] new() { FlowState.SendOut, FlowState.Alarm }, [FlowState.SendOut] new() { FlowState.Finished }, [FlowState.Alarm] new() { FlowState.WaitBoard } // 人工复位后回到待机 }; public FlowState Current _current; public bool TryEnter(FlowState next) { if (!Transitions[_current].Contains(next)) return false; _current next; return true; } public void ResetTo(FlowState state) _current state; }这段代码的核心在 Transitions 表。每个状态能去哪些状态一张表列清楚比散落在业务代码里的 if else 好维护得多。参数上有两点要注意一是 Alarm 必须能从任何“非 Finished”状态进入所以日常编码里我会把所有机械动作包一层 try-catch失败就调用 TryEnter(FlowState.Alarm)二是 TryEnter 返回 false 时不能忽略它说明代码逻辑和实际机构状态已经不一致这时候应该停下来报警而不是强行继续。2.2 多任务流程运动、视觉、通信三条线程怎么拆植板机一个节拍里运动卡要走位、相机要抓图、PLC 要握手如果全部塞在 UI 线程里界面卡死是小事运动指令和视觉指令互相等才是大麻烦。多任务流程的常见做法是拆成独立循环加队列循环之间只通过线程安全队列传数据不互相调用方法。参考这类 C# 上位机框架驱动层一般会这样组织public class PlantBoardController { private readonly CancellationTokenSource _cts new(); private readonly ConcurrentQueueVisionRequest _visionQueue new(); public void Start() { Task.Run(() MotionLoop(_cts.Token)); // 运动指令串行处理 Task.Run(() VisionLoop(_cts.Token)); // 视觉取流与定位 Task.Run(() IoCommLoop(_cts.Token)); // PLC/上下游握手 } private void VisionLoop(CancellationToken token) { while (!token.IsCancellationRequested) { if (_visionQueue.TryDequeue(out var req)) { var result _camera.CaptureAndLocate(req.BoardId); _motion.ApplyOffset(result.Dx, result.Dy, result.Angle); } Thread.Sleep(5); // 让出 CPU防止空转 } } private void MotionLoop(CancellationToken token) { while (!token.IsCancellationRequested) { // 从运动队列里取指令执行绝对定位或 IO 翻转 Thread.Sleep(1); } } private void IoCommLoop(CancellationToken token) { while (!token.IsCancellationRequested) { // 读取 PLC 输入把 BoardReady 信号置为 True Thread.Sleep(10); // IO 扫描不需要太频繁 } } }三个循环各干各的是框架里“多任务流程”最直观的体现。参数说明VisionLoop 的 Thread.Sleep(5) 是必要的不写它会占满一个 CPU 核现场机器容易发热节拍反而波动IoCommLoop 用 10ms 周期扫描 IO 已经够还能兼顾 PLC 通信握手比事件驱动简单可靠相机定位结果通过 _motion.ApplyOffset 交给运动层不直接操作控制卡保证运动指令只有一个入口。踩过的坑是把视觉处理直接写在相机 SDK 的回调线程里结果回调线程和运动线程同时抢控制卡轻则超时重则蓝屏。视觉回调里只做“深拷贝图像 入队”算法另开线程跑这是通用的安全写法。2.3 依赖方向UI、业务、硬件驱动三层怎么切这类源码框架在 C# 侧的经典分层是三层UI 层WPF/WinForms、业务层状态机 任务调度 节拍统计、硬件驱动层相机 SDK、控制卡 DLL、PLC 通信。关键不是分三层而是依赖方向业务层只能面向接口编程绝不能直接引用控制卡和相机厂商的 DLL。否则就会出现程序里到处是厂商 SDK 的类型、窗口里直接调用运动函数换一块控制卡等于重写一半代码。标题里写的“提供灵活的硬件支持”落到代码上其实就是接口隔离public interface IMotionProvider { bool Home(); void MoveAbs(double x, double y, double angle); bool WaitInPos(double timeoutMs); int ReadInput(int port); void WriteOutput(int port, bool on); } public interface ICameraProvider : IDisposable { bool Open(string serialNo); bool Start(); CaptureResult CaptureAndLocate(); }业务层保存的应该是 IMotionProvider 和 ICameraProvider 接口实际对象在程序启动时由工厂装配。换硬件时只改驱动层和工厂里的 new 语句业务逻辑一行不用动。UI 层只读取状态机状态和节拍计数不在按钮事件里直接调控制卡。按钮事件要做的是把命令放进业务层的队列业务层在合适的时机执行。这样产线断开重连、手动单步操作时都不会发生“界面点了一下机械臂突然动了”的事故。3. 机器视觉源码框架与相机 SDK 集成从取流到输出像素坐标3.1 相机 SDK 接入的三层封装硬件抽象、取流回调、视觉处理机器视觉源码框架里相机接入位置的设计决定了后续换相机品牌要不要改业务。常见做法是定义一个 ICamera 接口把厂商 SDK 的取流回调封装在实现类里视觉处理逻辑只依赖这个接口。工业相机 SDK 的回调有个明显特点它跑在 SDK 自己的线程里而且传给回调的图像缓冲是 SDK 内部复用的。如果你在回调里直接保存引用下一帧来了数据就被覆盖如果在回调里直接跑视觉算法又会把取流线程拖死。所以封装层要做两件事一是把图像数据深拷贝成托管数组二是立刻投递到视觉任务队列public interface ICamera : IDisposable { bool Open(string sn); bool StartGrabbing(); event EventHandlerFrameReadyEventArgs FrameReady; void Stop(); } public sealed class HikLikeCamera : ICamera { private IntPtr _handle; public bool Open(string sn) { // 调用厂商 SDK 的连接函数这里按实际手册填写 return true; } private void OnImageCallback(IntPtr frameData, uint size, IntPtr user) { var bytes new byte[size]; Marshal.Copy(frameData, bytes, 0, (int)size); // 关键回调里只拷贝和抛事件不在回调里做定位 FrameReady?.Invoke(this, new FrameReadyEventArgs(bytes)); } }这段封装的意义在注释里Marshal.Copy 把非托管指针指向的数据复制到托管数组之后 SDK 再怎么复用那个内存我们手里这份数据都是安全的。视觉处理端订阅 FrameReady 事件把 bytes 解成 Bitmap 或者直接扔给图像处理库这样相机 SDK 的线程压力被完全隔离开。参数上还要注意事件订阅的生存期。程序关闭时先调用 Stop 再释放事件订阅避免回调触发时对象已经释放这也是 C# 里比较容易翻车的地方。早期我还见过有人用 LockBitmap 转 Bitmap 又没 Dispose内存涨得飞快现场只能每天重启上位机。3.2 曝光调整原理先定曝光再用增益补亮做植板机视觉的人基本都遇到过同一个画面板子上的 Mark 点怎么调都发白或者板子过去时拍出来是糊的。曝光调整原理其实一句话就能讲透先满足“不拖影”的曝光上限再在这个范围内用增益和光源把亮度找回来。曝光上限由产线速度决定。相机视野宽度固定时每个像素对应的实际尺寸是确定的板子在曝光时间内走过的距离不能超过一个像素否则边缘会拉丝。算一个典型场景视野宽(mm)分辨率(px)线速度(mm/s)单个像素(mm)最大曝光(ms)10012802000.0780.3920024482000.0820.4115012805000.1170.23比如第一行视野 100mm横向 1280 像素单个像素约 0.078mm产线速度 200mm/s 时曝光超过 0.39ms 就会产生可感知的拖影。实际现场我一般会留 1.5 到 2 倍余量曝光设在 0.2ms 左右再用 LED 低角度光把对比度打出来。增益是最后手段。增益上去以后噪声跟着涨Mark 边缘的二值化阈值会被噪声顶得飘来飘去定位结果也跟着飘。如果你发现现场很暗、曝光调不上去优先加光源亮度或者延长光源频闪时间而不是直接拉增益。这个顺序就是很多人说的“调曝光全靠玄学”背后的真实逻辑其实是一套确定的约束链。3.3 九点标定把像素坐标变成机器人坐标视觉定位算出 Mark 点的像素坐标后必须通过标定矩阵换成运动控制卡的机器人坐标才能交给伺服轴去补正。植板机大多数是平面相机 平面运动九点标定就够了不需要上完整的单应矩阵。九点标定的做法让运动轴带着相机或产品走一个 3×3 阵列在每一个位置拍一次记录像素坐标uv和当时的机器人坐标rxry然后用最小二乘法拟合一个仿射模型public class NinePointCalibrator { private double K0, K1, K2; // 机器人X K0 K1*U K2*V private double K3, K4, K5; // 机器人Y K3 K4*U K5*V public void Fit(double[] u, double[] v, double[] rx, double[] ry) { int n u.Length; double[,] a new double[2 * n, 6]; double[] b new double[2 * n]; for (int i 0; i n; i) { a[2 * i, 0] 1; a[2 * i, 1] u[i]; a[2 * i, 2] v[i]; b[2 * i] rx[i]; a[2 * i 1, 3] 1; a[2 * i 1, 4] u[i]; a[2 * i 1, 5] v[i]; b[2 * i 1] ry[i]; } // 调用 MathNet.Numerics 的 LinearAlgebra 求解 a*xb再把 x 赋给 K0..K5 } public double RobotX(double u, double v) K0 K1 * u K2 * v; public double RobotY(double u, double v) K3 K4 * u K5 * v; }这个模型的物理意义是像素坐标和机器人坐标之间是旋转、缩放加平移的组合。K0 和 K3 是平移量K1、K2、K4、K5 里的交叉项体现了旋转和坐标轴比例不一致。标定时要注意三点标定点要覆盖整个工作范围别缩在角落否则外插偏差很大每个点拍两三次取平均抵消重复定位噪声标定完一定要用未参与拟合的验证点测残差平均残差超过 0.1mm 就该检查机械和光源。4. 运动控制卡集成把点位和偏移变成真正的伺服动作4.1 控制卡 DLL 的 C# 封装入口函数、结构体布局和回调委托运动控制卡通常提供 C/C 动态库C# 这边要用 P/Invoke 对接。最容易出问题的两件事结构体布局和调用约定。控制卡的参数结构体大多是 C 风格连续内存C# 里必须标记 StructLayout否则属性对齐规则一变传入 DLL 的就是一堆乱码。下面是一段简化后的控制卡封装以固高这类常见的运动控制卡为模板[StructLayout(LayoutKind.Sequential)] public struct TrapPrm { public double acc; public double dec; public double vel; } public sealed class MotionCard : IDisposable { private readonly object _sync new(); [DllImport(gts.dll, EntryPoint GT_Open, CallingConvention CallingConvention.StdCall)] private static extern short GT_Open(int cardId); [DllImport(gts.dll, EntryPoint GT_Close, CallingConvention CallingConvention.StdCall)] private static extern short GT_Close(int cardId); [DllImport(gts.dll, EntryPoint GT_SetTrapPrm, CallingConvention CallingConvention.StdCall)] private static extern short GT_SetTrapPrm(short axis, ref TrapPrm prm); public void Open(int cardId) { lock (_sync) { short r GT_Open(cardId); if (r ! 0) throw new MotionCardException(GT_Open error: r); } } public void SetTrap(short axis, double acc, double dec, double vel) { var prm new TrapPrm { acc acc, dec dec, vel vel }; lock (_sync) { short r GT_SetTrapPrm(axis, ref prm); if (r ! 0) throw new MotionCardException(SetTrap error: r); } } public void Dispose() GT_Close(_cardId); }这段封装里lock 是必须的控制卡 SDK 并不是线程安全的多个线程同时调 DLL 会直接导致指令错乱或超时。另一个参数要点是错误码判断几乎所有控制卡函数都返回一个 short 类型错误码我见过太多示例代码调完就扔结果轴没动还在那空等极难排查。把错误码转成异常抛出来现场日志就能直接看到是哪条指令出了问题。4.2 点位表、回零与IO联锁安全的运动控制代码骨架C# 上位机里做点位管理实践中用一个 List 或者 Dictionary 存点位名和坐标就够了。每个点位包含 X、Y、Z 和速度这样换产品时只改点位表不用重新编译运动逻辑。public class AxisPoint { public string Name { get; set; } public double X { get; set; } public double Y { get; set; } public double Z { get; set; } public double Speed { get; set; } } public class PointTable { private readonly Dictionarystring, AxisPoint _points new(); public void Add(AxisPoint p) _points[p.Name] p; public AxisPoint Get(string name) _points[name]; }回零逻辑是运动控制里最不能省的部分。设备第一次上电或者急停复位后伺服轴的实际位置和控制器里记录的位置是脱节的必须通过原点开关重新建立坐标。可靠的回零过程是双速回零先在较高速度下找原点开关的上升沿再反方向离开原点用很低的速度再次压向原点这样消除机械反向间隙和信号抖动带来的误差。IO 联锁同样关键。植板机送板动作必须在夹紧确认、前站和后站都就绪的情况下才允许执行。我一般会把 IO 读取放进运动循环的前置检查读输入 0x01 表示板已到位0x02 表示下游已就绪两个条件同时满足才下发运动指令否则进入等待或者报警。这比在 UI 上做判断可靠得多因为 IO 状态变化不等人。4.3 固高这类控制卡的 C# 开发习惯与常见岔路接触过几类控制卡之后会发现 C# 开发控制卡的思路是相通的区别主要在外围。固高的板卡走的是“板卡 端子板 线缆”架构上位机通过 DLL 直接控制适合快速开发更复杂的系统会走 EtherCAT 总线配置表和轴参数全部在 XML 里运动规划交给主站C# 侧只需要发位置指令和读状态。选控制卡时只看轴数是不够的。要确认需要的 IO 是板载还是必须外扩要看是否支持硬件触发拍照——视觉定位最忌讳软触发软触发延迟不稳定我下面会专门讲。另外还要确认 SDK 有没有 Linux 和 x64 版本很多客户后期会要求把上位机从 Win7 迁到工控一体机驱动跟不上就得换卡这个后悔药不好买。开发习惯上有一条铁律运动指令绝不能从 UI 线程直接发。WPF 按钮事件背后是 UI 线程如果这里直接调用控制卡 DLL界面一个拖动就会把运动周期打断。正确的做法还是回到第 2 章的队列模型UI 只负责把“去哪个点位”这个请求丢给业务线程由业务线程统一调用控制卡封装。5. 视觉与运动联调避坑五个要在装机前想清楚的问题5.1 视觉给的坐标和运动实际位置总差一个固定偏移先重标定再怀疑代码现象是视觉算法算出了 Mark 偏移运动轴补偿过去以后产品位置仍然偏而且偏差方向基本固定。原因大多数不是坐标算错了而是手眼标定出了问题。常见情况有三种九点标定的像素坐标和机器人坐标没有严格对应同一个物理点标定过程里相机或产品有松动标定矩阵用了旋转方向反了的坐标系——比如视觉的 Y 轴向下而运动轴 Y 轴向上模型还在用正拟合硬算。解决方法是先做一次完整的九点标定然后专门用边界上的验证点看残差。残差整体偏大说明标定过程有问题残差分布呈明显方向性说明坐标轴方向或者旋转角度没对齐。每次换线体、换板面高度、拆装相机以后都必须重新标定这是血泪经验不是建议。5.2 拍照时机不准板子还在晃图像就抓了曝光和硬触发一起调现象是视觉定位结果忽好忽坏同一块板连续拍五次坐标波动超过 0.5mm。原因之一在第 3 章讲过曝光过长产生拖影另一个更隐蔽的原因是触发时机。软件触发调用有毫秒级不确定性当板子在相机视野里还在匀速运动时早晚几毫秒拍到的位置都不一样看起来就像视觉自己不稳定。解决措施要双管齐下。第一曝光时间按产线速度重新计算宁可暗一点也要保证不拖影第二用运动控制卡的比较输出或 IO 做硬件触发让板子运动到固定位置时由控制卡直接给相机一个触发信号同时相机的触发延迟设为 0。这样视觉拿到的就是“同一位置、同一时刻”的图像后续定位结果也会从波动变成稳定闭环。5.3 多任务一开运动卡指令就超时驱动不是线程安全的调用必须串行现象是单任务调试时一切正常一旦把视觉、PLC、状态机同时启动运动控制卡偶尔返回超时错误甚至直接丢轴。原因是厂商 SDK 底层并没有做线程保护多个线程同时进入 DLL 调运动函数内部指令缓冲区互相覆盖轻则超时重则驱动异常。很多第一次做 C# 上位机的人都在这翻车以为是自己时序写错了。解决方法是给运动控制卡封装内部加一个全局锁所有指令串行执行同时用单独的运动线程消费指令队列而不是让多个线程各发各的。串行化以后吞吐量完全够一个植板机用因为单个运动指令也就几毫秒真正耗时的是视觉处理而视觉已经在单独的线程和队列里了。5.4 关机再开回零后原点就偏用原点开关加双速回零别用硬限位当原点现象是设备当天生产精度都没问题第二天开机回零第一个产品就偏了而且偏的位置每天还不完全一样。原因是回零只用了硬限位。硬限位的触发位置受机械撞击和传感器重复精度影响每次停在的位置都有微小差异直接被当成了基准点等于把误差注入了整个坐标系。解决方法是让回零参考真正意义上的原点开关并采用双速回零先以较快的速度逼近原点开关确认开关信号有效后反方向退出再以很低的速度重新压向开关取第二次触发位置作为原点。这样做的关键在于同一个方向、同一个速度去触发把反向间隙和机械惯性造成的影响压到最小。另外回零完成后写一个“已回零”状态状态靠谱了后续点位才靠谱。5.5 C# 调用 C 控制卡 DLL 报 Access Violation结构体布局和调用约定优先查现象是程序一调用控制卡函数就崩事件日志里能看到 c0000005Access Violation有些还会在退出时随机崩。原因多数不是驱动坏了而是 P/Invoke 层没对齐。结构体没加 StructLayoutC# 把字段按托管规则对齐传给 DLL 的长度对不上或者调用约定错SDK 是 cdecl 你却按 stdcall 进栈指针被搞乱进程当场崩溃。解决方法是先核对三件事结构体字段的顺序和类型是否和头文件完全一致是否加了 [StructLayout(LayoutKind.Sequential)]DllImport 里的 CallingConvention 是否匹配。还有一个容易被忽视的点x64 和 x86 进程不能混着来控制卡 SDK 是 32 位编译的C# 工程就必须以 x86 编译带 AnyCPU 跑到 64 位进程里照样崩。这个排查顺序能解决掉九成以上的 DLL 崩溃问题剩下的再考虑用日志定位具体是哪个函数。6. 从“能跑通”到“跑得稳”一小时的验证顺序与我的土办法6.1 一套现场验证清单用来验收植板机视觉与运动配合框架搭好、联调完成以后不能急着上线节拍。每次装机、移机、换线体我习惯先花一小时跑一遍下面的清单把结果记在本子上验证项通过标准失败先查什么上电回零连续 10 次原点位置极差 ≤ 0.02mm原点开关安装位置、回零速度、IO 信号抖动九点标定残差验证点平均残差 ≤ 0.1mm标定点覆盖范围、相机固定、运动反向间隙视觉重复定位同一块板连续拍 10 次坐标极差 ≤ 0.05mm曝光时间、光源亮度、夹紧机构是否稳定整线连续节拍按产线要求节拍跑 30 分钟无超时无丢任务队列堆积、相机帧率、控制卡错误码6.2 记录最小数据才能给“玄学问题”留后悔药通过清单还不够我会额外保留三个数据九点标定的残差、单次节拍时间、异常发生时的控制卡错误码。这三个数据平时看不出价值一旦第二天用户打电话说“视觉偶尔偏了”翻出记录马上能判断是标定动了还是光源老化不需要重新拆现场。我自己的习惯是每次更换产品型号先花这半小时把标定和节拍数据留底再决定要不要调曝光和点位速度。很多机器视觉项目后期的所谓“玄学问题”最后都证明是标定残差、触发时机、线程竞争这三件事里的一件。把这套清单和框架里的队列模型、接口隔离落实到位你手里的源码才能从“能转的演示”变成“产线敢用的设备”。希望帮到你。本文还有配套的精品资源点击获取
