If I0.0 or I2.6 are not activated, M0.3 will reset during the same scan cycle. Therefore, nothing will occur.
- 18-02-2025
- CommissioningMan
**User sigmadelta indicated:** The line marked with "22 S7" is consistently active, ensuring that M 0.3 (indicated by the line with R M 0.3) is always reset. To elaborate, this appears to be a normally closed (N.C.) contact, which means M0.3 will only reset when the button is activated.
From my perspective, this code represents the initialization phase of the control system. There is a timing delay implemented; however, it currently malfunctions due to incorrect programming. When the start button is pressed and there’s no emergency stop (e-stop) engaged, the power-on bit (M0.3) is triggered, subsequently activating the contactor 33_K2. Additionally, a lamp is illuminated if the power-on bit is engaged or the lamp-test button is pressed.
In my opinion, there seems to be an overemphasis on Structured Text Language (STL) among some developers. They may believe that proficiency in STL demonstrates superior intelligence, yet it seems they may overlook simple errors.
Consider this code example:
```
Code:
AN M 0.2
SD T 1
L S5T#5S
S M 0.2
```
It should be modified to:
```
Code:
AN M 0.2
L S5T#5S
SD T 1
A T 1
S M 0.2
```
There’s absolutely no justification for not expressing this logic using Ladder Diagram (LAD) or Function Block Diagram (FBD). These formats are considerably easier to interpret, and the built-in editor functionalities help users avoid the most basic programming mistakes.
Understood! The emergency stop (E-stop) pushbutton on the auxiliary console was not disengaged. Thank you for bringing this to my attention. The PLC programming, along with the Structured Text Language (STL) logic, was developed years ago by our German division. Until now, I haven’t had the opportunity to delve deeply into STL. It’s true what they say—you’re never too old to learn something new!
JesperMP commented that there seems to be a fascination among some programmers with Structured Text Language (STL). The perception is that if someone can code in STL, they must possess exceptional intelligence. However, it appears that this intelligence doesn’t always extend to identifying straightforward coding errors. There’s no compelling reason why one couldn’t develop the same functionality using Ladder Logic (LAD) or Function Block Diagram (FBD) instead—these alternatives are typically easier to read, and their integrated editors provide helpful features to prevent common mistakes.
As an American primarily working with Siemens technology, it’s quite surprising to hear sentiments like this expressed by someone who aligns with a European identity. Jesper, you continue to be an inspiration! It's worth noting that the previous enthusiasm for STL seems to have shifted towards Structured Control Language (SCL), which strikes a balance between STL and LAD, offering improved usability for beginners in programming.
I dislike when developers choose programming languages for coding that could be significantly enhanced by utilizing a more suitable language. However, with Siemens and their older S7-300/400 series, many limitations were present when using Ladder Logic (LAD) or Function Block Diagram (FBD). Fortunately, in their efforts to capture the U.S. market, Siemens has made improvements in their newer systems, addressing these shortcomings.
mk42 shared insights on the evolving preferences in programming syntax, noting that the rising popularity of Structured Control Language (SCL) is gradually overshadowing traditional Structured Text Language (STL) among users, particularly beginners. SCL strikes a balance in usability between STL and Ladder Logic (LAD), making it more accessible for those just starting out.
In scenarios where complex logic might seem cumbersome in LAD, SCL offers a clearer and more concise way to express the same ideas. Additionally, SCL allows for extensive commenting, enhancing code readability and maintainability. While it’s often feasible to implement logic in SCL, many find that using LAD remains the more effective choice in most instances.
Interestingly, recent updates to TIA Portal now permit the integration of both SCL and LAD within a single project, a feature that aligns with feedback I once suggested for STEP7. This advancement means that developers no longer have to strictly choose one programming language over the other, thereby fostering greater flexibility and efficiency in their coding practices.
JesperMP stated: "Horses for courses." When it comes to programming, concepts that might be overly complex in Ladder Logic (LAD) can often be articulated more clearly and effectively in Structured Control Language (SCL). SCL allows for extensive commenting, which enhances code readability and understanding. Conversely, while logic can typically be implemented in SCL, many developers find that using LAD is preferable for certain tasks.
Interestingly, in TIA Portal, it is now possible to integrate both SCL and LAD within the same project! I had previously expressed this as a wish for STEP7, but I didn't expect it to come to fruition. This development means that users no longer need to choose one language exclusively over the other.
To elaborate, within the TIA Portal environment and using 1500 series processors, you can have different networks such as Network 1 utilizing LAD, Network 2 in STL (Structured Text), and Network 3 in SCL. Even with 1200 series processors, a similar approach can be adopted, although STL cannot be used in that case.
You can utilize a single function across multiple programming languages; however, unlike SIMATIC Step 7, there isn’t a straightforward "conversion" process between these languages. This can be somewhat frustrating, especially when you need to simplify concepts for someone who specializes in ladder logic programming.
User cardosocea commented: It’s possible to utilize a single function across various programming languages; however, there isn't a direct "conversion" feature akin to that found in SIMATIC Step7. This can be a challenge, especially when you need to simplify complex concepts for someone who specializes in ladder logic. Upon further reflection, I believe there is some conversion capability between LAD and FB, but the same cannot be said for other languages. On a positive note, I'm thrilled to witness a growing acceptance of Structured Control Language (SCL) among the newer cohort of controls engineers. More professionals are entering the field with a programming background acquired through their education.
You can convert from LAD to STL, although I haven't tried converting LAD to SCL. Additionally, it is possible to convert from STL back to LAD, but this process tends to be most effective with straightforward routines.
Rob mentioned that there is a conversion process from Ladder Logic (LAD) to Structured Text Language (STL), although he hasn't tried the reverse conversion from LAD to Structured Control Language (SCL). It is possible to convert STL back to LAD, but this tends to work effectively only with straightforward routines. The success of this conversion also relies on whether the STL is written in a way that the converter can comprehend. Personally, I have yet to achieve this, but I once had a colleague who could write STL code that was accurately convertible to other programming languages in Step7. I need to check if I can locate that conversion capability within the TIA Portal.
mk42 commented on the increasing acceptance of SCL among the new generation of control engineers, noting that more individuals with programming backgrounds are entering the field during their education. I share this sentiment, and I believe that some brands may face challenges due to their limited offerings of programming languages as optional features or, in some cases, entirely absent. While Ladder Logic excels at representing Boolean logic, SCL provides a close second option—provided the programmer formats the code effectively. Nevertheless, SCL is not always the most suitable language for handling the increasingly complex tasks prevalent in modern control systems.
Conversion between LAD (Ladder Diagram) and STL (Structured Text) can only be performed on a 300/400 series controller within the TIA Portal project—it's not possible with the S7-1500, at least not in TIA versions 13 and 14. I haven’t explored the TIA 15 version yet. If your STL code includes specific instructions, such as memory swapping or double assignments within the same section, conversion will also be impossible. However, straightforward commands like `LD M0.0` or `A I0.0 = Q0.0` will convert without issues. I have completed two projects featuring precise motion control entirely in ladder logic, but I found myself creating multiple SCL (Structured Control Language) function blocks to manage the complexity. It was quite a challenge! Converting function blocks written in STL or LAD to a different platform? Good luck with that!
- 20-02-2025
- CommissioningMan
CommissioningMan stated: "A straightforward instruction like LD M0.0A I0.0= Q0.0 is perfectly acceptable." However, are you certain about that? What specific role does the LD play in this context? CommissioningMan further remarked: "Good luck attempting to translate a function block created in STL or LAD to a different platform." It seems to me that transferring code between various platforms isn't a top priority for any manufacturer.
According to user cardosocea, the importance of porting code between different platforms is not a priority for most manufacturers. Although there have been some initiatives aimed at achieving cross-platform compatibility, none have gained widespread acceptance in the industry. The IEC 61131-3 standard was introduced to unify programming languages for PLCs, and PLCOpen sought to standardize various instructions. However, many manufacturers merely pay lip service to these standards, treating them more as suggestions rather than regulations. Typically, vendors adopt the elements they find beneficial while augmenting them with their proprietary features. As a result, few PLC manufacturers limit themselves to the agreed-upon concepts from the committees, and many show resistance to adopting new ideas.
A more recent development, AutomationML, aims to integrate PLC programming, hardware design, and more into a cohesive XML model for sharing purposes. While Siemens and Eplan tout its use as an interfacing solution, it remains unclear whether other companies have adopted it, or how compatible their implementations are with one another.
This discourse sheds light on the ongoing challenges of standardization in the automation industry, emphasizing the need for greater collaboration and compatibility among leading PLC vendors.
Cardosocea asked: Are you certain? What is the role of LD in this scenario? Click to expand... It was merely a typographical error. Initially, I used an "L" to denote load value, but then I modified it to a small comparison without updating the instructions; as a result, the typo persisted. The takeaway here is that a straightforward function can be easily converted. Try creating a new project with an S7-300 controller and see for yourself.
Cardosocea continued: I believe that transitioning code between different platforms isn't a top priority for manufacturers. Click to expand... It's not about the manufacturers; it's about the end users. We operate with 4 to 5 different platforms, and when you have numerous standard function blocks that were created and tested long ago, you want to avoid using ladder logic because it doesn't allow for copy-pasting to other platforms. In contrast, with Structured Text, minimal editing is required after copying, making it much more efficient.
- 20-02-2025
- CommissioningMan