OS independent xUnit file path

[philippleidig]

In order to execute the unit tests on different target plattforms with different operating systems, you need to change the GVL_Param_TcUnit.xUnitFilePath parameter. The idea is to use generic constants, which are then replaced in the file path depending on the operating system to change the target plattform without adjusting the PLC project itself. You would also not have to pay attention to the separators of the paths of the different operating systems ( \ and / )

The following constants can be read from the registry by using Tc2_Utilities.FB_RegQueryValue to replace the constants:

• TwinCAT boot directory ( e.g. C:\TwinCAT\3.1\Boot\ ) %TCBOOTDIR%tcunit_testresults.xml

• TwinCAT install directory ( e.g. C:\TwinCAT\3.1\ ) %TCINSTALLDIR%tcunit_testresults.xml

see Tc2_Utilities.FB_RegQueryValue for more information.

All TwinCAT supported Target Plattforms are available

• WES7/Win7/Win10: TC RT x86/x64,
• WEC6/7: TC RT x86,
• WEC7: TC CE7 ARMV7,
• TC/BSD: TC RT x64,
• TC OS ARMT2

[philippleidig]

233

[iadonkey]

In the end the xml file is needed on the computer that activated the “Test PLC” on the target. What do you think about writing the xml file directly to this computer. It would require to refactor the code that writes the file to use FB_Open and FB_FileWrite and use the sNetId Parameter.

Of course it is also possible to get the file over ADS, but I think this would be a more direct approach

[philippleidig]

That would definitely be a much cleaner solution. Depending on how TcUnit is used, however, it could possibly come to the same point as with the absolute file path.

If the PLC project with unit tests is executed locally on the engineering laptop and subsequently in a CI pipeline, the AmsNetID of the two TwinCAT XAE systems will probably differ. The parameter in the TcUnit library would then have to be adapted explicitly for the CI pipeline.

It may also be possible to intercept the events from ADS port 100 and evaluate the test results. So it may not be necessary to publish the test results in a xUnit file. See the sample for detailed information.

What do you think?

[iadonkey]

The parameter in the TcUnit library would then have to be adapted explicitly for the CI pipeline.

That is a good point. Depending on the CI setup this might be a problem for some since you can’t change the parameter list after compiling. (at least I am not aware of a simple way to do it)

It may also be possible to intercept the events from ADS port 100 and evaluate the test results.

Seems tempting to this or use the event logger instead. My personal preference though is to have a result file that is directly generated by the PLC executing the tests.

So considering this, I take it back and think your approach is probably the best way. Thanks for implementing it!

[philippleidig]

@iadonkey , @sagatowski

Found a even better solution. TwinCAT supports a bunch of pre defined OS independent environment variables.

see beckhoff infosys or plc deployment for detailed information

%TC_BOOTPRJPATH% -> e.g. C:\TwinCAT\3.1\Boot\ %TC_INSTALLPATH% -> e.g. C:\TwinCAT\3.1\

Works fine with both libraries SysFile.SysFileOpen and Tc2_System.FB_FileOpen

Perhaps the default value in the library parameters could be adjusted accordingly? 🙂

[iadonkey]

Didn’t know that the FBs resolve those, seems I only have to change the values parameter in the parameter list, thanks!

Guess it is %…% also on Unix-based OSs

[sagatowski]

This is great, thanks @philippleidig! Yes, the default parameters should be changed now that we have Tc/BSD (and soon Linux) in the game (which didn't exist at the time of creation of TcUnit).

[philippleidig]

see #239

[sagatowski]

Merged in #239.