简介这份资源是大恒CG300采集卡的C#示例工程面向从事工业控制、图像处理与科学研究的C#开发者尤其是需要基于该卡做二次开发、多通道数据采集与实时显示的技术人员。压缩包共28个文件约78KB以cs源码、exe可执行程序、resources资源、pdb调试符号、resx与settings配置、sln解决方案及csproj工程文件为主结构完整可直接在Visual Studio中打开运行。工程围绕四路采集与场采集帧显示展开涵盖采集卡初始化、多通道数据采集、帧数据实时显示等核心环节并涉及晶振频率与驱动配置匹配的排错思路例如将晶振改为28MHz后即可正常工作的经验对理解硬件时钟与采样同步问题很有帮助。目前已有492人学习下载适合希望快速上手CG300采集卡、搭建稳定高效采集系统的开发者参考借鉴。1. 工业相机采集卡上手从一块CG300板卡到能跑起来的C#工程车间里一台工业相机挂在产线支架上图像死活进不了工控机现场排查半天发现是采集卡SDK没调通。这种场景做机器视觉的同行应该不陌生。大恒CG300系列采集卡属于Camera Link接口的采集卡配套的C# Demo工程就是用来验证板卡、相机、线缆、触发这一整条链路是否打通的。它适合两类人一类是刚拿到板卡、需要快速确认硬件好坏的现场调试人员另一类是准备在C#上位机里集成图像采集功能的开发者想找一个能直接编译运行的起点工程。这份Demo的价值不在于功能多花哨而在于它把SDK初始化、相机枚举、连续采集、回调取图这条最短路径完整跑通了拿过来改改就能接进自己的检测流程里。2. 工程结构拆解SDK封装层、采集流程与界面线程怎么分工拿到一个采集卡Demo先别急着点运行按钮。我一般会先把解决方案目录翻一遍看清楚哪部分是厂商SDK的托管封装哪部分是业务逻辑哪部分是界面。CG300的C# Demo通常围绕大恒自家的采集卡SDK展开SDK本身是C/C的动态库C#这边靠P/Invoke或者厂商提供的.NET包装类来调用。搞清这个分层后面改代码才不会把界面线程和采集线程搅在一起。2.1 解决方案目录与关键文件一个典型的CG300 C# Demo工程目录结构大致是这样CG300Demo/ ├── CG300Demo.sln ├── CG300Demo/ │ ├── Program.cs // 程序入口 │ ├── MainForm.cs // 主界面按钮和图像显示 │ ├── MainForm.Designer.cs │ ├── CameraController.cs // 采集控制封装核心逻辑在这 │ ├── DeviceEnumerator.cs // 设备枚举与打开 │ └── Properties/ ├── GalaxySDK/ // 厂商SDK的.NET封装引用 │ ├── GalaxyCamera.cs │ └── ... └── lib/ // 原生dll运行时必须拷到输出目录 ├── GalaxyC.dll └── ...这里要特别注意lib目录。原生dll不会自动跟着C#的引用走编译能过不代表运行能过运行时找不到dll是新手最常见的翻车点。常见做法是在项目属性里加一个生成后事件把lib下的dll拷到输出目录或者干脆把dll放进系统PATH能搜到的路径。2.2 设备枚举与打开SDK初始化的第一步采集卡Demo的第一段核心代码永远是初始化SDK、枚举设备、打开设备。CG300这类板卡SDK初始化会去扫描板卡上挂的相机返回一个设备列表。下面这段是典型的封装写法// CameraController.cs public bool Initialize() { // 1. SDK全局初始化整个进程只需调用一次 int ret GalaxySDK.IGXInit(); if (ret ! 0) { // 返回码非0通常是驱动没装好或dll版本不匹配 throw new Exception($SDK初始化失败错误码: {ret}); } // 2. 枚举当前板卡上连接的所有相机 var deviceList new ListIGXDeviceInfo(); ret GalaxySDK.IGXUpdateDeviceList(out deviceList); if (ret ! 0 || deviceList.Count 0) { // 枚举不到设备先查相机供电和线缆再查板卡驱动 return false; } // 3. 打开第一个设备实际项目里应该让用户选 _device GalaxySDK.IGXOpenDevice(deviceList[0].DeviceID); return _device ! null; }逻辑说明IGXInit是全局初始化一个进程调一次就够重复调用有的SDK版本会报错。IGXUpdateDeviceList返回的是结构体列表里面包含设备ID、型号、序列号这些信息实际项目里应该把这些信息显示到界面上让用户选而不是像Demo这样直接开第一个。IGXOpenDevice拿到设备句柄后后面所有采集操作都基于这个句柄。参数说明DeviceID是SDK内部标识设备的整数不是相机的序列号别搞混。错误码的含义要对着SDK手册查不同返回码对应驱动、权限、设备占用等不同问题。2.3 连续采集与回调取图打开设备之后设置采集模式、注册回调、启动采集这是采集流程的三板斧。CG300 Demo一般用连续采集模式回调里拿图像数据// 注册回调SDK采到一帧就回调一次 _device.RegisterCaptureCallback(OnFrameReceived); // 设置连续采集模式 _device.SetAcquisitionMode(AcquisitionMode.Continuous); // 启动采集 _device.StartAcquisition(); private void OnFrameReceived(IGXFrame frame) { // 回调在SDK的采集线程里执行不要在这里做耗时操作 // 常见做法拷贝数据丢给界面线程或处理队列 byte[] buffer new byte[frame.Width * frame.Height]; Marshal.Copy(frame.DataPtr, buffer, 0, buffer.Length); // 通过Invoke切回UI线程更新显示 this.BeginInvoke(new Action(() { _currentFrame buffer; pictureBox.Invalidate(); // 触发重绘 })); }逻辑说明回调函数运行在SDK的采集线程上不是UI线程。在这里直接操作控件会抛跨线程异常所以要用BeginInvoke切回去。另外回调里不要做图像处理处理慢了会丢帧正确做法是把数据拷出来丢进队列让独立的工作线程去处理。参数说明frame.Width和frame.Height是当前帧的尺寸frame.DataPtr是原生内存指针必须用Marshal.Copy拷到托管数组不能直接引用因为回调返回后这块内存可能被SDK复用。2.4 界面线程与采集线程的边界Demo里最容易出问题的地方就是线程边界。采集回调在SDK线程图像显示在UI线程图像处理如果也塞进回调三个线程搅在一起界面卡死、丢帧、内存暴涨全来了。合理的分工是回调只负责拷贝数据入队处理线程从队列取数据做算法UI线程只负责显示。Demo为了简单可能直接在回调里Invoke显示但你要往生产环境改第一件事就是把处理逻辑从回调里挪出去。3. 编译运行实操从零把Demo跑起来的完整步骤光看代码不动手永远不知道坑在哪。这一章按顺序走一遍从环境准备到看到图像的流程每一步都给出具体操作和失败时的排查方向。3.1 环境准备与依赖确认动手之前先确认三样东西采集卡驱动装了没、相机供电和线缆接了没、开发环境版本对不对。CG300的驱动一般在厂商提供的安装包里装完之后设备管理器里应该能看到板卡设备。相机这边Camera Link线缆要接对端口相机供电单独确认很多“枚举不到设备”最后查出来是相机没供电。开发环境方面Demo工程通常基于.NET Framework 4.x用Visual Studio打开。如果工程引用了厂商的.NET封装dll确认引用路径没断。原生dll的位数要和工程平台匹配x64工程配x64的dll32位配32位混了就是BadImageFormatException。3.2 编译与首次运行用VS打开sln先别急着F5。第一步是检查平台配置把解决方案平台设成和dll一致的位数。然后生成解决方案看输出窗口有没有警告说dll拷贝失败。生成成功后确认输出目录bin/Debug或bin/Release里有没有原生dll没有就手动拷过去或者配生成后事件。首次运行程序一般会弹主界面点“枚举设备”或“打开相机”按钮。如果设备列表是空的按这个顺序查相机供电→线缆→板卡驱动→SDK版本。如果列表有设备但打开失败多半是设备被别的进程占用了关掉其他采集软件再试。3.3 采集参数配置与图像显示设备打开后Demo一般会提供曝光、增益、触发模式这些参数的设置入口。连续采集模式下先设一个适中的曝光时间太短图像全黑太长一片白。触发模式如果设成外部触发但没接触发源图像永远不来调试阶段先用内触发或连续模式确认链路通。图像显示这块Demo通常用PictureBox或者自己写的控件。如果采集在跑但界面不刷新检查回调有没有真的被调用可以在回调里打个日志或者加个计数器。如果回调在调但界面卡多半是Invoke太频繁考虑降低显示帧率比如每三帧显示一次。3.4 保存图像与基础验证确认能连续看到图像之后下一步是验证数据正确性。Demo一般有单帧保存功能存成bmp或raw。存raw的话要注意像素格式Mono8、BayerRG8、RGB8存出来的数据布局完全不同用错了解析出来就是花屏。验证方法很简单存一帧用图像查看器打开看是不是和相机对着的场景一致。如果花屏先查像素格式设置再查宽高有没有对上。4. 避坑与常见问题枚举不到设备、回调丢帧、内存泄漏怎么查这一章是我自己踩过和帮别人排查过的坑按现象、原因、解决三段式写遇到问题对着查。4.1 枚举不到设备现象程序启动后设备列表为空或者IGXUpdateDeviceList返回0个设备。原因最常见的是相机没供电或线缆松动其次是板卡驱动没装好再就是SDK版本和板卡固件不匹配。解决先看相机指示灯亮不亮换根线缆试试。驱动问题去设备管理器看有没有黄色感叹号。SDK版本问题对着厂商文档确认板卡固件和SDK的兼容关系别自己乱升。4.2 回调丢帧现象采集在跑但显示的帧率明显低于相机标称帧率或者画面一顿一顿的。原因回调里做了耗时操作比如图像处理、文件写入、频繁Invoke。回调线程被占住SDK的帧缓冲满了就丢帧。解决回调里只做数据拷贝拷贝完立刻返回。处理和显示放到独立线程用队列解耦。显示帧率可以主动降没必要每帧都刷界面。4.3 内存持续增长现象程序跑一段时间后内存占用越来越高最后卡死或崩溃。原因回调里每帧都new一个大数组GC来不及回收或者原生内存没释放比如帧数据用完没调SDK的释放接口。解决用对象池复用buffer别每帧new。如果SDK要求手动释放帧确认回调结束前调了释放接口。用性能监视器看托管堆和原生内存哪个在涨定位方向。4.4 图像花屏或颜色不对现象能采到图但图像是花的或者颜色明显不对。原因像素格式设置和实际相机输出不匹配或者宽高、行对齐没对上。解决确认相机输出的像素格式在SDK里设成一致的。注意有些格式有行对齐要求比如宽度不是4的倍数时每行会补字节解析时要按对齐后的行宽算。4.5 程序退出后设备被占用现象关掉程序再打开提示设备被占用打不开。原因程序退出时没调SDK的关闭设备和反初始化接口句柄没释放。解决在窗体的FormClosing事件里先停采集再关设备最后调反初始化。顺序不能反先反初始化再关设备有的SDK会报错。5. 二次开发改造把Demo变成能接进产线检测的采集模块Demo能跑通只是起点真正要用到产线上得把它改成一个稳定的采集模块。这一章讲几个改造方向都是实际项目里会用到的。5.1 封装成独立采集服务Demo的采集逻辑和界面耦合在一起改造第一步是把采集部分抽成一个独立的服务类对外暴露启动、停止、取帧这几个接口。界面只负责调接口和显示采集服务内部管理SDK句柄、回调、缓冲队列。这样换界面、加处理逻辑都不影响采集核心。public class AcquisitionService { private BlockingCollectionbyte[] _frameQueue new BlockingCollectionbyte[](5); private CancellationTokenSource _cts; public void Start() { _cts new CancellationTokenSource(); // 采集线程从SDK回调往队列写 // 处理线程从队列读做算法 Task.Run(() ProcessLoop(_cts.Token)); } public bool TryGetFrame(out byte[] frame, int timeoutMs 100) { return _frameQueue.TryTake(out frame, timeoutMs); } public void Stop() { _cts?.Cancel(); // 停采集、关设备、反初始化顺序不能乱 } }逻辑说明用BlockingCollection做帧队列容量设小一点比如5队列满了自动阻塞回调起到背压作用防止内存无限涨。TryGetFrame给上层提供带超时的取帧接口上层处理慢了也不会把采集拖垮。参数说明队列容量根据处理速度和内存权衡太小丢帧太大吃内存。超时时间按处理帧率设一般设成帧间隔的一半左右。5.2 多相机与触发同步产线上经常一台工控机带多个相机CG300板卡支持多路采集。改造时要考虑多设备管理每个相机一个采集通道触发信号怎么同步。硬触发靠板卡的外触发接口软触发靠SDK的触发命令。多相机场景下帧的时间戳对齐很关键SDK一般会提供时间戳取帧时一起带出来。5.3 异常恢复与日志产线环境不能一崩就停。采集服务要能检测到相机掉线、SDK报错然后自动尝试重连。日志这块把SDK返回码、时间戳、帧号都记下来出问题时能回溯。别用Console.WriteLine用成熟的日志库写到文件方便现场排查。改造点Demo现状生产建议采集与界面耦合在一起抽成独立服务类帧缓冲每帧new数组对象池复用异常处理基本没有掉线重连日志多相机单设备多通道管理时间戳对齐配置硬编码配置文件或界面设置5.4 验证改造效果的方法改完之后怎么确认没改坏我的习惯是做一个压力测试连续采集半小时看内存曲线平不平、帧率稳不稳、有没有丢帧。再模拟异常拔掉相机线缆看程序能不能检测到并恢复。最后拿标准测试图卡拍几张确认图像质量没下降。这套流程走一遍基本能保证采集模块在产线上不会掉链子。从那以后我每次拿到新的采集卡Demo都强制先跑一遍压力测试再往项目里集成省得后面在产线上返工。希望帮到你。本文还有配套的精品资源点击获取