简介压缩包提供了一套C#与CoDeSys共享内存通信的完整例程面向自动化、物联网领域开发者用于解决跨语言进程间高速低延迟数据交换问题相比串口或网络通信可明显降低延迟和复杂度尤其适合PLC控制程序与上位机软件实时交互。资源共含37个文件以C#源码、CoDeSys工程文件和配置文件为核心附带解决方案、编译后的可执行文件与调试符号整体体积仅146KB目录划分明确便于直接对照学习与二次修改。已有3857人学习该资源参考价值得到了验证。通过完整例程读者能掌握基于Marshal类操作共享内存、结构体与CoDeSys变量块匹配映射、以及读写同步和内存对齐的实践经验并可直接运行Demo验证效果非常适合希望快速上手跨语言进程间通信的开发者也可作为相关课程设计或项目初期的参考原型。1. 为什么C#和CoDeSys之间要共享内存一条产线设备的上位机是C#控制器是CoDeSys软PLC两者跑在同一台Windows工控机上。界面每秒要刷新上千个点位历史曲线还要往前端推大块数据。最开始走TCP延迟不稳换OPC UA点位多了以后抖动明显。后来我把两者之间的数据通道换成共享内存往返耗时直接降到微秒级CPU占用还比TCP低了一大截。这件事解决的是同一台机器上两个进程之间的高频、大批量数据交换核心做法是Windows内存映射文件加指针读写C#负责建通道CoDeSys调用系统API去打开。如果你也在做上位机与软PLC的高频数据交互且两者同机部署这篇文章能给你一套能直接照着改的例程以及比例程更值钱的踩坑清单。2. 共享内存方案原理与选型判断2.1 内存映射文件的机制两个进程为什么要通过内存碰头共享内存在Windows上的正式名称是内存映射文件Memory-Mapped File。操作系统把一段物理内存或页文件支撑的映射区域映射到进程的虚拟地址空间里两个进程各自拿到一个指向同一块物理内存的地址。C#里MemoryMappedFile对象就是内核里那个文件映射对象的封装CoDeSys侧通过kernel32的OpenFileMappingW拿到句柄再MapViewOfFile得到指针。关键在于两个进程的虚拟地址可以完全不同但背后指向同一块物理页面所以任何一方写入另一方直接可见。这个机制带来的最直接好处是零拷贝。对比TCP或共享文件数据在进程间传递时不需要经过协议栈的多次缓冲拷贝也不依赖网络组件的调度。代价也很明确通信双方必须跑在同一台机器上因为映射对象的作用域就是本机内核对象命名空间。跨机器不行跨平台也不行——好在CoDeSys软PLC与C#上位机同机部署的场景在设备行业非常常见。用进程模型来理解更清楚。C#进程和CoDeSys运行时进程彼此隔离正常情况下不可能互相访问内存地址。内存映射文件相当于在两者之间开了一扇门门牌号就是那个命名对象。C#把数据写进映射视图CoDeSys把自己的指针指向同一块区域读写就是普通内存操作。整个过程不存在网络帧的组装和解析也没有socket缓冲的延迟所以在高频小数据块交换场景下它的延迟表现天然优于TCP类方案。2.2 是不是非它不可TCP、OPC UA、共享内存的参数对比我在选型时常用下面这张表做判断省去了很多纠结。对比项TCP SocketOPC UA共享内存典型往返延迟100微秒~毫秒级亚毫秒~毫秒级1~10微秒级延迟抖动依赖系统调度抖动明显依赖UA栈线程点位多时加剧极小接近内存访问大批量传输需要分包序列化开销大数据量大时编码开销高天然适合无序列化跨机器能力支持支持不支持实现复杂度中高低调试手段网络抓包UA客户端工具内存查看器、句柄工具我的经验是点位数量在几百个以上且刷新周期在几十毫秒以内共享内存的收益最明显。如果只是几十个开关量和模拟量TCP或Modbus反而更省事因为不需要处理指针和结构体对齐。换一个场景如果上位机和PLC不在同一台机器上共享内存直接出局老老实实走OPC UA或者TCP。还有一个很容易被忽略的维度调试的确定性。共享内存的数据没有协议格式出了问题就是一坨字节必须有结构体定义和可视化工具兜底。所以我的建议是共享内存适合有固定结构、固定长度的数据块交互不适合零散的、动态拼接的消息。通信双方一旦需要灵活的消息语义还是TCP更合适。2.3 CoDeSys侧能不能碰共享内存外部函数调用的边界很多人第一次听说CoDeSys也能操作共享内存时第一反应是PLC里哪有这种库函数。确实标准IEC 61131-3库里没有内存映射相关的功能块但这不妨碍我们实现。CoDeSys Control Win运行时本身就是一个Windows用户态进程它支持通过外部函数声明直接调用系统DLL导出函数。这意味着kernel32.dll里的OpenFileMappingW、MapViewOfFile、UnmapViewOfFile、CloseHandle都能被结构化文本直接声明调用。边界条件有三条实操中必须确认。第一CoDeSys运行时位数必须与C#进程位数一致或者至少都装在64位系统且CoDeSys是64位版本指针长度不一致时传递出来的地址会直接错位。第二调用外部函数传递指针时CoDeSys侧要用匹配的地址类型变量保存MapViewOfFile返回值不能塞进一个普通的DINT里再转换。第三CoDeSys的扫描周期会影响读写时序共享内存本身没有同步机制必须自己在协议层用心跳和状态字兜底。3. C#侧建立共享内存最小可运行工程3.1 创建命名共享内存一个可以直接抄的C#类C#侧的核心是System.IO.MemoryMappedFiles命名空间不需要P/Invoke就能完成映射。我一般把整个通道封装成一个类构造函数接收通道名、容量和读写模式调用方只需要关心Read和Write两个方法。using System; using System.IO.MemoryMappedFiles; using System.Runtime.InteropServices; public class SharedMemoryChannel : IDisposable { private MemoryMappedFile _mmf; private MemoryMappedViewAccessor _view; private readonly string _mapName; private readonly long _capacity; public SharedMemoryChannel(string mapName, long capacity, bool createIfMissing) { _mapName mapName; _capacity capacity; if (createIfMissing) { // 创建或打开服务端先创建客户端后打开 _mmf MemoryMappedFile.CreateOrOpen( mapName, capacity, MemoryMappedFileAccess.ReadWrite); } else { // 客户端模式只打开不创建避免误建出空的映射对象 _mmf MemoryMappedFile.OpenExisting( mapName, MemoryMappedFileAccess.ReadWrite); } _view _mmf.CreateViewAccessor(0, capacity, MemoryMappedFileAccess.ReadWrite); } public void WriteT(long offset, ref T data) where T : struct { _view.Write(offset, ref data); } public void ReadT(long offset, out T data) where T : struct { _view.Read(offset, out data); } public void Dispose() { _view?.Dispose(); _mmf?.Dispose(); } }这段代码里有两个参数值得展开说。第一个是CreateOrOpen与OpenExisting的选择服务端用前者因为首次启动要创建对象客户端用后者避免C#服务还没起来时客户端自己把一个空映射对象建出来等会儿服务端反而打不开。第二个是容量Windows内存映射按页对齐页大小一般是4KB我习惯直接把容量设成结构体的整数倍并对齐到4096避免视图尾部出现无法访问的碎片页。创建视图时还有一个小细节CreateViewAccessor的第一个参数是偏移量第二个是视图大小。我通常直接给完整容量省去按偏移管理的麻烦。如果只映射部分区域后续读写时offset就要相对视图起点计算容易绕晕。3.2 结构体布局与封送避免C#和CoDeSys各说各话共享内存里的数据本质就是一串字节两边如果对字段顺序、类型大小理解不一致读出来的数据就是乱的。C#里用StructLayout明确控制布局CoDeSys侧用相同顺序定义结构体。下面这个结构体是我在项目里常用的一套协议字段。using System; using System.Runtime.InteropServices; [StructLayout(LayoutKind.Sequential, Pack 1)] public struct PlcExchangeData { public byte Command; // 命令字0空闲, 1启动, 2停止 public byte Status; // 状态字0空闲, 1运行中, 2故障 public uint SeqCounter; // 序号每次写入1 public uint Heartbeat; // 心跳CoDeSys每周期1 [MarshalAs(UnmanagedType.ByValArray, SizeConst 256)] public byte[] DataBuffer; // 数据区按需定义长度 }这里最关键的三个坑是不要用boolC#的bool占1字节但封送时可能被当作整型处理CoDeSys侧对不上统一用byte代替。MarshalAs的SizeConst必须与CoDeSys侧数组长度一致差一个字节整个结构体就错位。Pack 1表示不填充对齐字节C#默认按平台对齐如果不指定结构体中间可能被塞进填充字节两边定义不一致。判断结构体大小是否一致C#侧可以用Marshal.SizeOf ()直接算出来。CoDeSys侧用SIZEOF也可以拿到字节数。我在写完结构体后第一件事就是两边打印大小对不上再调整不靠肉眼数。3.3 生命周期与访问权限服务、会话隔离、重连如果C#上位机以Windows服务方式运行共享内存的命名空间就要特别注意。服务进程运行在Session 0交互式桌面程序在Session 1及以上两者对内核对象的默认访问策略不同。共享内存命名带Global前缀可以跨会话可见但需要服务拥有SeCreateGlobalPrivilege权限普通服务默认有普通应用程序在非交互会话里不一定有。还有一个常见问题是进程退出后的对象清理。命名内存映射对象在内核里的生命周期由句柄引用计数决定不是由创建它的进程决定。一旦C#进程崩溃只要还有别的进程持有句柄对象就不会消失。CoDeSys侧如果已经MapViewOfFile成功拿到的是自己的地址映射C#进程退不退出都不影响已有地址的读写问题在于重新创建后内容被清零CoDeSys侧需要检测序号跳变来感知对端重启。给共享内存命名时建议直接用Global开头比如Global\PlcExchangeData。别嫌名字长这一步能省掉后面大量Session隔离的排查。如果遇到打不开的情况用进程管理器确认一下映射对象是否存在再确认当前进程权限比在代码里猜更高效。4. CoDeSys侧实现从声明API到完整读写功能块4.1 在结构化文本里声明kernel32函数CoDeSys里调用外部DLL函数不需要额外安装库直接在POU里声明FUNCTION就可以。但声明必须严格匹配Windows API原型参数类型和顺序错一个都调用失败。下面是四个核心函数的声明写法。FUNCTION OpenFileMappingW : __PVOID VAR_INPUT dwDesiredAccess : DWORD; bInheritHandle : BOOL; lpName : __PVOID; // LPCWSTR, 指向UTF-16字符串 END_VARFUNCTION MapViewOfFile : __PVOID VAR_INPUT hFileMappingObject : __PVOID; dwDesiredAccess : DWORD; dwFileOffsetHigh : DWORD; dwFileOffsetLow : DWORD; dwNumberOfBytesToMap : DWORD; END_VARFUNCTION UnmapViewOfFile : BOOL VAR_INPUT lpBaseAddress : __PVOID; END_VARFUNCTION CloseHandle : BOOL VAR_INPUT hObject : __PVOID; END_VAR声明外部函数时返回类型和指针参数一律用__PVOID不要用DINT代替。__PVOID在CoDeSys里是平台相关的指针类型64位环境下占64位32位环境下占32位。如果你声明成DINT64位环境下高32位被截断MapViewOfFile返回的地址直接变成无效指针一读写就崩。字符串参数也要注意OpenFileMappingW接收的是宽字符串CoDeSys里的STRING默认是ANSI需要先把通道名转成UTF-16字节数组再把数组首地址塞给lpName这一步不知道卡了多少人。4.2 把共享内存封装成功能块FbSharedMemClient直接散着调用API函数后期维护成本高我习惯把它封装成功能块对外只暴露两个方法Open和Close内部管理句柄和指针状态。下面这段是一个最小实现。FUNCTION_BLOCK FbSharedMemClient VAR hMapping : __PVOID; pBase : __PVOID; bOpened : BOOL; END_VAR METHOD Open : BOOL VAR_INPUT bCreate : BOOL; // TRUE创建者, FALSE打开者 sName : STRING(64); // 共享内存名称 END_VAR VAR wszName : ARRAY[0..127] OF BYTE; dwNameLen : DINT; pName : __PVOID; i : DINT; END_VAR打开逻辑分四步把STRING转成UTF-16字节数组调用OpenFileMappingW或CreateFileMappingW判断返回值成功则调用MapViewOfFile。关闭逻辑反着来先UnmapViewOfFile再CloseHandle顺序错了会先释放句柄导致进程冲突。CoDeSys的FB实例如果在一个任务里周期调用Open方法必须在首次调用时完成初始化后面周期只做读写。我通常加一个内部状态机Init、Opening、Opened、Closed。Open成功后才允许读写方法执行Open失败时返回错误码而不是直接崩掉。错误码用GetLastError获取需要再声明一个kernel32函数定义成FUNCTION GetLastError : DWORD即可这个值能直接对微软错误码文档排查效率高很多。4.3 协议层心跳、序号与状态标志位共享内存最大的隐患是数据一致性问题。CoDeSys任务周期比如2msC#侧可能是10ms写一次两边读写没有锁。结构体里的某个DWORD如果跨字节拆分成多次内存访问对端可能读到一半被改写的新值。解决办法就是在协议层做握手机制而不是依赖操作系统给锁。我的做法是设计三件套SeqCounter序号每次写入方写完数据后自增Heartbeat心跳由对端周期递增用于检测存活Status状态字表示当前数据区是否处于可读状态。写方可遵循先写数据区再翻转状态字最后增加序号的顺序读方先读序号和状态字再读数据区最后再读一次序号校验两次序号一致才认可这批数据。这个方案叫作双缓冲校验比加锁简单得多实测在2ms任务周期下万次读取未出现一次错读。// 读侧帧校验伪代码 IF status 1 THEN dwSeq1 : data.SeqCounter; // 此时读取数据区字段 fValue : data.DataBuffer[0]; dwSeq2 : data.SeqCounter; IF dwSeq1 dwSeq2 THEN // 两次序号一致数据有效 ELSE // 数据被写方更新打断丢弃本次 END_IF END_IF注意这个方案不能彻底解决并发问题但它把错读概率压到了极低因为内存映射的写入是原子性相对较强的单指令操作。如果对一致性要求更严格比如机器人实时轨迹数据我会改成分区双缓冲方案写方写A区时读方读B区写完后交换标志。代价是内存尺寸翻倍但彻底消除了读写竞争。5. 避坑与排查共享内存对接常见的5个实测问题5.1 现象CoDeSys侧OpenFileMappingW一直返回空指针原因最常见的是C#进程和CoDeSys进程位数不一致导致对象句柄类型不匹配其次是共享内存名称没有加Global前缀CoDeSys运行在Session 0或不同用户上下文时访问不到。解决先检查两个进程的位数用任务管理器确认。再检查命名是否统一C#和CoDeSys两侧的字符串必须一字不差包括大小写。最后调用GetLastError拿错误码返回2表示系统找不到指定文件返回5表示拒绝访问前者查命名后者查权限。5.2 现象结构体字段读出来错位数值明显不对原因C#侧没有指定Pack对齐结构体中间被插入了填充字节或者CoDeSys侧数组长度和C#侧不一致。解决C#侧所有共享结构体都加[StructLayout(LayoutKind.Sequential, Pack 1)]两边各打印一次SIZEOF确认字节数相同。CoDeSys侧用SIZEOF(MyStruct)C#侧用Marshal.SizeOf两边值必须严格相等。5.3 现象C#服务里能写桌面调试程序读不到原因服务跑在Session 0桌面程序跑在Session 1内核对象默认使用Local命名空间不同会话隔离导致不可见。解决映射名称统一用Global\开头且服务进程需要具备创建全局对象的权限。如果权限受限可以在服务启动时显式设置ACL或者在部署时给服务账户授予相应权限。5.4 现象C#崩溃重启后CoDeSys侧指针没变但数据全是零原因C#进程退出后内核对象引用计数归零映射区域内容被系统清零新进程重新创建时是一块干净内存。CoDeSys侧老指针还在但映射已经被系统层面释放。解决CoDeSys侧必须监控SeqCounter和心跳连续几个周期心跳不再增长就判定对端离线主动Unmap并重新执行Open。不要试图在对方重启期间继续写数据都是白写。5.5 现象数据整体正常但偶发一次值跳变原因CoDeSys任务周期和C#写入周期没有同步读取时正好赶上写入方写入多字节数据的中间状态。解决采用4.3节的双缓冲校验读数据前记录序号读完再校验序号一致。如果跳变出现在高频率写场景可以考虑把数据类型改成原子长度比如4字节对齐的DWORD拆开写两次。6. 上产线前验证吞吐量测试与长期稳定性的三个习惯把共享内存跑通不代表能交付我在这个方向上栽过跟头后来养成了一套验证习惯。第一件事是压测C#侧用Stopwatch循环写100万次结构体统计平均单次耗时和总耗时CoDeSys侧在线监视SeqCounter递增速率。正常在同一台工控机上100万次小结构体写入应在几秒内完成平均往返在微秒级。如果出现毫秒级耗时优先检查是否有触发了磁盘交换的大镜像或者CoDeSys任务周期设置过长。第二个习惯是故意杀进程测试。C#侧写一个定时重启逻辑每隔几分钟重启进程观察CoDeSys侧能否在三个周期内自动重连重连后序号是否连续。抓不到这个现场的话以后产线上掉一次电就是灾难。第三个习惯是把心跳和错误码全部暴露到界面上的调试页。我习惯在C#上位机加一个诊断窗口显示心跳计数、序号、最近一次错误码、重连次数和帧丢弃次数。这些数据对比TCP方案里的粘包重传统计更直观因为共享内存没有协议栈中间层出问题就是底层指针或地址问题数据一眼就能定位到是写入方还是读取方。整个方案做完后我最大的教训是别省掉协议层的心跳序号设计。共享内存太简单了简单到让人误以为不需要协议实际上没有序号和状态字出问题连定位都无从下手。双缓冲校验那十几行代码换来的是现场半年没出现一次错读数据。希望帮到你。本文还有配套的精品资源点击获取
简介压缩包提供了一套C#与CoDeSys共享内存通信的完整例程面向自动化、物联网领域开发者用于解决跨语言进程间高速低延迟数据交换问题相比串口或网络通信可明显降低延迟和复杂度尤其适合PLC控制程序与上位机软件实时交互。资源共含37个文件以C#源码、CoDeSys工程文件和配置文件为核心附带解决方案、编译后的可执行文件与调试符号整体体积仅146KB目录划分明确便于直接对照学习与二次修改。已有3857人学习该资源参考价值得到了验证。通过完整例程读者能掌握基于Marshal类操作共享内存、结构体与CoDeSys变量块匹配映射、以及读写同步和内存对齐的实践经验并可直接运行Demo验证效果非常适合希望快速上手跨语言进程间通信的开发者也可作为相关课程设计或项目初期的参考原型。1. 为什么C#和CoDeSys之间要共享内存一条产线设备的上位机是C#控制器是CoDeSys软PLC两者跑在同一台Windows工控机上。界面每秒要刷新上千个点位历史曲线还要往前端推大块数据。最开始走TCP延迟不稳换OPC UA点位多了以后抖动明显。后来我把两者之间的数据通道换成共享内存往返耗时直接降到微秒级CPU占用还比TCP低了一大截。这件事解决的是同一台机器上两个进程之间的高频、大批量数据交换核心做法是Windows内存映射文件加指针读写C#负责建通道CoDeSys调用系统API去打开。如果你也在做上位机与软PLC的高频数据交互且两者同机部署这篇文章能给你一套能直接照着改的例程以及比例程更值钱的踩坑清单。2. 共享内存方案原理与选型判断2.1 内存映射文件的机制两个进程为什么要通过内存碰头共享内存在Windows上的正式名称是内存映射文件Memory-Mapped File。操作系统把一段物理内存或页文件支撑的映射区域映射到进程的虚拟地址空间里两个进程各自拿到一个指向同一块物理内存的地址。C#里MemoryMappedFile对象就是内核里那个文件映射对象的封装CoDeSys侧通过kernel32的OpenFileMappingW拿到句柄再MapViewOfFile得到指针。关键在于两个进程的虚拟地址可以完全不同但背后指向同一块物理页面所以任何一方写入另一方直接可见。这个机制带来的最直接好处是零拷贝。对比TCP或共享文件数据在进程间传递时不需要经过协议栈的多次缓冲拷贝也不依赖网络组件的调度。代价也很明确通信双方必须跑在同一台机器上因为映射对象的作用域就是本机内核对象命名空间。跨机器不行跨平台也不行——好在CoDeSys软PLC与C#上位机同机部署的场景在设备行业非常常见。用进程模型来理解更清楚。C#进程和CoDeSys运行时进程彼此隔离正常情况下不可能互相访问内存地址。内存映射文件相当于在两者之间开了一扇门门牌号就是那个命名对象。C#把数据写进映射视图CoDeSys把自己的指针指向同一块区域读写就是普通内存操作。整个过程不存在网络帧的组装和解析也没有socket缓冲的延迟所以在高频小数据块交换场景下它的延迟表现天然优于TCP类方案。2.2 是不是非它不可TCP、OPC UA、共享内存的参数对比我在选型时常用下面这张表做判断省去了很多纠结。对比项TCP SocketOPC UA共享内存典型往返延迟100微秒~毫秒级亚毫秒~毫秒级1~10微秒级延迟抖动依赖系统调度抖动明显依赖UA栈线程点位多时加剧极小接近内存访问大批量传输需要分包序列化开销大数据量大时编码开销高天然适合无序列化跨机器能力支持支持不支持实现复杂度中高低调试手段网络抓包UA客户端工具内存查看器、句柄工具我的经验是点位数量在几百个以上且刷新周期在几十毫秒以内共享内存的收益最明显。如果只是几十个开关量和模拟量TCP或Modbus反而更省事因为不需要处理指针和结构体对齐。换一个场景如果上位机和PLC不在同一台机器上共享内存直接出局老老实实走OPC UA或者TCP。还有一个很容易被忽略的维度调试的确定性。共享内存的数据没有协议格式出了问题就是一坨字节必须有结构体定义和可视化工具兜底。所以我的建议是共享内存适合有固定结构、固定长度的数据块交互不适合零散的、动态拼接的消息。通信双方一旦需要灵活的消息语义还是TCP更合适。2.3 CoDeSys侧能不能碰共享内存外部函数调用的边界很多人第一次听说CoDeSys也能操作共享内存时第一反应是PLC里哪有这种库函数。确实标准IEC 61131-3库里没有内存映射相关的功能块但这不妨碍我们实现。CoDeSys Control Win运行时本身就是一个Windows用户态进程它支持通过外部函数声明直接调用系统DLL导出函数。这意味着kernel32.dll里的OpenFileMappingW、MapViewOfFile、UnmapViewOfFile、CloseHandle都能被结构化文本直接声明调用。边界条件有三条实操中必须确认。第一CoDeSys运行时位数必须与C#进程位数一致或者至少都装在64位系统且CoDeSys是64位版本指针长度不一致时传递出来的地址会直接错位。第二调用外部函数传递指针时CoDeSys侧要用匹配的地址类型变量保存MapViewOfFile返回值不能塞进一个普通的DINT里再转换。第三CoDeSys的扫描周期会影响读写时序共享内存本身没有同步机制必须自己在协议层用心跳和状态字兜底。3. C#侧建立共享内存最小可运行工程3.1 创建命名共享内存一个可以直接抄的C#类C#侧的核心是System.IO.MemoryMappedFiles命名空间不需要P/Invoke就能完成映射。我一般把整个通道封装成一个类构造函数接收通道名、容量和读写模式调用方只需要关心Read和Write两个方法。using System; using System.IO.MemoryMappedFiles; using System.Runtime.InteropServices; public class SharedMemoryChannel : IDisposable { private MemoryMappedFile _mmf; private MemoryMappedViewAccessor _view; private readonly string _mapName; private readonly long _capacity; public SharedMemoryChannel(string mapName, long capacity, bool createIfMissing) { _mapName mapName; _capacity capacity; if (createIfMissing) { // 创建或打开服务端先创建客户端后打开 _mmf MemoryMappedFile.CreateOrOpen( mapName, capacity, MemoryMappedFileAccess.ReadWrite); } else { // 客户端模式只打开不创建避免误建出空的映射对象 _mmf MemoryMappedFile.OpenExisting( mapName, MemoryMappedFileAccess.ReadWrite); } _view _mmf.CreateViewAccessor(0, capacity, MemoryMappedFileAccess.ReadWrite); } public void WriteT(long offset, ref T data) where T : struct { _view.Write(offset, ref data); } public void ReadT(long offset, out T data) where T : struct { _view.Read(offset, out data); } public void Dispose() { _view?.Dispose(); _mmf?.Dispose(); } }这段代码里有两个参数值得展开说。第一个是CreateOrOpen与OpenExisting的选择服务端用前者因为首次启动要创建对象客户端用后者避免C#服务还没起来时客户端自己把一个空映射对象建出来等会儿服务端反而打不开。第二个是容量Windows内存映射按页对齐页大小一般是4KB我习惯直接把容量设成结构体的整数倍并对齐到4096避免视图尾部出现无法访问的碎片页。创建视图时还有一个小细节CreateViewAccessor的第一个参数是偏移量第二个是视图大小。我通常直接给完整容量省去按偏移管理的麻烦。如果只映射部分区域后续读写时offset就要相对视图起点计算容易绕晕。3.2 结构体布局与封送避免C#和CoDeSys各说各话共享内存里的数据本质就是一串字节两边如果对字段顺序、类型大小理解不一致读出来的数据就是乱的。C#里用StructLayout明确控制布局CoDeSys侧用相同顺序定义结构体。下面这个结构体是我在项目里常用的一套协议字段。using System; using System.Runtime.InteropServices; [StructLayout(LayoutKind.Sequential, Pack 1)] public struct PlcExchangeData { public byte Command; // 命令字0空闲, 1启动, 2停止 public byte Status; // 状态字0空闲, 1运行中, 2故障 public uint SeqCounter; // 序号每次写入1 public uint Heartbeat; // 心跳CoDeSys每周期1 [MarshalAs(UnmanagedType.ByValArray, SizeConst 256)] public byte[] DataBuffer; // 数据区按需定义长度 }这里最关键的三个坑是不要用boolC#的bool占1字节但封送时可能被当作整型处理CoDeSys侧对不上统一用byte代替。MarshalAs的SizeConst必须与CoDeSys侧数组长度一致差一个字节整个结构体就错位。Pack 1表示不填充对齐字节C#默认按平台对齐如果不指定结构体中间可能被塞进填充字节两边定义不一致。判断结构体大小是否一致C#侧可以用Marshal.SizeOf ()直接算出来。CoDeSys侧用SIZEOF也可以拿到字节数。我在写完结构体后第一件事就是两边打印大小对不上再调整不靠肉眼数。3.3 生命周期与访问权限服务、会话隔离、重连如果C#上位机以Windows服务方式运行共享内存的命名空间就要特别注意。服务进程运行在Session 0交互式桌面程序在Session 1及以上两者对内核对象的默认访问策略不同。共享内存命名带Global前缀可以跨会话可见但需要服务拥有SeCreateGlobalPrivilege权限普通服务默认有普通应用程序在非交互会话里不一定有。还有一个常见问题是进程退出后的对象清理。命名内存映射对象在内核里的生命周期由句柄引用计数决定不是由创建它的进程决定。一旦C#进程崩溃只要还有别的进程持有句柄对象就不会消失。CoDeSys侧如果已经MapViewOfFile成功拿到的是自己的地址映射C#进程退不退出都不影响已有地址的读写问题在于重新创建后内容被清零CoDeSys侧需要检测序号跳变来感知对端重启。给共享内存命名时建议直接用Global开头比如Global\PlcExchangeData。别嫌名字长这一步能省掉后面大量Session隔离的排查。如果遇到打不开的情况用进程管理器确认一下映射对象是否存在再确认当前进程权限比在代码里猜更高效。4. CoDeSys侧实现从声明API到完整读写功能块4.1 在结构化文本里声明kernel32函数CoDeSys里调用外部DLL函数不需要额外安装库直接在POU里声明FUNCTION就可以。但声明必须严格匹配Windows API原型参数类型和顺序错一个都调用失败。下面是四个核心函数的声明写法。FUNCTION OpenFileMappingW : __PVOID VAR_INPUT dwDesiredAccess : DWORD; bInheritHandle : BOOL; lpName : __PVOID; // LPCWSTR, 指向UTF-16字符串 END_VARFUNCTION MapViewOfFile : __PVOID VAR_INPUT hFileMappingObject : __PVOID; dwDesiredAccess : DWORD; dwFileOffsetHigh : DWORD; dwFileOffsetLow : DWORD; dwNumberOfBytesToMap : DWORD; END_VARFUNCTION UnmapViewOfFile : BOOL VAR_INPUT lpBaseAddress : __PVOID; END_VARFUNCTION CloseHandle : BOOL VAR_INPUT hObject : __PVOID; END_VAR声明外部函数时返回类型和指针参数一律用__PVOID不要用DINT代替。__PVOID在CoDeSys里是平台相关的指针类型64位环境下占64位32位环境下占32位。如果你声明成DINT64位环境下高32位被截断MapViewOfFile返回的地址直接变成无效指针一读写就崩。字符串参数也要注意OpenFileMappingW接收的是宽字符串CoDeSys里的STRING默认是ANSI需要先把通道名转成UTF-16字节数组再把数组首地址塞给lpName这一步不知道卡了多少人。4.2 把共享内存封装成功能块FbSharedMemClient直接散着调用API函数后期维护成本高我习惯把它封装成功能块对外只暴露两个方法Open和Close内部管理句柄和指针状态。下面这段是一个最小实现。FUNCTION_BLOCK FbSharedMemClient VAR hMapping : __PVOID; pBase : __PVOID; bOpened : BOOL; END_VAR METHOD Open : BOOL VAR_INPUT bCreate : BOOL; // TRUE创建者, FALSE打开者 sName : STRING(64); // 共享内存名称 END_VAR VAR wszName : ARRAY[0..127] OF BYTE; dwNameLen : DINT; pName : __PVOID; i : DINT; END_VAR打开逻辑分四步把STRING转成UTF-16字节数组调用OpenFileMappingW或CreateFileMappingW判断返回值成功则调用MapViewOfFile。关闭逻辑反着来先UnmapViewOfFile再CloseHandle顺序错了会先释放句柄导致进程冲突。CoDeSys的FB实例如果在一个任务里周期调用Open方法必须在首次调用时完成初始化后面周期只做读写。我通常加一个内部状态机Init、Opening、Opened、Closed。Open成功后才允许读写方法执行Open失败时返回错误码而不是直接崩掉。错误码用GetLastError获取需要再声明一个kernel32函数定义成FUNCTION GetLastError : DWORD即可这个值能直接对微软错误码文档排查效率高很多。4.3 协议层心跳、序号与状态标志位共享内存最大的隐患是数据一致性问题。CoDeSys任务周期比如2msC#侧可能是10ms写一次两边读写没有锁。结构体里的某个DWORD如果跨字节拆分成多次内存访问对端可能读到一半被改写的新值。解决办法就是在协议层做握手机制而不是依赖操作系统给锁。我的做法是设计三件套SeqCounter序号每次写入方写完数据后自增Heartbeat心跳由对端周期递增用于检测存活Status状态字表示当前数据区是否处于可读状态。写方可遵循先写数据区再翻转状态字最后增加序号的顺序读方先读序号和状态字再读数据区最后再读一次序号校验两次序号一致才认可这批数据。这个方案叫作双缓冲校验比加锁简单得多实测在2ms任务周期下万次读取未出现一次错读。// 读侧帧校验伪代码 IF status 1 THEN dwSeq1 : data.SeqCounter; // 此时读取数据区字段 fValue : data.DataBuffer[0]; dwSeq2 : data.SeqCounter; IF dwSeq1 dwSeq2 THEN // 两次序号一致数据有效 ELSE // 数据被写方更新打断丢弃本次 END_IF END_IF注意这个方案不能彻底解决并发问题但它把错读概率压到了极低因为内存映射的写入是原子性相对较强的单指令操作。如果对一致性要求更严格比如机器人实时轨迹数据我会改成分区双缓冲方案写方写A区时读方读B区写完后交换标志。代价是内存尺寸翻倍但彻底消除了读写竞争。5. 避坑与排查共享内存对接常见的5个实测问题5.1 现象CoDeSys侧OpenFileMappingW一直返回空指针原因最常见的是C#进程和CoDeSys进程位数不一致导致对象句柄类型不匹配其次是共享内存名称没有加Global前缀CoDeSys运行在Session 0或不同用户上下文时访问不到。解决先检查两个进程的位数用任务管理器确认。再检查命名是否统一C#和CoDeSys两侧的字符串必须一字不差包括大小写。最后调用GetLastError拿错误码返回2表示系统找不到指定文件返回5表示拒绝访问前者查命名后者查权限。5.2 现象结构体字段读出来错位数值明显不对原因C#侧没有指定Pack对齐结构体中间被插入了填充字节或者CoDeSys侧数组长度和C#侧不一致。解决C#侧所有共享结构体都加[StructLayout(LayoutKind.Sequential, Pack 1)]两边各打印一次SIZEOF确认字节数相同。CoDeSys侧用SIZEOF(MyStruct)C#侧用Marshal.SizeOf两边值必须严格相等。5.3 现象C#服务里能写桌面调试程序读不到原因服务跑在Session 0桌面程序跑在Session 1内核对象默认使用Local命名空间不同会话隔离导致不可见。解决映射名称统一用Global\开头且服务进程需要具备创建全局对象的权限。如果权限受限可以在服务启动时显式设置ACL或者在部署时给服务账户授予相应权限。5.4 现象C#崩溃重启后CoDeSys侧指针没变但数据全是零原因C#进程退出后内核对象引用计数归零映射区域内容被系统清零新进程重新创建时是一块干净内存。CoDeSys侧老指针还在但映射已经被系统层面释放。解决CoDeSys侧必须监控SeqCounter和心跳连续几个周期心跳不再增长就判定对端离线主动Unmap并重新执行Open。不要试图在对方重启期间继续写数据都是白写。5.5 现象数据整体正常但偶发一次值跳变原因CoDeSys任务周期和C#写入周期没有同步读取时正好赶上写入方写入多字节数据的中间状态。解决采用4.3节的双缓冲校验读数据前记录序号读完再校验序号一致。如果跳变出现在高频率写场景可以考虑把数据类型改成原子长度比如4字节对齐的DWORD拆开写两次。6. 上产线前验证吞吐量测试与长期稳定性的三个习惯把共享内存跑通不代表能交付我在这个方向上栽过跟头后来养成了一套验证习惯。第一件事是压测C#侧用Stopwatch循环写100万次结构体统计平均单次耗时和总耗时CoDeSys侧在线监视SeqCounter递增速率。正常在同一台工控机上100万次小结构体写入应在几秒内完成平均往返在微秒级。如果出现毫秒级耗时优先检查是否有触发了磁盘交换的大镜像或者CoDeSys任务周期设置过长。第二个习惯是故意杀进程测试。C#侧写一个定时重启逻辑每隔几分钟重启进程观察CoDeSys侧能否在三个周期内自动重连重连后序号是否连续。抓不到这个现场的话以后产线上掉一次电就是灾难。第三个习惯是把心跳和错误码全部暴露到界面上的调试页。我习惯在C#上位机加一个诊断窗口显示心跳计数、序号、最近一次错误码、重连次数和帧丢弃次数。这些数据对比TCP方案里的粘包重传统计更直观因为共享内存没有协议栈中间层出问题就是底层指针或地址问题数据一眼就能定位到是写入方还是读取方。整个方案做完后我最大的教训是别省掉协议层的心跳序号设计。共享内存太简单了简单到让人误以为不需要协议实际上没有序号和状态字出问题连定位都无从下手。双缓冲校验那十几行代码换来的是现场半年没出现一次错读数据。希望帮到你。本文还有配套的精品资源点击获取
