Project Discussion ^{mandeepahujaifm Project (Discussion)}
Forum for Project comments
Last updated: 2021-07-23

mandeepahujaifm SVN repository ^{mandeepahujaifm Project (SVN Repository)}
Last updated: 2021-07-23

wiki Discussion ^{thekrel wiki (Discussion)}
Forum for wiki comments
Last updated: 2021-07-23

blog Discussion ^{thekrel blog (Discussion)}
Forum for blog comments
Last updated: 2021-07-23

(no subject) ^{thekrel wiki (Thread)}
Last updated: 2021-07-23

Home ^{thekrel wiki (WikiPage)}
This is the personal project of thekrel. This project is created automatically during user registration as an easy place to store personal data that doesn't need its own project such as cloned repositories.
Last updated: 2021-07-23

API Reference ^{co♻e: A unittest framework for CODESYS apireference (WikiPage)}
Compatibility Though we strive for high interopatibility, the reality is that we cannot guarantee this library is compatible with all systems though it has been verified to work with most popular CODESYS Runtimes All CODESYS runtimes from v3.5.10.20 or later are supported. Original Equipment Manufacturer (OEM) CODESYS Runtimes listed (or higher) are supported Unlisted or older runtimes can work starting from 3.5.10.20 (your mileage may vary, so try at your own luck). In case of older runtimes, some library references/dependencies should be swapped for older ones. System Version Result Remark CODESYS Control Win SL (x64) 3.5.17.x verified CODESYS Control Win SL (x64) 3.5.16.x verified CODESYS Control Win SL (x64) 3.5.15.x verified CODESYS Control Win SL (x64) 3.5.14.x verified CODESYS Control Win SL (x64) 3.5.13.x verified CODESYS Control Win SL (x64) 3.5.12.x verified CODESYS Control Win SL (x64) 3.5.11.x verified CODESYS Control for Raspberry Pi SL 3.5.17.x verified CODESYS Control for Raspberry Pi SL 3.5.16.x verified CODESYS Control for Raspberry Pi SL 3.5.15.x verified CODESYS Control for Raspberry Pi SL 3.5.14.x verified CODESYS Control for Raspberry Pi SL 3.5.13.x verified CODESYS Control for Raspberry Pi SL 3.5.12.x verified CODESYS Control for Raspberry Pi SL 3.5.11.x verified CODESYS Control for BeagleBoneBlack SL 3.5.10.30 verified ABB Automation Builder v2.4.x verified ABB Automation Builder v2.3.x verified ABB Automation Builder v2.2.x verified ABB Automation Builder v2.1.x verified ABB Automation Builder v2.0.x verified Schneider SoMachine ? verified WAGO e!COCKPIT ? verified [#48] ---------- ---------- ---------- ---------- API References for version [v1.0.0.0] [v1.2.0.0]
Last updated: 2021-08-09

counit: Artifact 611193e235577ef6fec17ede ^{co♻e: A unittest framework for CODESYS builds (Generic Artifact)}
Last updated: 2021-08-09

counit: Artifact 6111c75435577ef6fec17f98 ^{co♻e: A unittest framework for CODESYS builds (Generic Artifact)}
Last updated: 2021-08-10

Post by hermsen on #51 Multiple timed tests, assertions and access violations ^{co♻e: A unittest framework for CODESYS tickets (Post)}
First off, thank you for your interest in coUnit. On first glance after reading your description it seems to me you are making your tests too "complex". But in no way I can really say anything about it really before seeing your code, so maybe you could post your testproject code for us to study. Some in depth hints and tips; "I've found a way around to call asserts only once in case a specific condition happens." To me this seems a good and valid way to assert something since PLC Function Blocks are mostly state dependent. Testing state dependent code is therfore itself also state depending. The clou is not to assert before you are sure that the code is in the 'to be asserted state'. Therefore running asserts continuously in such situations is not recommended. usually such a test is comprised of a CASE statement which guide the FB to the proper test state and then an assert to verify it. Be aware that all tests need to be written in such a way that your test can be run in any order all the time and are thus not inter dependable on each other. usually this means some stages are present in each test: initialise the testee, bring testee in test state, assert, de-initialise test. Hoping to see your code posted here and with kindest regards Haico
Last updated: 2021-08-10

Post by stmos on #51 Multiple timed tests, assertions and access violations ^{co♻e: A unittest framework for CODESYS tickets (Post)}
Hello Haico, thanks for the help and sorry for posting in the FAQs instead of in the tickets, I overlooked that and there was no way to edit it. I admit that I'm quite a newbie with Codesys even if I did already some projects, so maybe some issues are due to my misunderstandings, and indeed I'm not used to write test cases. I can't send you the original code, but I was able to reproduce the first issue in a project based on your examples, attached (Access violations). I've put multiple cases inside it - working and not working - just activate the ones you want to test at each run. I'm using Codesys 3.5.16.20 and simulating that on the soft PLC (Codesys Control Win x86). I will try to prepare also sample code for the other issue: usage of TEST/TEST_FINISHED/TEST_FINISHED_NAME and asserts (I hope in short time). Regarding my third issue (usage of one timed test case for each test suite), it seems to me that the answer is that it is possible to have multiple timed test cases for each test suite, given that the variables are not shared (I don't want the result of a test case to influence the results of the others, for example with shared units under tests). Thanks again for the help.
Last updated: 2021-08-10

