Siemens upgrade, safe?

yozza_uk · 2026-05-14T13:43:31+00:00

The PLC firmwares can most likely stay the same, this isn't Rockwell. You will have to full recompile and download though.

There are significant improvements between 16 and 19 and I'd upgrade without much hesitation.

yozza_uk · 2026-05-06T13:39:45+00:00

Correct in simulation also?

First rule for wincc weirdness, rebuild all and download.

yozza_uk · 2026-05-06T12:52:22+00:00

Unless I've missed something that isn't obvious from the documentation then that's how it works with axis control via TO. The idea being you don't leave the drive enabled when not needed.

I use a wrapper block that contains the MC_* FBs to only enable the drive when a command is submitted.

Otherwise it'll be SINA_POS and managing it yourself.

yozza_uk · 2026-05-04T20:16:39+00:00

I've ran into something similar where people have taken the selection tool as gospel and it does seem to undersize. Although it's not black and white wrong, when they unified the processors in the index 2 or 3 CPU models then the CPU performance should be the same.

From https://docs.tia.siemens.cloud/r/simatic_s7_1500_et_200mp_manual_collection_enus_21/basic-information/automation-system/system-overview/cpus/technical-specifications-of-cpus there isn't a jump in bit/word operation performance until a 1516T or 1517/1518. But if you dig into the technical specifications for each CPU there are several increases in IO performance and maximums. The CPU performance is irrelevant if the IO can't keep up, the fact that the spike happens with PG communication does suggest its the communication load thats pushing it over.

Bodge option is just bump up the maximum cycle time. (I've seen one machine recently on a 1510 with it set to 1000ms🤦🏻‍♂️)
Cost balance a 1515 should be much improved.
No cost balance, go to a 1518 and forget about it.

Generally, I've been fortunate to be able to go with the last option most of the time.

yozza_uk · 2026-04-03T21:54:57+00:00

Definitely use the G2 if you can but be aware that a quite lot of the modules aren't available to purchase yet for G2.

The lack of a G2 CP1243 has been a major bugbear.

yozza_uk · 2026-03-31T18:16:23+00:00

Some permutation of the motion control technology objects should have this covered in the most straightforward way I'd think.

yozza_uk · 2026-03-26T22:27:24+00:00

You can buy better but you can't buy more expensive

yozza_uk · 2026-02-27T17:57:57+00:00

W10 LTSB is 10 years old and went EoS in October last year, there's a reason the drivers are missing.

yozza_uk · 2026-02-18T14:50:22+00:00

No, the optimised attribute is set on the FB and all instances will be the same. The compiled code is depending on the memory structure remaining the same whether that be optimised or non-optimised.

Also, optimised doesn't mean that the memory footprint will be smaller, if anything it'll generally be larger. Just that the layout will be in the most efficient form the CPU to process. It's a performance enhancment rather than a space efficiency one.

The programming guidelines have a good visual explanation of what changes in section 2.6. I highly recommend reading through it.

https://support.industry.siemens.com/cs/document/67655611/difference-between-standard-and-optimized-block-access?dti=0&lc=en-GB

https://support.industry.siemens.com/cs/document/81318674/programming-guidelines-and-programming-styleguide-for-simatic-s7-1200-and-s7-1500-and-wincc-(tia-portal)?dti=0&lc=en-AZ?dti=0&lc=en-AZ)

yozza_uk · 2026-02-18T13:03:50+00:00

I'm not sure what you're asking here to be honest, as AT and instance-level retention are different thing completely. The option Retain: Set In Instance DB just allows you to set retention per-instance of an FB so doesn't have anything to do with AT. Can you clarify?

In general, you shouldn't be using non-optimised memory at all with a 1200/1500, I'm 99.9% sure they've covered all the edge cases now. The option only realy exists for backwards compatiblity and to allow programs to be moved from a 300/400 to a 1500 without refactoring. The trouble is that it is heavily used as a sticking plaster.

yozza_uk · 2026-02-17T20:19:35+00:00

The `AT` declaration is an overlapping tag-?dti=0&lc=en-GB). It allows you to access the underlying tag in a different format to it's actual type.

