|
Re: No trace info in Debug mode in 4DIAC-IDE [message #1733363 is a reply to message #1733339] |
Thu, 26 May 2016 13:44 |
|
Hi, if you are using the prebuilt version of FORTE which comes with 4DIAC-IDE the event tracing on the console is deactivated. The reason for this is that the first of all event tracing clutters the console a lot and can lead that more important messages are not shown. Furthermore this logging feature is rather slow and therefore degrades the performance of your control application.
If you want to have tracing enabled you need to build your own FORTE (please see the docs for details on this) and activate in the advanced section of the FORTE CMake properties the option FORTE_TRACE_EVENTS.
Cheers,
Alois
|
|
|
Re: No trace info in Debug mode in 4DIAC-IDE [message #1734065 is a reply to message #1733363] |
Fri, 03 June 2016 13:03 |
Vuk Lesi Messages: 6 Registered: May 2016 |
Junior Member |
|
|
Thank you very much for a quick reply.
I am able to follow instructions on how to compile FORTE from source with CMake, but it seems like I am not able to obtain an executable file whose path I can just set in 4DIAC to be used in stead of the default precompiled FORTE. Am I expecting the right thing?
The other question that I have is the following: If event tracing is slowing down the application and is generally not recommended to be left enabled, is there any other (better) way to obtain the trace of events so that the distributed behavior and execution semantics could be easily extracted for a certain function block network? EDIT: What I am really trying to ask is whether or not event tracing can have any effect on the semantics of execution.
Thank you very much for your help.
[Updated on: Sat, 04 June 2016 15:30] Report message to a moderator
|
|
|
Re: No trace info in Debug mode in 4DIAC-IDE [message #1734184 is a reply to message #1734065] |
Sun, 05 June 2016 21:31 |
|
Hi,
the executable should be located in a directory "src" in your bin directory.
Tracing may have an effect if you have several threads in parallel then because of tracing it could be that the order of execution in the threads relative to each other is different (but after a second thought this may be corner cases and not happening often). But with in a thread the execution is always the same independent of the tracing enabled or disabled.
Cheers,
Alois
|
|
|
|
|
|
|
Re: No trace info in Debug mode in 4DIAC-IDE [message #1743537 is a reply to message #1743495] |
Fri, 16 September 2016 09:25 |
|
Hi,
during the testing between 1.8 M1 and the final 1.8 release we noticed that logging and tracing takes quite some resources. Therefore we decided that loging will be disabled in the default release build.
In order to enable it you need to set the CMAKE_BUILD_TYPE to Debug telling the build system you like to have a debug build.
|
|
|
|
|
|
|
|
|
|
Re: No trace info in Debug mode in 4DIAC-IDE [message #1761068 is a reply to message #1761043] |
Fri, 05 May 2017 20:38 |
|
Please don't add this option by yourself. All cmake options prefixed with CMAKE are cmake default options which are coming from the cmake system itself. Cmake stores a specific configuration with your setup in a file called CMakeCache.txt in your build directory. You can open this file and edit the options if you want to change the configuration. for make based builds then running make should correctly use these options. I don't have so much experience with VS therefore I don't know if this is the case also for VS.
|
|
|
|
Re: No trace info in Debug mode in 4DIAC-IDE [message #1761108 is a reply to message #1761082] |
Sat, 06 May 2017 21:26 |
|
Thaks for the figure of the system configuration. I think the problem is that, as said above, you have two devices on with the ID "localhost:61499" (Steuerung and Control). As this is not allowed from a TCP point of view even if you are only running one of the both we can not handle this in the monitoring code. By changing the port of one of the both.
|
|
|
|
Re: No trace info in Debug mode in 4DIAC-IDE [message #1761163 is a reply to message #1761118] |
Mon, 08 May 2017 12:35 |
|
Great that it works now. The reason for the difference is that 1.6.2 made it accidentally correct. However this could lead to other unwanted and even worse wrong situiations. With the clean-up of the monitoring code in 1.8.x we had to change the behvaior. Although that this lead to an overall more stable code this special situation is now not possible anymore.
|
|
|
Powered by
FUDForum. Page generated in 0.06234 seconds