Post by stmos on #51 Multiple timed tests, assertions and access violations ^{co♻e: A unittest framework for CODESYS tickets (Post)}
Hi Haico, maybe I've found the issue, please correct me if I'm wrong. See CODESYS Support/POU/GetCurTaskInfo. Suggested change: **Declaration:** FUNCTION_BLOCK GetCurTaskInfo VAR pCurTask : CmpIecTask.RTS_IEC_HANDLE; - pResult : POINTER TO CmpIecTask.RTS_IEC_HANDLE; + pResult : CmpIecTask.RTS_IEC_RESULT; pCurTaskInfo : POINTER TO CmpIecTask.Task_Info2; END_VAR VAR_OUTPUT CurTaskInfo : CmpIecTask.Task_Info2; END_VAR ----- **Code:** -pCurTask := CmpIecTask.IECTaskGetCurrent( pResult := pResult); +pCurTask := CmpIecTask.IECTaskGetCurrent( pResult := ADR(pResult)); pCurTaskInfo := CmpIecTask.IECTaskGetInfo3( hIecTask := pCurTask, pResult := pResult); CurTaskInfo := pCurTaskInfo^; IECTaskGetCurrent needs a pointer to a valid RTS_IEC_RESULT, not RTS_IEC_HANDLE, and the instance of the pointer was not initialized. I'll hope this helps.
Last updated: 2021-08-10

Post by hermsen on #51 Multiple timed tests, assertions and access violations ^{co♻e: A unittest framework for CODESYS tickets (Post)}
Ticket moved from /prj/cfunit/questions/18/
Last updated: 2021-08-10

Post by hermsen on #51 Multiple timed tests, assertions and access violations ^{co♻e: A unittest framework for CODESYS tickets (Post)}
status: accepted --> closed
Last updated: 2021-08-10

(no subject) ^{co♻e: A unittest framework for CODESYS tickets (Thread)}
Last updated: 2021-08-10

