We’ve reached out to our Siemens partner; here’s the answer we got:
Generally speaking; the latest version of TIA Portal is backwards-compatible with older revisions of firmware. That means that you are not required to use the latest firmware with the latest software revision. Likewise, if you receive a CPU from the factory with the latest-released firmware pre-loaded, you can program it to run older firmware and it will run in what I call “backwards-compatible” mode – so the user does not need to “flash” firmware beforehand to “match” the TIA Portal version of software it was programmed with. An example is I have TIA V17 installed, however my original PLC project was installed & programmed with V15 and firmware 4.3. I can migrate my project to TIA V17(latest), keep the firmware as originally configured at V4.3 and download to the CPU with no additional changes/steps needed to be made (and no flashing the firmware to match V17). If the original CPU fails and the user receives a replacement from the factory with firmware 4.5 (even though the original program has it configured as 4.3), the CPU will run the older firmware as configured in the TIA project – the user does not need to flash the older firmware. Side note: This is also how in TIA V17 we can even program S7-300s manufactured in 2007 (3 years before TIA Portal released). Backwards compatibility is in our DNA and how we choose to support our customers long term, even through migration.
The only time where “flashing” the firmware is required is when the user wants to utilize the new features with the new software (e.g. cause-effect matrix (CEM) programming, CFC programming, TLS-based encryption of S7 comms, etc.) and they are using a CPU with older firmware loaded. If using an S7-1500 CPU, the firmware is shown on the front display of the CPU. If using S7-1200, ET200 or S7-300/400 CPUs, the firmware is shown in the online diagnostics information.
This is not a question, but I will comment that this is the advantage of having a TRUE “all-in-one” engineering software. The ability to easily connect devices, tags and objects reduces effort and errors that the engineer should not worry about. On the note about Profinet connections – Out of the box, the PLC does not have an IP address or subnet mask so it uses the MAC address to find an equivalent. If the PLC DOES have an IP address loaded and your PC is not in the same subnet/IP settings, TIA Portal will ask if you want it to automatically assign this – intelligence built-in!
In short, yes, and it is also freely configurable to be asynchronous, if required.
Explanation: For all Siemens S7-PLCs, I/O status is cyclically read/written [by the OS] from the IO module and buffered to an internal memory area of the CPU, called the process image. The user program accesses the Process image to read/write I/O.
The process image is updated cyclically at the beginning of the “Main (OB1)” cycle by default. If a signal state on an input module changes during program execution, the signal state in the process image is retained until the process image is updated again in the next cycle – then the new value is stored in the process image and used I the user program. This ensures that the I/O status is consistent throughout a single scan of the program. Although it is possible to asynchronously access the I/O status directly at the I/O card, access to the process image requires far less time than direct access to the signal modules since the process image is located in the internal memory of the CPU.
Note, the user can alternatively choose a different OB to cyclically update the process image or even assign I/O to certain process image partitions (PIP) that update synchronous with other OBs. This is a more advanced topic, but if you want to see where this is configured, you can see it in the properties of the IO module/CPU:
“online editing” is a term coined by Rockwell to describe the task of downloading program changes without stopping the processor. If the question he is asking is whether in Siemens one can make program changes without stopping the PLC – the answer is Yes and has been possible since the 90s. To further explain this process – If you edit blocks while they are being monitored, monitoring will be interrupted and you will be able to edit the block offline (the PLC is still executing the unmodified code while you are making your changes). If the block is not available offline in the project, you will first have to upload it from the device to the project. After editing the block, you will also have to compile and download it again – this process does not stop the PLC. After the changes have been downloaded, the online connection to the block is re-established and monitoring continues.
Not sure what is being asked here – can you clarify? Couple points from my side (unless I interpreted the question wrong)
I/O points are addressed according to IEC61131-3 standards for I/O addressing (e.g. I,Q, or M) and are independent of the module location. We do not address I/O using rack/slot-based syntax (location dependent). It is my understanding (I could be wrong) that “:<Slot #>::data[0]” syntax is not conformant to IEC 61131-3 standard for direct I/O addressing. As you point out in your video about “aliasing” in Studio 5000, the downfall of the AB syntax is not knowing what is wired to that point – you either have to comment the IO point or create an Alias.
With Siemens you create a descriptive tag name (similar to “alias”), which stays with the address throughout the program. If they re-wire the sensor to another channel, then they can update the address in the tag table and Voila! - The user program updates every call of that IO address to reflect the changes – no cross-referencing or find/replace functions needed.
i. Note: in AB you can assign multiple “aliases” to a single IO point, which could be a problem for troubleshooting/maintenance. In TIA Portal, it is impossible to assign multiple symbolic tag names to a single address point and it is impossible to use the same name twice – it will compile with an error and prevent you from downloading until it is fixed.
I am not sure what “module-defined datatypes” are, so if the above didn’t answer his question, do you mind explaining what “module-defined datatypes” are? What are they used for?
