Zitat:
I just queried my coworker responsible for the converter code. The converter internally calls into CoDeSys V2.3 code via COM, and this dialog is shown by that V2.3 code. So it does not use the CoDeSys 3.x MessageService, and thus there is no possibility to catch it from a Python script.
The message I specifically want to suppress is:
Zitat:
The project could not be compiled. Syntax adaption of the source code will not be performed!
The reason for this is that my V2.3 and V3.x code are not dependent on the same library, so I do some syntax adaption in the V2.3 code before importing it - therefore, it is not possible for me to get it to compile in V2.3.
Best regards,
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-06-19
Originally created by: M.Schaber
Hi, Frank,
This issue was officially considered as Requirement 686. It was denied by our product management, because they consider the code adaption a very important part of the conversion functionality.
The following workarounds could be considered:
The first way has the advantage that it still preserves the code adaptions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your answer and the possible workarounds. I will consider which choice to make. For your information I have now tried some of the new script engine functionality in V3.5 SP3 and this helps me a lot. The only thing missing before I have set up a complete scripting autobuild now, is the warning dialog from V2.3 Converter. My current workaround is to start CoDeSys with script from command-line and after that I start another program which waits for any dialog to appear with the specific title and then it shuts it down and waits for the CoDeSys process to finish.
Best regards,
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-06-20
Originally created by: M.Schaber
Hi, Frank,
Just out of curiosity: The issue was first raised in May 2012. Do you really have such a big bunch of projects to convert from V2 to V3, so you're still busy for such a long time?
Thanks,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No. I do know have that many projects to convert. However, in my company we develop software that supports multiple HW platforms and some has 2.3 runtime and some has 3.x runtime.
What we do is that we primarily develop for 2.3 since this has the largest customer base and then our continuous integration build server automatically converts the 2.3 source code into 3.x before building the binaries for 3.x runtime. Then only a few pieces of the source code has to be actually saved in version control system as V3.x.
The reason for me to bring up the issue again, was that I am currently working on improvements of the build system. I do not work full-time with that.
Best regards,
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-06-21
Originally created by: M.Schaber
Hi, Frank,
In that scenario, disabling the automatic conversions done by the codesys converter seems contra productive to me. Especially, as you start with an existing V2.3 project without compile errors.
In your case, I really think the best solution is to use the converter on the unmodified V2.3 project, and then apply your custom modifications using scripting and PLCOpenXML afterwards.
HTH,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The V2.3 projects are not without compile errors even before syntax conversion. The V2.3 projects are libraries that are supposed to be included in larger projects. First after being included in that project, they can compile in V2.3.
So if I want to avoid the Converter dialog, then I really only see two rather large tasks. Either modify the way our entire code base is assembled so libraries can compile by themselves or write our own converter and skip using built-in V2.3 to 3.0 Converter.
For now I will stick with the work-around even though it is quite a "hack".
If I cannot get this work-around to be reasonable stable, then I think I will go for writing my own converter from V2.3 to PLCOpenXML. I have had that in mind almost from the beginning of creating the system, but thought that there must be a way around the dialog since it is only a warning. Now that 3-S has decided not to implement that, I see this as kind of the last way around. Even though the decision not to allow script access to that particular dialog because syntax adaption is important seems a little self-contradictory, when using the converter manually then it is only a warning. If the syntax adaption was really that important, then I guess you should not allow import without syntax adaption manually either.
Best regards,
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-06-21
Originally created by: M.Schaber
Hi, Frank,
Zitat:
Even though the decision not to allow script access to that particular dialog because syntax adaption is important seems a little self-contradictory
I just feel a need to clarify: Script access to that dialog is not explicitly prevented by us. It is just a negative side-effect of the fact that this dialog is directly raised from the V2.3 code which is internally used by the converter, and not via the normal CODESYS V3 infrastructure.
Additionally, the fact that libraries exist in V2.3 which won't compile, but are still correct in the sense that they're usable from a project was not known to me (nor mentioned by you up to now) - until now, I was under the impression that it is your pre-conversion modifications which break the compilation. (I'm not a V2.3 expert, though...)
Considering those new facts, this seems like a valid use case, and I'll re-raise the issue internally.
HTH,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, I do not agree that the description of the use case is new. I described the use case on May 3, 2012, when we discussed it the first time. See post 5 in l viewtopic.php?f=18&t=4888 l . Comparing with my description in this thread I think it is quite similar.
Description from old thread:
Zitat:
The code is not able to compile by itself in V2.3 since it is a library, that needs to be included in a larger project before it is able to compile; that is why the code will not be able to compile in V2.3. Furthermore, I need to do some custom conversions that are very specific at my company because V2.3 and V3 code is not supposed to run on the same hardware platform.
Description in this thread:
Zitat:
The reason for this is that my V2.3 and V3.x code are not dependent on the same library, so I do some syntax adaption in the V2.3 code before importing it - therefore, it is not possible for me to get it to compile in V2.3.
...
The V2.3 projects are not without compile errors even before syntax conversion. The V2.3 projects are libraries that are supposed to be included in larger projects. First after being included in that project, they can compile in V2.3.
We discussed quite some back and forth at that time, so the point might have gotten lost at the time.
Best regards,
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-07-01
Originally created by: M.Schaber
Hi,
Sorry for the long delay, I've been out of office last week.
Yes, I have to admit, that point got lost.
The Requirement entry in our Jira Database does indeed not contain the fact that those are libraries which don't compile despite being "correct", neither the fact that this is a regular process instead of an one-time migration issue.
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-07-17
Originally created by: M.Schaber
Hi,
This issue was now again discussed internally.
I got the following arguments from my coworkers:
As I said, I myself am not a V2.3 expert, so I just have to accept their arguments.
HTH,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I know I have raised this question before, but there might have been some improvements since last time.
Is it possible to suppress the dialogs from CoDeSys V2.3, when using Python script to e.g. convert a V2.3 library to a V3.x library?
Previous answer was: (from l viewtopic.php?f=18&t=4888 l )
The message I specifically want to suppress is:
The reason for this is that my V2.3 and V3.x code are not dependent on the same library, so I do some syntax adaption in the V2.3 code before importing it - therefore, it is not possible for me to get it to compile in V2.3.
Best regards,
Frank
Originally created by: M.Schaber
Hi, Frank,
This issue was officially considered as Requirement 686. It was denied by our product management, because they consider the code adaption a very important part of the conversion functionality.
The following workarounds could be considered:
The first way has the advantage that it still preserves the code adaptions.
Hi Markus,
Thanks for your answer and the possible workarounds. I will consider which choice to make. For your information I have now tried some of the new script engine functionality in V3.5 SP3 and this helps me a lot. The only thing missing before I have set up a complete scripting autobuild now, is the warning dialog from V2.3 Converter. My current workaround is to start CoDeSys with script from command-line and after that I start another program which waits for any dialog to appear with the specific title and then it shuts it down and waits for the CoDeSys process to finish.
Best regards,
Frank
Originally created by: M.Schaber
Hi, Frank,
Just out of curiosity: The issue was first raised in May 2012. Do you really have such a big bunch of projects to convert from V2 to V3, so you're still busy for such a long time?
Thanks,
Markus
Hi Markus,
No. I do know have that many projects to convert. However, in my company we develop software that supports multiple HW platforms and some has 2.3 runtime and some has 3.x runtime.
What we do is that we primarily develop for 2.3 since this has the largest customer base and then our continuous integration build server automatically converts the 2.3 source code into 3.x before building the binaries for 3.x runtime. Then only a few pieces of the source code has to be actually saved in version control system as V3.x.
The reason for me to bring up the issue again, was that I am currently working on improvements of the build system. I do not work full-time with that.
Best regards,
Frank
Originally created by: M.Schaber
Hi, Frank,
In that scenario, disabling the automatic conversions done by the codesys converter seems contra productive to me. Especially, as you start with an existing V2.3 project without compile errors.
In your case, I really think the best solution is to use the converter on the unmodified V2.3 project, and then apply your custom modifications using scripting and PLCOpenXML afterwards.
HTH,
Markus
Hi Markus,
The V2.3 projects are not without compile errors even before syntax conversion. The V2.3 projects are libraries that are supposed to be included in larger projects. First after being included in that project, they can compile in V2.3.
So if I want to avoid the Converter dialog, then I really only see two rather large tasks. Either modify the way our entire code base is assembled so libraries can compile by themselves or write our own converter and skip using built-in V2.3 to 3.0 Converter.
For now I will stick with the work-around even though it is quite a "hack".
If I cannot get this work-around to be reasonable stable, then I think I will go for writing my own converter from V2.3 to PLCOpenXML. I have had that in mind almost from the beginning of creating the system, but thought that there must be a way around the dialog since it is only a warning. Now that 3-S has decided not to implement that, I see this as kind of the last way around. Even though the decision not to allow script access to that particular dialog because syntax adaption is important seems a little self-contradictory, when using the converter manually then it is only a warning. If the syntax adaption was really that important, then I guess you should not allow import without syntax adaption manually either.
Best regards,
Frank
Originally created by: M.Schaber
Hi, Frank,
I just feel a need to clarify: Script access to that dialog is not explicitly prevented by us. It is just a negative side-effect of the fact that this dialog is directly raised from the V2.3 code which is internally used by the converter, and not via the normal CODESYS V3 infrastructure.
Additionally, the fact that libraries exist in V2.3 which won't compile, but are still correct in the sense that they're usable from a project was not known to me (nor mentioned by you up to now) - until now, I was under the impression that it is your pre-conversion modifications which break the compilation. (I'm not a V2.3 expert, though...)
Considering those new facts, this seems like a valid use case, and I'll re-raise the issue internally.
HTH,
Markus
Hi Markus,
Thanks for raising the issue again.
However, I do not agree that the description of the use case is new. I described the use case on May 3, 2012, when we discussed it the first time. See post 5 in l viewtopic.php?f=18&t=4888 l . Comparing with my description in this thread I think it is quite similar.
Description from old thread:
Description in this thread:
We discussed quite some back and forth at that time, so the point might have gotten lost at the time.
Best regards,
Frank
Originally created by: M.Schaber
Hi,
Sorry for the long delay, I've been out of office last week.
Yes, I have to admit, that point got lost.
The Requirement entry in our Jira Database does indeed not contain the fact that those are libraries which don't compile despite being "correct", neither the fact that this is a regular process instead of an one-time migration issue.
Markus
Originally created by: M.Schaber
Hi,
This issue was now again discussed internally.
I got the following arguments from my coworkers:
As I said, I myself am not a V2.3 expert, so I just have to accept their arguments.
HTH,
Markus
Hi Markus,
Thanks for considering the issue again and posting the response from your coworker.
I will bring the issue up in my department again and then we can find a solution that works for us.
Best regards,
Frank
Originally created by: M.Schaber
Hi, Frank,
Feel free to contact me with email or via our support department to discuss more details if necessary.
HTH,
Markus