Ticket #51: Multiple timed tests, assertions and access violations ^{co♻e: A unittest framework for CODESYS tickets (Ticket)}
HI all, I've started looking at the framework for a project for which I wanted to use TDD techniques. Using the public version 1.1.0.0, after some tests I started having AccessViolations on assertions or static variables that do not get initialized with expected init values... What I've deduced and what it's not clear to me for timed tests (state-machine based): If I have too many assertions in a test this causes an access violation in the PLC (using Codesys Control Win x86). If I have a state in the test state machine with an assert that is called repeatedly on each cycle (for example because I want to check that a boolean does not get true for some cycles) at some point I get an AccessViolation exception and the PLC stops. I've found a way around to call asserts only once in case a specific condition happens. Is that true? For timed tests it seems from the examples that for a test suite we can have only one test case. If I use more than one test case I get strange behaviors, like tests failing for wrong reasons... I've put static variables on each test case with the unit under test also. Always in the examples I've found that the UUT and other support variables are instead instantiated in the FB of the test suite. Which one is the correct way to do it? * When I need to use TEST_FINISHED vs TEST_FINISHED_NAME? I get strange behaviors also here. If I name the test in only the first (init) state of the test case test machine I must then used TEST_FINISHED_NAME, but then failed assertions do not appear in the log... Thanks in advance for the help. Regards.2021-08-10 01:49:14.729000 Ticket #51: Multiple timed tests, assertions and access violations co♻e: A unittest framework for CODESYS counit tickets tickets False /lib/counit/tickets/51/ Ticket Multiple timed tests, assertions and access violations False 2 2021-07-15 22:11:54.927000 51 Multiple timed tests, assertions and access violations closed HI all, I've started looking at the framework for a project for which I wanted to use TDD techniques. Using the public version 1.1.0.0, after some tests I started having AccessViolations on assertions or static variables that do not get initialized with expected init values... What I've deduced and what it's not clear to me for timed tests (state-machine based): If I have too many assertions in a test this causes an access violation in the PLC (using Codesys Control Win x86). If I have a state in the test state machine with an assert that is called repeatedly on each cycle (for example because I want to check that a boolean does not get true for some cycles) at some point I get an AccessViolation exception and the PLC stops. I've found a way around to call asserts only once in case a specific condition happens. Is that true? For timed tests it seems from the examples that for a test suite we can have only one test case. If I use more than one test case I get strange behaviors, like tests failing for wrong reasons... I've put static variables on each test case with the unit under test also. Always in the examples I've found that the UUT and other support variables are instead instantiated in the FB of the test suite. Which one is the correct way to do it? * When I need to use TEST_FINISHED vs TEST_FINISHED_NAME? I get strange behaviors also here. If I name the test in only the first (init) state of the test case test machine I must then used TEST_FINISHED_NAME, but then failed assertions do not appear in the log... Thanks in advance for the help. Regards. False False 0 0 0 51 v1.2.0.0 stmos hermsen
Last updated: 2021-08-10

Post by hermsen on #53 Migrate project to /lib/counit ^{co♻e: A unittest framework for CODESYS tickets (Post)}
assigned_to: i-campbell --> h-hermsen
Last updated: 2021-08-10

Post by hermsen on #53 Migrate project to /lib/counit ^{co♻e: A unittest framework for CODESYS tickets (Post)}
Description has changed: Diff: --- old +++ new @@ -1,5 +1,5 @@ -migrate project: -[] create project -[] export/import webpages -[] import SVN -[] create git repo(s) +migrate project:* +* [x] create project +* [x] export/import webpages +* [x] import SVN +* [] create git repo(s)
Last updated: 2021-08-10

Post by hermsen on #51 Multiple timed tests, assertions and access violations ^{co♻e: A unittest framework for CODESYS tickets (Post)}
status: --> accepted assigned_to: h-hermsen Milestone: --> v1.2.0.0
Last updated: 2021-08-10

Post by hermsen on #51 Multiple timed tests, assertions and access violations ^{co♻e: A unittest framework for CODESYS tickets (Post)}
I'll check this when releasing v1.2.0.0
Last updated: 2021-08-10

Post by hermsen on #53 Migrate project to /lib/counit ^{co♻e: A unittest framework for CODESYS tickets (Post)}
Description has changed: Diff: --- old +++ new @@ -1,4 +1,5 @@ -migrate project:* +migrate project + * [x] create project * [x] export/import webpages * [x] import SVN
Last updated: 2021-08-10

