#48 Porting the library to e!COCKPIT (from WAGO)

v1.0
closed
nobody
None
2020-07-14
2020-07-10
pedro
No

I've tried to port the library as it is to e!COCKPIT (WAGO's version of CODESYS V3) to use it in my projects.

First, I did a test with CODESYS V3 in a Raspberry Pi, just following the tutorial to see and understand how the library is supposed to work.

After that, I installed the library in e!COCKPIT and ran the example of the tutorial. As far as I'm able to assess with my limited knowledge about the inner functioning of the library and the used components (CmpLog, CmpApp...):

  • It seems like the tests ran properly, as you can see in the attached screenshot (CfUnit_WAGO_ejemplo.PNG).
  • But the messages don't appear in the CfUnit logger.

Trying to solve this problem or make the library works somehow in e!COCKPIT I've been tinkering a bit with the code while reading through CODESYS Online Help. The only solution I've found is really a shabby workaround, but it works:

I've change the piece of code you can see in the in the attached screenshot (AddLogEntry_change.png). This ignores the CfUnit logger that the library creates and write the messages in the <default logger=""> successfully. This is enough for me to be able to leverage the benefits of having a unit test framework within my development tool.</default>

I hope this ticket is helpful to someone out there trying to use the library with WAGO software and also curious about the initial problem: do you have any clue about why the CfUnit logger is not working?

P.S. - Thank you very much for porting this into CODESYS from TcUnit. I'm sure is going to be very helpful to me.

2 Attachments

Related

API Reference: API Reference

Discussion

  • aliazzz

    aliazzz - 2020-07-10

    Hi!

    Thank you very much for your feedback on using CfUnit with WAGO E!Cockpit. We'll move this feedback into the FAQ section for anybody who runs into this scenario.

    Could you answer some questions for us? What version of CODESYS libraries is running in the E!Cockpit IDE?

    Can you search for CmpLog library? If it is non existent, as well as some other libs (check the library manager) we can post it so you can import it into the E!Cockpit Library Manager.

    Also, we will release the next version of CfUnit in a full package with all dependencies, so all libraries like CmpLog will be shipped with the CfUnit installer. This will solve your current issue by design.

    With kind regards,

    The CfUnit project.

     
  • aliazzz

    aliazzz - 2020-07-11
    • status: open --> closed
     
  • pedro - 2020-07-13

    Hi!

    You're welcome. I'm happy to help.

    Does this screenshot answer your question?

    CmpLog is there. Actually, digging in CmpLog documentation is how I got the idea for the workaround I explained in my first post.

     
  • aliazzz

    aliazzz - 2020-07-13

    Hi again,

    As it seems that the correct libraries are available it makes me wonder why the e!COCKPIT IDE isn't able to show the Device Log. I can't promise to write a version specific to WAGO e!COCKPIT, as most of the third party CODESYS OEM Controllers/IDE's work correct. The so software has been successfully tested on ABB Automation Builder v2.x, Schneider SoMachine, FESTO, TwinCAT (as TcUnit) and so forth. Also, WAGO works too, it's just that the logging seems not to get visualised.

    An update in which the testlog gets displayed via a webvisu is under consideration, so that makes the test output available via three separate channels (Device Log, XML File & Webvisu). For now I can try to install WAGO and check stuff out myself if needed.

    With kind regards,

    The CfUnit team

     
  • pedro - 2020-07-14

    Hi, Aliazzz.

    Yes, for some reason the 'CfUnit' is created but nothing is published in it. I guess the problem is exactly in the publishing part because only by changing the line I showed (to force the library to publish in the "Default logger"), it works as expected.

    Maybe the problem is that WAGO's IDE is doing something specific with the Device logger than we don't know about.

    Anyway, the library is usable with the little fix I commented, so no need to put many ours into something that's probably vendor's faults.

    Using webvisu would be a good way to make the library as vendor-independent as possible, I think is a good idea.

     

Log in to post a comment.