Hi,

I am looking for a method to see which dialogues that can be auto-answered using the system.prompt_answers property.

I can see in Marcus's answer here that only the dialogues having a "MessageKey" defined, can be accessed.

Is to possible to get a list of these MessageKeys (I did not find it in documentation for script engine)?

Could be either a way directly via script or could just be a list written here in the forum. I am using V3.5 Patch 3 and is particular interested in the dialogue called "CoDeSys 2.3 to 3.0 Converter" that pops up when opening a V2.3 lib and says something like "The project could not be compiled..."

Best regards,
Frank

Originally created by: M.Schaber

Hi, Frank,

Frank Jepsen hat geschrieben:
I am looking for a method to see which dialogues that can be auto-answered using the system.prompt_answers property.
I can see in Marcus's answer here that only the dialogues having a "MessageKey" defined, can be accessed.

In CoDeSys V3.5 SP1, the situation will improve a little bit. It will be possible to generically handle all simple MessageService prompts (those which only have a single OK button, thus giving no real "choice" to the user) by just logging them instead of triggering a popup.

Zitat:
Is to possible to get a list of these MessageKeys (I did not find it in documentation for script engine)?
Could be either a way directly via script or could just be a list written here in the forum.

I'm afraid that currently, there is no such list available. But I think both such a list, and some way to "catch" the message keys of a triggered message box is a good idea. I did put that issue on our ToDo-List, but if you file a feature request via our support department, that will increase the priority in the queue.

Zitat:
I am using V3.5 Patch 3 and is particular interested in the dialogue called "CoDeSys 2.3 to 3.0 Converter" that pops up when opening a V2.3 lib and says something like "The project could not be compiled..."

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.

But I also was given the general advise that it is a rather bad idea to try conversion of projects which don't compile. The conversion steps include some code transformations, and those only work when the projects compile without error. So he strictly advises that you need a complete V2.3 installation on the machine you attempt to do the conversion, and take care that all your projects compile fine using V2.3 on that same machine before attempting the conversion.

HTH,
Markus

M.Schaber hat geschrieben:
I'm afraid that currently, there is no such list available. But I think both such a list, and some way to "catch" the message keys of a triggered message box is a good idea. I did put that issue on our ToDo-List, but if you file a feature request via our support department, that will increase the priority in the queue.

Ok. I will do that. My coworker (who has the more general contact to CoDeSys at my company) tried to file a feature request via Jira the other day, but did not find a may to do it. Should I just email the feature requests to your support department?

M.Schaber hat geschrieben:
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.
But I also was given the general advise that it is a rather bad idea to try conversion of projects which don't compile. The conversion steps include some code transformations, and those only work when the projects compile without error. So he strictly advises that you need a complete V2.3 installation on the machine you attempt to do the conversion, and take care that all your projects compile fine using V2.3 on that same machine before attempting the conversion.

That does not sound good. I am afraid that it is not a good solution for my, because I need to change some code to be compatible with V3 version and I also need to load libraries in V3 for the code to be able to compile. I have developed an external script that handles all code conversion, so I am actually not using the CoDeSys Converter as I understand it. I only use it to import V2.3 code without having to write my own V2.3 to PLCopenXML converter (even though it seems as the only stable solution at the moment).

Currently, I use a combination of external scripts to modify V2.3 code, script in V2.3 to generate .lib from XML and then a GUI automation tool to literally move the mouse around in the V3 GUI to do what the script engine was supposed to do. Some operations like installing libraries in V3 has been solved using your help to generate python scripts for it, but it seems that I have to keep using the mouse-mover tool for many of the operations.

I really hope that CoDeSys soon will put focus into the script engine in V3 to get it up to a level at least as good as the one in V2.3.

Originally created by: M.Schaber

Frank Jepsen hat geschrieben:
Ok. I will do that. My coworker (who has the more general contact to CoDeSys at my company) tried to file a feature request via Jira the other day, but did not find a may to do it. Should I just email the feature requests to your support department?