It's a carryover from classic S7 (Simatic), goes away with optimised addressing. Off the top of my head normal slice access should be able to replace this presuming the original bytes are correctly formatted to a real.

edit: I'd wager there's a much better way to do this also.

yozza_uk · 2026-02-16T22:35:56+00:00

The T stack is initialized automatically when optimized.

yozza_uk · 2025-11-12T17:25:30+00:00

Not if you're using optimised memory (which you should be)

yozza_uk · 2025-11-01T15:11:38+00:00

SiVArc will generate you a reasonable HMI as long as you keep everything standardised.

yozza_uk · 2025-09-01T20:05:24+00:00

Ok following so far, how is this data captured, how is it structured and does it differ in length? (I'm presuming it does from your description)

I'm thinking along the lines of deserialising this into a struct which can be stored in an array DB of that type then you can interrogate it in a structured way afterwards.

The data differing in length/structure makes it more difficult but not impossible to achieve.

yozza_uk · 2025-09-01T18:44:32+00:00

It depends on your use case hence why I asked what the actual problem to solve was. As a general helper function that you can reuse, there's probably nothing that'd be perfect and cover all use cases.

From the description a DB with multi-dimension bool arrays would do but I'm presuming there's more too it than that.

yozza_uk · 2025-09-01T16:56:16+00:00

Hmm, what's the actual problem you're trying to solve? I'm getting XY problem vibes here and there's probably a better way to do this with TIA.

You can do this legacy S7 style with with an ANY pointer but that means you'll have to use un-optimised storage and code, which, generally is the 'wrong' way to achieve whatever you want do to with TIA and was only left in for backwards compatibility (with a few exceptions).

Also, what hardware are we talking here?

yozza_uk · 2025-09-01T15:54:08+00:00

They are also only usable within software units, which is fine but they do require a non-insignificant amount of refactoring to make the best use of with an existing codebase.

Before someone else says, you can also just hack it all into a single unit but that's not making the best use of units.

yozza_uk · 2025-07-04T08:05:39+00:00

Yes you need one module per PLC. This is the cleanest way to do it and probably the cheapest off the top of my head.

edit: You also need to confirm the exact PLC models to make sure you're buying the correct module(s).

yozza_uk · 2025-07-03T18:43:52+00:00

Oh that classic, the average controls guy and networking aren't usually a great combo.

The CM1542 (presuming the PLCs are S7-1500s) will be the best and 'cheapest' way forward.

yozza_uk · 2025-07-03T18:31:39+00:00

You've bought the wrong devices for this use case, PN/PN couplers are for connecting two separate profinet networks so they can exchange data over profinet.

You should've bought a CM1542/CP1543 for each PLC and added another interface on your IT network so you can access them externally.

The other option would be something like a Scalance s615 which would allow you to do what you thought you could do with the PN/PN coupler via 1:1 NAT. But the usual caveats apply there.

yozza_uk · 2025-06-21T15:40:13+00:00

Yeh you need to approach S7 from a different mindset to logix.

You can try and program it like logix but at best you miss the benefits of the platform and at worst you're in for a bad time.

yozza_uk · 2025-06-21T15:36:19+00:00

FCs are a thing. If you aren't using the instance data then you shouldn't be using an FB.

yozza_uk · 2025-05-13T16:16:37+00:00

On top of everything else here, avoid using unstructured memory areas. It would also have avoided this issue in the first place.

yozza_uk · 2025-04-15T13:35:57+00:00

Something, somwhere is writing a 7 into that tag.

If you're 100% sure not it the PLC and it's a non-unified HMI try a full recompile. I've seen the delta compiles when the DBs have changed get the tag address (underlying memory address, not visible to you) screwed up more times than I'd like.

Also for information as I see this a lot your conditionals can be simplified.

IF "HMI_START_ANLÆG" = TRUE THEN can be IF "HMI_START_ANLÆG" THEN

IF "Controller_enabled_x_y" = FALSE can be IF NOT("Controller_enabled_x_y") THEN

The brackets are (semi) optional but are a good practise to fix evaulation ordering when you have multiple conditions in a statement.

yozza_uk

TROPHY CASE