How to limit the memory access

[acxysty]

Dear All

We are extensively using Nano and FMD in our systems. We are very happy with them.

We usually communicate with MODBUS over TCP with external devices and it works fine. But this protocol gives an acces to the whole memory space.

Is there a way to limit the memory access by MODBUS overTCP  to a limited memory space eg DM 1 to DN100.

Regards

TYS

[support]

For Nano-10 and FMD PLC with FRAM-RTC-xxx you can store data in FRAM using SAVE_EEP and load them back using LOAD_EEP and these space are not accessible by Modbus protocol.

[acxysty]

Thank you for your answer.
Regards
TY

[Philippe Parmentier]

Hello everybody,

That's a good news... But can you give me more details about that way of using the LOAD_EEP variables.

1) If the FRAM-256 RTC is present, the pseudo eeprom is not used anymore and replace by the FRAM memory that can handle unlimited read/write. Is it right?

2)If the fact of Using the LOAD_EEP command is as faster as using the DM[xx] acces or will it slow the complete ladder speed process?

Regards
 

[support]

Yes that is correct. The presence of FRAM-RTC-xxx means LOAD_EEP and SAVE_EEP will work with FRAM.

Reading/writing data out of FRAM is very fast too. In fact it fast enough that DM[1001] to DM[4000] are actually implemented in FRAM.  You can test the performance to see if it works well enough for you.

[Philippe Parmentier]

Greetings,

I've done a small test to see the performances of reaing DM[] or LOAD_EEP() Integer..

and the results are

for DM reading, it take             129,4µs
for LOAD_EEP reading it take  169,8µs

Here is the code used:

A = STATUS(21)
SETLCD 1, 1, "DM =" + STR$(DM[1]) + " / " + STR$(STATUS(21)-A)
A = STATUS(21)
SETLCD 2, 1, "EEP=" + STR$(LOAD_EEP(1)) + " / " + STR$(STATUS(21)-A)
A = STATUS(21)
SETLCD 3, 1, "DM =" + STR$(DM[2]) + " / " + STR$(STATUS(21)-A)
A = STATUS(21)
SETLCD 4, 1, "EEP=" + STR$(LOAD_EEP(2)) + " / " + STR$(STATUS(21)-A)

[garysdickinson]

Philiippe,

You've doing great work.  I think that your calculations for DM vs EEP access are a bit off. Much of the time that your test code reports, is not due to DM vs EEP access.  most of the time is involved in the update of the LCD display and STR$ functions.

I took a different approach to trying to get an estimate on the time required to access DM vs EEP.  A read of EEP takes about 7.4 us longer than a read of DM.

This is the test code that I used:


A = STATUS(21)
Z = DM[1]
B = STATUS(21)
C = B-A      ' Time to access 16 bit integer from DM
A = STATUS(21)
Z = LOAD_EEP(1)
B = STATUS(21)
D = B-A      ' Time to access 16 bit integer from EEP
A = STATUS(21)
B = STATUS(21)
E = B-A         ' Time between Status calls
SETLCD 0,1,"\01"   ' Clear screen
SETLCD 1, 1, "DM = " + STR$(C/10) + "." + STR$(C MOD 10)
SETLCD 2, 1, "EEP = " + STR$(D/10) + "." + STR$(D MOD 10)
SETLCD 3, 1, "No Access  = " + STR$(E/10) + "." + STR$(E MOD 10)
[/color]

This is what I see on a FMD-16, r79A without the FRAM-RTC installed:

DM = 49.3
EPP = 54.0
No Access  = 28.4

Unfortunately, I killed my FMD-16 when I attempted to install the FRAM-RTC.

My other test PLC is too old and does not support the STATUS(21) function.

Gary D

[Philippe Parmentier]

Thanks Gary,

My original test was not to calculate the real 'reading time' and my description was faulty, but just to see if DM reading is faster than EEP reading... and we reached both the same conclusion...

It was to estimate what is the best solution for my code to get out of the code some message display and also prevent some modbus access to some value.. but it look that using EEP memory for calculation that are made at every ladder loop will slow down the ladder loop....
 In my current test by changing that, I go from 1000 ladder loops per second (more than 2000 on a most simple ladder login) to 600 ladder loops per second just by changing the DM variable by LOAD_EEP variable...
As far as my code is not yet fully done, it will slow down again and I try to stay over the 500 loops per second on average.

For 'human operation' it's still ok, but for electrical critical device.. it can be an issue.

[support]

Is your program running custom function that accesses the DM[] variable or LOAD_EEP() function every scan of the ladder program?  Does it need to? The PLC is most optimal such that the custom function are called as  {dCusF} which is "differentiated up" - which means it run ONCE when the ladder logic condition goes from OFF to ON.  Unless you elect to tuse the "{CusFn}" version of it, which runs on every scan. In most applications it is not necessary to access the variables on every scan but only periodically using a clock pulse.

If you need to monitor time critical data you can define some inputs as interrupt input or use the periodical interrupt time so that only critical data get processed first regardless of the ladder scan time of the PLC.