Hi, Frank,
Frank Jepsen wrote:
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 wrote:
M.Schaber wrote:
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".
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 wrote:
"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 wrote:
"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 wrote:
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.
_________________
Check out the CODESYS store:
http://store.codesys.com/CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions