Hello, I visited the CDS Users Conference ... I saw there is a way to debug scipts with e.g. Pydevd, PyCharm, PyDev or LiClipse ... do you know if any of a free versions like PyCharm Community Edition is working

Originally created by: M.Schaber

Hi,

The Debugging functionality currently relies on "remote debugging" capabilities.

According to PyCharm Editions Comparison, remote debugging is only supported in the professional edition of PyCharm. I don't know the details of other IDEs and their feature policies.

Personally, I did switch to PTVS and the .NET based debugging approach, because that one "just works" without any further effort by attaching to a running CODESYS process. (In theory, it should also work with SharpDevelop or MonoDevelop / Xamarin Studio, but I never tried them.)

The python based debugging approach currently requires that one starts CODESYS with special command line parameters, and needs an active "connection" script to be maintained, so the ScriptEngine can actually connect to the debugger.

We will most likely improve on that situation in the future, but (also most likely) it will stay a "remote debugging" mechanism. Everything else would require the CODESYS installation to more closely emulate a traditional python distribution (which requires quite some architectural work including changing the installation directory layout which has some constraints due to our OEMs), and additionally each script run would need a fresh CODESYS instance to be started from scratch.

We also have some plans to integrate an IronPython debugger right into CODESYS itself, but unfortunately, such issues are handled with low priority.

HTH,
Markus

Hello, thank you for the fast Feedback ... hope the CDS Python Debugger will coming soon

Hello,

i have a question concerning debugging Python scripts in Visual Studio:

i have installed PTVS 2.1 and try to debug the script example of the Codesys user's conference. I opened a script file, attached it to running Codesys.exe. Then i started the script from Codesys, but i cannot get Visual Studio to hit the breakpoint:

Do i miss something? Thx...

Originally created by: M.Schaber

Hi,

To be honest, I have no idea what's going wrong.

Just some thoughts:
- Are you sure the file path is the same?
- What happens if you call the System.Diagnostics.Debugger.Launch() or System.Diagnostics.Debugger.Break() functions?

I figured out the problem. When attaching the script to the Codesys.exe process, i have to select code type 'Python' to make it work

Originally created by: M.Schaber

Hi,

I always tried using "Managed" rsp. ".NET" code, and it also worked. Glad you got it to work.

M.Schaber hat geschrieben:
The python based debugging approach currently requires that one starts CODESYS with special command line parameters, and needs an active "connection" script to be maintained, so the ScriptEngine can actually connect to the debugger.

Hello!

What is the special command line option? And what sort of script is needed?

Is it just the option to run the script, and is the script just any script that waits a little at the beginning before doing its work?

Also, how does the attach to process work, do I just have the same python script file open in Visual Studio and say "attach to process"? I have Visual Studio Tools for Python installed.

Also, I noticed with a script I was running that it was blocking the GUI. Do you have the python interpreter running in the UI thread, so if I run a python script I cannot control the UI anymore? I would like to do both, run python script and control UI at same time.

Thanks, best
Andreas Reiff

Originally created by: M.Schaber

Hi,

Just to recall, there are two debugging approaches possible with IronPython in CODESYS:
- The .NET based approach using the .NET debugging APIs
- The Python (settrace) based approach

andipandi hat geschrieben:
What is the special command line option? And what sort of script is needed?
Is it just the option to run the script, and is the script just any script that waits a little at the beginning before doing its work?

The python debugger based approach is a little more complicated. You need an Python IDE with "remote debugging" enabled and waiting for connections, and then the connection script needs to hook into sys.settrace() and open the connection to the debugger.

For example, we successfully got it working with PyCharm using the following command line:

CODESYS.exe --profile="CODESYS V3.5 SP5" --scriptDebugger="D:\test\charmdebug\initdebug.py"

The file "initdebug.py" itself looks like:

from __future__ import print_function
from __future__ import unicode_literals
import sys
sys.path.append(r"D:\test\Env2\Lib\site-packages\pycharm-debug.egg")
import pydevd
def scriptdebuggersetup():
    pydevd.settrace('localhost', port=51234, stdoutToServer=True, stderrToServer=True)
def scriptdebuggershutdown():
    pydevd.stoptrace()

You will need to adapt the pathes (and possible hostname and port) to match your own installation.

andipandi hat geschrieben:
Also, how does the attach to process work, do I just have the same python script file open in Visual Studio and say "attach to process"? I have Visual Studio Tools for Python installed.

If you're using Python Tools for Visual Studio, I'd suggest you use the .NET based debugger approach, as it is much less troublesome.

You just use "Attach to process" to the running CODESYS instance before you start the script, and select "Python" as well as "Managed (V4.0)". (It may also be "Managed (V4.0, V4.5)" or similar depending on the installed VS and .NET versions, just make sure you don't select the "Managed (V2.0/3.0/3.5)" instead. Then you simply open the script in Visual studio, set the breakpoint, and start it in CODESYS, that should work (and did in all my tests).

andipandi hat geschrieben:
Also, I noticed with a script I was running that it was blocking the GUI. Do you have the python interpreter running in the UI thread, so if I run a python script I cannot control the UI anymore? I would like to do both, run python script and control UI at same time.

Yes, the python interpreter is running in the main thread. A technical reason is that the CODESYS architecture is inherentily bound to the UI thread for most API calls for historical reasons, so for running the scripts in a background thread, each interaction between the script and CODESYS would have to be marshalled to the UI thread. Another reason is that the focus of the ScriptEngine is to automate tasks which the user also can do manually - user interaction during those automated tasks would very likely disturb the script due to side-effects.

Depending on your exact use case, the solution may be:

HTH,
Markus

Many thanks for the answer, Markus.

The python debugging part looks good, I will try this.

As for the testing, I think I want to go for option 2, the CODESYS Test Manager.

My main goal is to automate codesys (actually a program that is built on/extends codesys) but find many UI controls not to adhere to MSAA or MSUIA standards and thus I am looking for another way to be able to do what I want. (Right now I am using Silktest.)

What sort of control do I have with Test Manager? Can I integrate test manager into test running in another context, like any test runner?

Originally created by: M.Schaber

Hi, andipandi,

andipandi hat geschrieben:
Many thanks for the answer, Markus.
The python debugging part looks good, I will try this.
As for the testing, I think I want to go for option 2, the CODESYS Test Manager.
My main goal is to automate codesys (actually a program that is built on/extends codesys) but find many UI controls not to adhere to MSAA or MSUIA standards and thus I am looking for another way to be able to do what I want. (Right now I am using Silktest.)
What sort of control do I have with Test Manager? Can I integrate test manager into test running in another context, like any test runner?

The execution of Test Manager Scripts can be triggered via Command Line arguments, this way, it can be included in CI systems (we use it in-house, where we integrated CODESYS into the Jenkins build server using both Script Engine (for build tasks) and the Test Manager (for automated test execution).

Originally created by: M.Schaber

Hi,

there's some additional information about the test manager in the store:
http://store.codesys.com/codesys-test-manager.html

You can also use a free trial license to try it out before buying (but you'll need a dongle even for the trial license).

HTH,
Markus