Optimized block access

[aferro17]

Hello @plcpeople,

Your project is amazing. I'm an Automation software developer and which mostly integrate SCADA, PLCs and some middleware software.

I was wondering if some S7 optimized block access reading and writing will be implemented instead of the old absolute address way. The feature you developed for having something similar on js side is awesome, but my collagues says (and also siemens) that havind dbs with absolute access slows down the cpu cycle.

Have a good one

[plcpeople]

There are no plans for this, because this is only supported with the new protocol which is still not documented either by Siemens or elsewhere on the internet. We have not found the speed effect of using absolute data blocks to be a problem for us in testing - I don't think the effect is large especially for a small number of blocks and I would suggest you run some tests to measure the effect. OPC UA is what Siemens supports for external access by an open protocol, and there is a node-opcua project that implements this.

[MehrabHalimi84]

Hello @aferro17 (and thanks @plcpeople for the clarification),

I am jumping in to provide a technical summary for you and future visitors regarding the “Optimized Access” debate.

As the owner correctly explained, this is not just a feature request but a fundamental protocol difference:

• NodeS7 (and Snap7) uses the legacy S7Comm (0x32) protocol, which relies on absolute addressing.
• Optimized Access uses the proprietary S7CommPlus (0x72) protocol, which supports symbolic addressing, anti-replay, and session IDs. Since Siemens has not documented this protocol, implementing it in open-source projects is extremely difficult and prone to breaking with every new Firmware update (e.g., TIA V17/V18 security changes).

Regarding the “CPU Cycle Time” Concern
Your colleagues are technically correct that “Optimized” blocks are native to the S7-1200/1500 architecture. However, the fear that using Non-Optimized blocks will significantly slow down the CPU is often overstated in practical applications.

For 99% of automation projects, the overhead of accessing a non-optimized DB is negligible (microsecond scale) and will not impact your machine’s operation unless you are running extremely tight motion control loops within the same cycle.

Recommended “Best Practice” with NodeS7
Since we cannot use Optimized Block Access here, the industry-standard workaround to ensure maximum performance and safety is:

1. Dedicated Interface DB: Do not expose your internal logic DBs directly. Create a specific DB (e.g., DB100 - SCADA_Interface) and uncheck “Optimized Block Access” only for this DB.
2. Data Copy: Inside your PLC program (at the end of OB1), simply copy the necessary values from your Optimized logic blocks to this Non-Optimized Interface DB.
3. Contiguous Data: Try to keep your variables in DB100 packed together (no large gaps). This allows nodeS7 to read everything in a single PDU request, which is far more efficient for the network and the CPU than requesting scattered addresses.

If your project requirements strictly forbid any Non-Optimized DBs, your only stable option is OPC UA (using node-opcua), as that is the official Siemens supported path for symbolic access. However, for a lightweight and fast Node.js integration, the current absolute addressing method in nodeS7 is perfectly fine and performant.

Hope this helps clear up the architectural constraints!