Replies: 18 comments
-
It is possible to get the method name. The binary image in the PLC has a function/method table that has names of all the functions. Given the address of the method, one can walk the entire function pointer table, and look up the details of any function. You'd get its address without using Let's say we have:
Then, I have a proof of concept of |
Beta Was this translation helpful? Give feedback.
-
@Aliazzzz I like the idea. Would be an interesting option, as long as it in no way breaks the current way of doing it as I've seen users doing it in all kinds of ways, for example:
There's probably more ways of doing it :-) |
Beta Was this translation helpful? Give feedback.
-
It is possible to ask for multiple names on the call stack, and then you'd name the tests according to some filtering principle, most likely user-provided. I.e. the user could implement an optional function that, given a function name, returns a null or a test name. The call stack would be walked one frame at a time until a valid name is found. |
Beta Was this translation helpful? Give feedback.
-
Would you be so kind and post an example or so? |
Beta Was this translation helpful? Give feedback.
-
I think this addition of a yet even smaller burner plate code will be much appreciated. |
Beta Was this translation helpful? Give feedback.
-
@Aliazzzz I'm not sure I follow this. Could you provide an example? |
Beta Was this translation helpful? Give feedback.
-
My idea is the following; Every FB has an implicit initialization method we can use ( fb_INIT ). TEST( name_of_test_method_without_path_obtained_via__path_reflection ); Now we don't have to call TEST('foo') in the test-method itself anymore as this is automatically achieved on initialisation of the suite. |
Beta Was this translation helpful? Give feedback.
-
How do we iterate the test methods in FB_Init? And how do we get their names? |
Beta Was this translation helpful? Give feedback.
-
All good questions on which I don't have an anwser at this time. @KubaO had an idea, but has not provided an example on it yet. Have you got a suitable idea on how to tackle this? |
Beta Was this translation helpful? Give feedback.
-
Maybe a way to get the method names is to just read the TcPOU file and extract the method names using an xml reader? Not the nicest solution, but should work I think. Getting rid of TEST('..') is a good idea. Also because it would enable it to stop calling the methods once they are finished. Or is there currently already a way to stop calling a method? |
Beta Was this translation helpful? Give feedback.
-
It seems the keyword __POUNAME is in the future for TwinCAT. This would be useful if each test case was an FB [#107] |
Beta Was this translation helpful? Give feedback.
-
@I-Campbell sounds useful, but this is actualy already possible currently in TwinCAT. It is also used in the TcUnit library. You can see it in use in
More info: https://infosys.beckhoff.com/content/1033/tc3_plc_intro/2529681547.html?id=8053634368777910140 |
Beta Was this translation helpful? Give feedback.
-
instance-path (eg. PLC_PRG.myInstance) is slightly different to __POUNAME (eg. FB_TestSuite), but you are right, it could solve the same problem AND it is available today. |
Beta Was this translation helpful? Give feedback.
-
Yes getting direct access to the POU name would be much more convenient of course! |
Beta Was this translation helpful? Give feedback.
-
It's nice to see get these tips about new functionality in codesys, surely we will see it further down the road in TwinCAT and it might be useful for TcUnit as well. Only thing I'm afraid of is breaking compatibility to Tc 4020/4022/4024 (like compatibility was broken to 4016/4018 with the introduction of ANY). |
Beta Was this translation helpful? Give feedback.
-
@KubaO I've been looking for more information on accessing TwinCAT/CoDeSys call stack, symbol tables, and method definitions at runtime, but I can't find any documentation or even blog posts. Can you give me any pointers? I've been trying to figure out how to write something similar to EDIT: Looks like the __VARINFO() operator is what you use for runtime reflection in TwinCAT. So that's useful for parsing strings and using the results to set values in arbitrary IEC61131-3 data structures. I still have no idea how to read the TwinCAT/CoDeSys call stack at runtime though. Clearly it's possible, since TwinCAT XAE has a Call Stack debugging window... |
Beta Was this translation helpful? Give feedback.
-
@DavidHopkinsFbr Maybe something for the local Beckhoff support to help answering? |
Beta Was this translation helpful? Give feedback.
-
@DavidHopkinsFbr Did you manage to get any information from Beckhoff? |
Beta Was this translation helpful? Give feedback.
-
With the pragma {attribute 'call_after_init'} not necessary anymore, maybe it is also possible to implicitely call
TEST('SomeTestName')
somehow. That way the function name of test method can act as the test name.Current;
Suggestion
Is this feasable? If so, is it difficult to implement?
Beta Was this translation helpful? Give feedback.
All reactions