I just confirmed the recommended procedure with our support department: Direct customers should contact the 3S support department. Indirect customers (those who get CoDeSys or a derivate via one of our OEMs) should contact their OEMs support department.

Frank Jepsen hat geschrieben:
That does not sound good. I am afraid that it is not a good solution for my, because I need to change some code to be compatible with V3 version and I also need to load libraries in V3 for the code to be able to compile.

Just to re-emphasize: The code must compile fine on V2.3 before attempting the import in V3. If all prerequisites (libraries etc.) are present in the V3 installation, then the importer should do all necessary conversions for you.

If you still need any custom conversions, this may be a bug in the converter (then please tell us), or it may be specific to your environment - maybe then it is better to apply your own transformations using Scripting in V3, after the conversion.

Frank Jepsen hat geschrieben:
I have developed an external script that handles all code conversion, so I am actually not using the CoDeSys Converter as I understand it. I only use it to import V2.3 code without having to write my own V2.3 to PLCopenXML converter (even though it seems as the only stable solution at the moment).

As far as I understood it, you implicitly use the Converter when you import the V2.3 project into V3. CoDeSys V3 has no means of directly reading a V2.3 project, it always relies on V2.3 code to do so.

Frank Jepsen hat geschrieben:
Currently, I use a combination of external scripts to modify V2.3 code, script in V2.3 to generate .lib from XML and then a GUI automation tool to literally move the mouse around in the V3 GUI to do what the script engine was supposed to do. Some operations like installing libraries in V3 has been solved using your help to generate python scripts for it, but it seems that I have to keep using the mouse-mover tool for many of the operations.
I really hope that CoDeSys soon will put focus into the script engine in V3 to get it up to a level at least as good as the one in V2.3.

Hmm, the first release of IronPython ScriptEngine in V3.4 SP3 was intended to cover everything which was possible using "Batch Mode" in V2.3. But I never used V2.3 myself, I only had a specification document written by an V2 expert when implementing the V3 Script Engine. Could you tell me which of the things you need were dropped?

M.Schaber hat geschrieben:
I just confirmed the recommended procedure with our support department: Direct customers should contact the 3S support department. Indirect customers (those who get CoDeSys or a derivate via one of our OEMs) should contact their OEMs support department.
Thanks. I will contact the 3S support via email then regarding the feature request we have discussed recently.

M.Schaber hat geschrieben:
Just to re-emphasize: The code must compile fine before attempting the import in V3. If all prerequisites (libraries etc.) are present in the V3 installation, then the importer should do all necessary conversions for you.
If you still need any custom conversions, this may be a bug in the converter (then please tell us), or it may be specific to your environment - maybe then it is better to apply your own transformations using Scripting in V3, after the conversion.
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. As far as I can see, there are no objects in the V3 script engine to directly manipulate the code-text. This means that it is not possible to do this conversion from script engine in V3. Please correct me if I am wrong.

M.Schaber hat geschrieben:
As far as I understood it, you implicitly use the Converter when you import the V2.3 project into V3. CoDeSys V3 has no means of directly reading a V2.3 project, it always relies on V2.3 code to do so.
Yep. We understand each other on that point and I see where the Converter is used in the process.

M.Schaber hat geschrieben:
Hmm, the first release of IronPython ScriptEngine in V3.4 SP3 was intended to cover everything which was possible using "Batch Mode" in V2.3. But I never used V2.3 myself, I only had a specification document written by an V2 expert when implementing the V3 Script Engine. Could you tell me which of the things you need were dropped?
Certainly, if that helps the process of getting V3 script engine in a usable condition.

Syntax: V2.3 cmd - What I use it for - What I would like in V3
"project rebuild" - Used for compiling - In V3 I lack access to "Check all Pool Objects" and "Build", without having to connect hardware and call them indirectly using "login".
"onerror continue" - Make sure that I can save project even if compile fails - Do not know how this will work in V3, since there is no direct "Build" method.
"query off ok" - Make all dialogs go away - We discussed it in this thread and I can see that it is coming but still is not there in V3

