I find it peculiar. I am intrigued by the potential outcome of placing the two movement instructions consecutively rather than separately.
Lare asked about the program execution order in Codesys, wondering if it follows a top-to-bottom then right sequence or a left-to-right then bottom sequence. The statement "The elements are sorted from top to bottom and left to right" only applies to CFC, not LD. For LD in Codesys, the execution order is uniquely determined in text-based and network-based editors. However, the current behavior in Codesys LD does not align with this, leading to confusion and a need for clarification.
User dwoodlock raised a valid point about the sequence of instructions in a program. By placing move instructions in series instead of branching them, the execution flow follows a left-to-right pattern. This simple test case highlights a common issue in programming logic.
In a more complex scenario, the order of execution can impact the outcome significantly. For instance, in a case where an XIC/NO contact is involved, running the upper branch first may lead to unexpected results. This discrepancy can be rectified by rearranging the branches or by combining them to ensure the desired logic sequence.
Implementing workarounds, such as swapping branch order or merging logic paths, can resolve timing conflicts and prevent incorrect behavior in the program execution. These adjustments are crucial in maintaining the accuracy and efficiency of the code.
I have not encountered this issue previously, but I will conduct some test cases today to troubleshoot. May I ask which version are you currently using?
CODESYS Group's ladder editor operates by executing branches in a sequential top-down manner. I appreciate the clarity in Control Expert's ladder editor regarding the order of function execution. However, there is a drawback as function blocks are not labeled in the same manner. This can make it challenging to access values from certain elements, such as timers, requiring additional testing.
dwoodlock mentioned encountering a new issue and is planning to conduct test cases to investigate further. They are using CODESYS V3.5 SP19 Patch 6, downloaded recently, on a Windows 10 "Enterprise Evaluation" Build 19041.vb_release.191206-1406 virtual machine in VirtualBox. The host operating system is Linux Mint, a variant of Ubuntu. Thank you!
drbitboy recently mentioned downloading the CODESYS V3.5 SP19 Patch 6 a few days ago on a Windows 10 "Enterprise Evaluation" Build 19041.vb_release.191206-1406 guest VM in VirtualBox. The host OS is Linux Mint, a variant of Ubuntu. @ Linux Mint has piqued my interest, as I have been considering switching over.
modiconguy from the CODESYS Group pointed out on content.helpme-codesys.com that the program executes branches in succession from top to bottom. Thank you for bringing this to our attention! It is discouraging to discover that there may be an error or bug in CODESYS. I was looking forward to an explanation about the execution order of Closed versus Unclosed branches.
Discover this feature as well. How does it impact performance? "CODESYS seamlessly integrates the top-level output with the neighboring function blocks' highest input." Explore more at: https://help.codesys.com/api-content/2/codesys/3.5.12.0/en/_cds_pragma_attribute_dataflow/
Lare noted: I also came across this information. Could it have an impact?"CODESYS maximizes connectivity between the output and input signals of adjacent function blocks." This feature can be found at https://help.codesys.com/api-content/2/codesys/3.5.12.0/en/_cds_pragma_attribute_dataflow/. While this is intriguing, the discussion appears to be more relevant to user-defined function blocks in FBD. The main focus of this thread, however, is determining the execution order of branches following a split in a branch/rung in LD programming.
Why do user-defined functions in PLC programming differ from built-in blocks like FC, FB, and other blocks? I'm uncertain about this.
Lare questioned the difference between user-defined function blocks (FBs) and built-in blocks like function code (FC) and function blocks (FB). It seems unlikely that users can modify built-in blocks with pragmas like {attribute 'dataflow'}. Click to learn more about this topic.
Drbitboy noted an issue with the Codesys LD program, questioning why Rungs 2 and 3 did not yield functionally identical results. Any insights on this discrepancy? Has this topic been discussed elsewhere? Click to expand...After a significant delay, I finally conducted a test today using RPI Zero W and Codesys for RPI SL, achieving the expected outcome.
I formatted it in the same way as Dr. Bitboy's, leading to identical outcomes on both networks.
dwoodlock mentioned that the setup has been adjusted to mirror Dr.Bitboy's, resulting in the same outcome across both networks. Is this behavior determined by the manufacturer or hardware used? This poses an interesting question.
Are you utilizing simulation software or hardware components? The outcome should be consistent, but I'm just interested to know.
dwoodlock inquired about the method being used: simulation or hardware? The outcome should be the same, but I am just curious. Click to expand for more information on simulation techniques.
I also modified my settings to simulation mode for scientific purposes, only to encounter the same outcome once more.
In response to dwoodlock, I also switched mine to simulation mode for scientific purposes, but encountered the same outcome. What operating system are you using? I need to revisit and double-check mine.
Download the latest version of Windows 11 64-bit operating system.
I'm interested to know if you used Ladder Diagram or Ladder Logic Diagram for this Program Organization Unit, Brian. I haven't had the chance to explore the distinctions between the two. It appears that there are variations in the POU being used by dwoodlock and Brian.
- 18-08-2024
- AlfredoQuintero
I have noticed that Alfredo and dwoodlock have achieved similar results in terms of layout, with both appearing to use LD (Logic Designer) in LD2 which includes EN/ENO input/output when a block is added. Despite this similarity, I am struggling to position my blocks as demonstrated by drbitboy in his example.
After conducting experiments, I found that using both the standard ladder and ladder diagram yielded the same result. Initially, I utilized the standard ladder, but later switched to the ladder diagram. However, I encountered layout issues with the ladder diagram. This problem is not new, as previous versions of Codesys also had issues with move instructions not automatically adjusting to the correct position within the ring. I noticed that@drbitboypreferred using ladder diagrams. Personally, I find that ladder diagrams in TIA look similar to standard ladders and occupy more space, especially on a laptop screen. I discovered a workaround by right-clicking on the program in my project tree and converting it to a "new ladder" format.
In Mitsubishi, there is a difference between using FBD/LAD and LAD only in terms of code. The purpose is to ensure compatibility with Ladder logic, making it backward compatible with previous IDE's and PLC models. For example, in FBD, linking functions with EN0 to create two functions in series may appear fine in FBD, but when the raw code is transferred to the ladder editor, it appears differently. The older convention requires that after an output or move instruction, it must be connected to the "common" rail. Some IDE's do not allow output coils or certain functions to be in series, only in parallel. The compiler creates a temporary variable to overcome this limitation. While the order of operation is correct in Mitsubishi, there may be a bug in the compiler causing the order to be swapped. This may result in unexpected outcomes, such as the use of temporary variables. The EN0 of the function drives a move instruction, similar to utilizing the result on M0. However, there may be errors in the compilation process due to the different formats used.
I am experiencing different outcomes than the original post while working on Windows. Brian, I am puzzled by how your compiler allows assigning ton0.Q to a coil. Since ton0.Q is an output of a timer on FB, I encountered an error when attempting to compile my program following your instructions.
- 18-08-2024
- AlfredoQuintero
AlfredoQuintero commented: I am puzzled by how your compiler allows assigning ton0.Q to a coil. In my programming experience with PLCs, it is common practice to assign memory bits to coils. Despite this, when attempting to compile my program following your instructions, I encountered an error.
It should be noted that in my program, ton0.Q is not directly connected to a coil. Instead, I have created a BOOL variable named ton0Q to represent the timer's expired state. This approach ensures a more organized and error-free program structure, especially when dealing with timer functions in Codesys or Siemens PLC programming. These timer functions often assess the internal state of timer objects asynchronously, requiring careful consideration in programming.
When coding a program, I define a BOOL variable named "ton0Q" to handle the timer-expired condition, in order to account for potential inconsistencies in Codesys and Siemens timer functions. These functions may evaluate the timer object's internal state asynchronously with the TON instruction. Unfortunately, I wasn't able to replicate the results you mentioned.
- 18-08-2024
- AlfredoQuintero
AlfredoQuintero mentioned that he was unable to replicate the results. Thank you for the information and bringing this to my attention.
The ability to replicate can be achieved with Ladder (LD2) but not with Ladder Logic Diagram (LD). While I do not have the exact wording from IEC-61131-3 regarding ladder execution order, it appears to contradict CODESYS's guidance stating that an Abranch splits the processing line into multiple branches that are executed sequentially from top to bottom. This discrepancy may indicate a potential bug in the new ladder system, which can be reported to CODESYS Store North America under 'Bug Report' in the 'My Question' section. It is common to encounter bugs in version 1.0.0.0 of any software. If needed, you can revert to the old ladder system by accessing the installer, selecting 'change,' then 'browse' and 'search' for LD.
I was taken aback when I first encountered the updated Ladder in my version of the software. Unlike what I am accustomed to, it now appears as "LD2". This change seems to be intended to differentiate it from previous versions. However, I must admit that I am finding the new LD2 interface challenging to navigate. I can't help but wonder about the reasons behind its introduction in CODESYS. Perhaps I simply need more time to adjust to it.
- 18-08-2024
- AlfredoQuintero
I am not a fan of this program as it requires more time to code and involves too many clicks within a network. In comparison to TIAs ladder editor, I find it to be somewhat lacking in quality.