Ticket #39: Assert_Equals() with STRING(1024) Causes PLC Crash ^{co♻e: A unittest framework for CODESYS tickets (Ticket)}
Test version: v1.0.9.9 RC2 Problem: Using Assert_Equals() with STRING(1024) Causes PLC to crash. The problem is, the AssertEquals uses pointers to write to memory, and will happily copy an entire 1024 character string over the top of a 255 character string See screenshot for the line which causes the memory overwrite Steps to repeat: With the Verifier_MultiCycle_Examplev1.0.9.9.project, change the following POU: Test/FB_AnyPrimitiveTypes.Test_ANY_STRING_Equals to METHOD PRIVATE Test_ANY_STRING_Equals VAR a : STRING(1024) := 'WCPRZC2VAB 01SQ7HD707 68UUBLAN0H AI2HPVN8YO NQ5T9PIV9M DAQYA96Y8T'; b : STRING(1024) := 'WCPRZC2VAB 01SQ7HD707 68UUBLAN0H AI2HPVN8YO NQ5T9PIV9M DAQYA96Y8T'; END_VAR TEST('Test_ANY_STRING_Equals'); AssertEquals(Expected := a, Actual := b, Message := 'Values differ'); TEST_FINISHED(); Download to the PLC and run ==> IS: PLC stops unexpectedly, no logs written, PLC won't start again ==> SHOULD: Either allow to compare any length strings, OR don't allow them and print an error message rather than crashing the PLC Note: To recover, delete the application from the PLC, for example at C:\ProgramData\CODESYS\CODESYSControlWinV3x64\AAAA\PlcLogic\Application\2021-08-10 01:56:43.897000 Ticket #39: Assert_Equals() with STRING(1024) Causes PLC Crash co♻e: A unittest framework for CODESYS counit tickets tickets False /lib/counit/tickets/39/ Ticket Assert_Equals() with STRING(1024) Causes PLC Crash False 1 2020-05-01 21:58:40.921000 39 Assert_Equals() with STRING(1024) Causes PLC Crash open Test version: v1.0.9.9 RC2 Problem: Using Assert_Equals() with STRING(1024) Causes PLC to crash. The problem is, the AssertEquals uses pointers to write to memory, and will happily copy an entire 1024 character string over the top of a 255 character string See screenshot for the line which causes the memory overwrite Steps to repeat: With the Verifier_MultiCycle_Examplev1.0.9.9.project, change the following POU: Test/FB_AnyPrimitiveTypes.Test_ANY_STRING_Equals to METHOD PRIVATE Test_ANY_STRING_Equals VAR a : STRING(1024) := 'WCPRZC2VAB 01SQ7HD707 68UUBLAN0H AI2HPVN8YO NQ5T9PIV9M DAQYA96Y8T'; b : STRING(1024) := 'WCPRZC2VAB 01SQ7HD707 68UUBLAN0H AI2HPVN8YO NQ5T9PIV9M DAQYA96Y8T'; END_VAR TEST('Test_ANY_STRING_Equals'); AssertEquals(Expected := a, Actual := b, Message := 'Values differ'); TEST_FINISHED(); Download to the PLC and run ==> IS: PLC stops unexpectedly, no logs written, PLC won't start again ==> SHOULD: Either allow to compare any length strings, OR don't allow them and print an error message rather than crashing the PLC Note: To recover, delete the application from the PLC, for example at C:\ProgramData\CODESYS\CODESYSControlWinV3x64\AAAA\PlcLogic\Application\ False False 1 0 1 39 [FUTURE FEATURE] i-campbell i-campbell
Last updated: 2021-08-10

Post by aliazzz on #39 Assert_Equals() with STRING(1024) Causes PLC Crash ^{co♻e: A unittest framework for CODESYS tickets (Post)}
Hi, Sadly at this moment, string(1024) is not supported, so technically it is not a Bug, but a feature ;-) Currently a string with maximum length of 255 ( type T_MaxString) is supported only. I will put this idea on hold for the future as it might be a good idea to test larger strings. This idea has to wait for the next release beyond V1.1.0.0. Hope this helps Aliazzz
Last updated: 2021-08-10

Post by aliazzz on #39 Assert_Equals() with STRING(1024) Causes PLC Crash ^{co♻e: A unittest framework for CODESYS tickets (Post)}
Milestone: v1.1.0.0 --> [FUTURE]
Last updated: 2021-08-10

Post by aliazzz on #39 Assert_Equals() with STRING(1024) Causes PLC Crash ^{co♻e: A unittest framework for CODESYS tickets (Post)}
status: unread --> pending
Last updated: 2021-08-10

Sort by relevance or date