Furthermore, in V2.3 we have an ENI server that stores source in XML. This makes in possible to access "objects" that it is not possible to access in V3; e.g. the project information we discussed the other day. Even though we have an external program to access it, it is still possible to automate, which it is not in V3 without the GUI-clicker.

Originally created by: M.Schaber

Hi, Frank,

Frank Jepsen hat geschrieben:
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. As far as I can see, there are no objects in the V3 script engine to directly manipulate the code-text. This means that it is not possible to do this conversion from script engine in V3. Please correct me if I am wrong.

It is planned at least for the text based objects (ST, GVL etc.).

As a workaround, you can use PLCOpenXML export, manipulate the XML, and re-import. For that, you do not even need temporary files, as the export_xml and import_xml functions can work with strings.

Frank Jepsen hat geschrieben:
Certainly, if that helps the process of getting V3 script engine in a usable condition.
Syntax: V2.3 cmd - What I use it for - What I would like in V3
"project rebuild" - Used for compiling - In V3 I lack access to "Check all Pool Objects" and "Build", without having to connect hardware and call them indirectly using "login".

This exists as a jira entry, you could ask the support to add you as an interested customer for that Jira to increase priority.

Frank Jepsen hat geschrieben:
"onerror continue" - Make sure that I can save project even if compile fails - Do not know how this will work in V3, since there is no direct "Build" method.

In CoDeSys V3, Saving and Compiling are different operations. And for the scriptengine, errors are either reported via return values or as exceptions (which can be caught in the script). So I do not see any reason why a non-compilable project should be unsaveable.

Frank Jepsen hat geschrieben:
"query off ok" - Make all dialogs go away - We discussed it in this thread and I can see that it is coming but still is not there in V3

A complete option to make all dialogs go away is not that easy in V3, as each plugin can just open its own dialog windows using .NET API. But it is certainly possible to "silence" a lot more of the dialogs than currently done, just by returning the "default" value or "OK" or so for all MessageService windows, denying all Authentication queries etc.

Maybe the --NoUI mode helps you a little bit in this direction.

Frank Jepsen hat geschrieben:
Furthermore, in V2.3 we have an ENI server that stores source in XML. This makes in possible to access "objects" that it is not possible to access in V3; e.g. the project information we discussed the other day. Even though we have an external program to access it, it is still possible to automate, which it is not in V3 without the GUI-clicker.

In V3, you can always use PlCOpenXML or native export/import to access the objects. And we still plan on improving object access, the Project Information is rather high on the list.

M.Schaber hat geschrieben:
In V3, you can always use PlCOpenXML or native export/import to access the objects. And we still plan on improving object access, the Project Information is rather high on the list.
I think we are getting a little off track though, but this assumes that the PLCopenXML or native export/import works, which it does not do for project information at the moment (not in GUI and not in script). Actually I cannot import anything using native import after an export, even though I can see that the exported file looks like it have the correct contents (tested in GUI only).

However, I still want to thank you for your effort in trying to help me. I am just a little sad, that the program is not able to do all that I want it to.

Best regards,
Frank

demo.zip [155.64 KiB]

Originally created by: M.Schaber

Hi, Frank,

The following items may be of interest for you:

HTH,
Markus

Hi Markus,

Thanks for the list. I am working on a complete list of issues for my case that I can submit to CoDeSys support.

Is there any way that I can help in the process of getting the updates to script engine? It would be nice if it was possible to be "beta-tester" or something (I know that kk-electronic has been that for some CoDeSys run-time issues). If it is possible, then we should take it on e-mail I think. My address is: e frjep@kk-electronic.com e

Best regards,
Frank

Originally created by: M.Schaber

Hi, Frank,

Frank Jepsen hat geschrieben:
Thanks for the list. I am working on a complete list of issues for my case that I can submit to CoDeSys support.
Is there any way that I can help in the process of getting the updates to script engine? It would be nice if it was possible to be "beta-tester" or something (I know that kk-electronic has been that for some CoDeSys run-time issues). If it is possible, then we should take it on e-mail I think.

I think the first step for being beta-tester is to be registered as an interested customer for theissues in our jira database.

I'll ask our the QA department for the beta teste possibilities.