# Shared memory not working with PFC300 **URL:** \ **Category:** Hardware and Linux\ **Created:** [April 7, 2025, 5:30am UTC](https://www.wago.community/t/shared-memory-not-working-with-pfc300/1740 "2025-04-07T05:30:58Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![pehaa](https://avatars.discourse-cdn.com/v4/letter/p/94ad74/32.png) [@pehaa](https://www.wago.community/u/pehaa)\ **Post date:** [April 7, 2025, 5:30am UTC](https://www.wago.community/t/shared-memory-not-working-with-pfc300/1740/1 "2025-04-07T05:30:58Z")
My Codesys project is using shared memory, from WagoAppMem library, to communicate with two processes running in Linux. This has been working flawlesly for years when we have been using pfc100 and pcf200 devices, but now with pfc300 it’s not working. Should it work? I noticed strange behaviour, after I write to shared memory, the sizeof the corresponding file in /dev/shm goes abnormally big. ![image](https://us1.discourse-cdn.com/flex016/uploads/wago/original/2X/6/6ca839e70091bf837c54f585d3286a863952d936.png) so that’s like 274 Petabyte. (I had to look up what’s coming after Terabyte) Any idea how to solve this? ---
**Author:** ![WagoIcard](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/wagoicard/32/1508_2.png) [@WagoIcard](https://www.wago.community/u/WagoIcard)\ **Post date:** [April 7, 2025, 11:56pm UTC](https://www.wago.community/t/shared-memory-not-working-with-pfc300/1740/2 "2025-04-07T23:56:27Z")
Hello, you can use -h with ls to have a better idea of the size. Also i think PFC300 is 64Bit which mean the memory address system is not DWORD (32bit) based but LWORD(64Bit) based Maybe your memory address are shifted between the linux side and the PFC side. ---
**Author:** ![pehaa](https://avatars.discourse-cdn.com/v4/letter/p/94ad74/32.png) [@pehaa](https://www.wago.community/u/pehaa)\ **Post date:** [April 8, 2025, 4:47am UTC](https://www.wago.community/t/shared-memory-not-working-with-pfc300/1740/3 "2025-04-08T04:47:34Z")
Hi, Thanks. Can you specify what you mean by ‘memory address shifting’? In my code, I only have to define the file name for the SHM communication, no addresses. ---
**Author:** ![pehaa](https://avatars.discourse-cdn.com/v4/letter/p/94ad74/32.png) [@pehaa](https://www.wago.community/u/pehaa)\ **Post date:** [April 8, 2025, 11:04am UTC](https://www.wago.community/t/shared-memory-not-working-with-pfc300/1740/4 "2025-04-08T11:04:54Z")
OK, So I send the address of my datablock as a parameter to shm (FBSHAREDMEMORY\_WITHREADWRITE). That address used to be 32 bit, now it’s 64 bit. Is it so that WagoAppMem library is not able to handle the 64 bit address correctly? ---
**Author:** ![WagoIcard](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/wagoicard/32/1508_2.png) [@WagoIcard](https://www.wago.community/u/WagoIcard)\ **Post date:** [April 10, 2025, 12:09am UTC](https://www.wago.community/t/shared-memory-not-working-with-pfc300/1740/5 "2025-04-10T00:09:04Z")
Sorry i may have mistaken, my finding where especially in codesys when I have variable and i want to access them by pointer, before I was using a dword based pointer shift to target my next memory address, on the PFC300 I have to use a LWORD to access the next memory address. I think the WagoAppMem should do this automatically but does your linux part also handle 64bit memory ? or does it map all like on the 32bit memory ? ---
**Author:** ![pehaa](https://avatars.discourse-cdn.com/v4/letter/p/94ad74/32.png) [@pehaa](https://www.wago.community/u/pehaa)\ **Post date:** [May 13, 2025, 9:24am UTC](https://www.wago.community/t/shared-memory-not-working-with-pfc300/1740/6 "2025-05-13T09:24:46Z")
> [@pehaa](#): > > WagoAppMem OK, it turns out that WagoAppMem library has a problem. At least in case there is more than one SHM instance used. My problem was solved by using the Codesys SysShm library instead.