Hallo Gemeinde,
ich versuche den Debugger zu ergruenden. SingleStep ist ja einfach, doch haeufig wenig zielfuehrend. Denn das wichtigste was ein Debugger braucht sind Breakpoints. Ich suche und probiere mir die Finger wund, ich komm aber nicht drauf. Wie baut man Breakpoints ein? Ablaufdiagramme schreien doch foermlich nach so einer Meachanik. Oder sollte es die etwa gar nicht geben? Ein Debugger ohne Braekpoints ist doch wie ein Fisch ohne Fahrrad. Uebersehe ich da etwas?
Viele Gruesse & ein gesundes Jahr 2022
Thomas
Debugger & Breakpoints
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
Re: Debugger & Breakpoints
Very simple.
You click in the Python code panel at the left side of a line number and you will get a red point.
(Between the line number and the left border line, almost just near the border line.
Only lines with executable Python code make sense.
The break points can be removed in the Breakpoint panel.
(It is not possible to post an image as attachment here.)
You click in the Python code panel at the left side of a line number and you will get a red point.
(Between the line number and the left border line, almost just near the border line.
Only lines with executable Python code make sense.
The break points can be removed in the Breakpoint panel.
(It is not possible to post an image as attachment here.)
Re: Debugger & Breakpoints
Oups, forgot to mention: I'm referring to RoboPro 
Re: Debugger & Breakpoints
In the original RoboPro:
There are no breakponts in RoboPro.
You can only "pause" a workflow and then continue with a single step.
Some kind of breaking point:
Place a workflow element "delay".
Start the program in debugger mode (yellow arrow).
During the delay, press "Pause the program in the debugger" (two yellow lines).
Continue with the single step button (yellow line +arrow).
During the design phase of programs, however, it may be advisable, from a view of the maintainability of your program, to add extra elements, such as for example: outputs and "delay" workflow elements, in a way that you can actually use the functions. based on predictions. Programming is more than just writing the right code to think that your program does what you have in mind.
That's the big difference when writing code or developing a program. The theory of unit testing" also applies here.
Unfortunately, this approach is lacking in the many sample programs provided by fischertechnik.
Programming is also using a systematic approach that helps you to test program components for their correctness.
There are no breakponts in RoboPro.
You can only "pause" a workflow and then continue with a single step.
Some kind of breaking point:
Place a workflow element "delay".
Start the program in debugger mode (yellow arrow).
During the delay, press "Pause the program in the debugger" (two yellow lines).
Continue with the single step button (yellow line +arrow).
During the design phase of programs, however, it may be advisable, from a view of the maintainability of your program, to add extra elements, such as for example: outputs and "delay" workflow elements, in a way that you can actually use the functions. based on predictions. Programming is more than just writing the right code to think that your program does what you have in mind.
That's the big difference when writing code or developing a program. The theory of unit testing" also applies here.
Unfortunately, this approach is lacking in the many sample programs provided by fischertechnik.
Programming is also using a systematic approach that helps you to test program components for their correctness.
Re: Debugger & Breakpoints
"There are no breakponts in RoboPro."
Arrrggghhhhhhh ...
"During the delay, press "Pause the program in the debugger" (two yellow lines)."
Thanks, that's an option. However, way apart from what I'm calling "debugging features". But at least I know now, that RoboPro is limited in such a way and I have to work around or should better use C, Python et al.
"Programming is more than just writing the right code to think that your program does what you have in mind."
Really
?
"Programming is also using a systematic approach that helps you to test program components for their correctness."
Well, probably I didn't tell, that my background is hard- and software engineering for life supporting devices. But I must admit it's some years (decades
) back. We've been used to Assembler and C. But nevertheless even there we had debuggers with (conditional) breakpoints.
Arrrggghhhhhhh ...
"During the delay, press "Pause the program in the debugger" (two yellow lines)."
Thanks, that's an option. However, way apart from what I'm calling "debugging features". But at least I know now, that RoboPro is limited in such a way and I have to work around or should better use C, Python et al.
"Programming is more than just writing the right code to think that your program does what you have in mind."
Really
?"Programming is also using a systematic approach that helps you to test program components for their correctness."
Well, probably I didn't tell, that my background is hard- and software engineering for life supporting devices. But I must admit it's some years (decades
) back. We've been used to Assembler and C. But nevertheless even there we had debuggers with (conditional) breakpoints.Re: Debugger & Breakpoints
RoboPro is a very nice 4G work flow with data flow for inter process synchronization program development environment.
I am using it now for more then 20 years and as software engineer/instructor I am working normally with imperative, declarative and functional programming concepts and languages for more then 40-ty years.
Debugging with break points is not really needed with the approach of RoboPro.
It is not imperative programming what you are doing with assembler, C etc.
I am using it now for more then 20 years and as software engineer/instructor I am working normally with imperative, declarative and functional programming concepts and languages for more then 40-ty years.
Debugging with break points is not really needed with the approach of RoboPro.
It is not imperative programming what you are doing with assembler, C etc.
Re: Debugger & Breakpoints
Hi Pinot,
ich bin ja kein Informatiker, verstehe unter „Breakpoint“ eine Stelle, an welcher das Programm im Debugmodus stehen bleibt, bis ein „weiter“ kommt, oder?
Dann kannst Du doch einfach eine Tasterabfrage einbauen und hast Deinen „Breakpoint“, oder verstehe ich das falsch?
Grüßle
Der Kali
ich bin ja kein Informatiker, verstehe unter „Breakpoint“ eine Stelle, an welcher das Programm im Debugmodus stehen bleibt, bis ein „weiter“ kommt, oder?
Dann kannst Du doch einfach eine Tasterabfrage einbauen und hast Deinen „Breakpoint“, oder verstehe ich das falsch?
Grüßle
Der Kali
Re: Debugger & Breakpoints
Hallo Kali,
„Dann kannst Du doch einfach eine Tasterabfrage einbauen und hast Deinen „Breakpoint““
Ja, das ist denkbar. Nur wenn Du über den Breakpoint hinaus willst, dann musst Du auch nen Taster und nen
Eingang dafür haben. Und einen Breakpoint zu definieren, der das Programm an bel. Stelle anhält wenn bestimmte Variablen definierte Werte annehmen ist so auch nicht möglich.
Beispiel: eine Variable x wird negativ, was sie nach der implementierten Logik nie werden sollte. Da ist es praktisch dem Debugger sagen zu können „Halte das Programm an wenn x<0“.
Mit Breakpoints zu arbeiten ist eine mächtige Hilfe in der Fehlersuche. Aber wie ich hier lerne mit RoboPro nur umständlich möglich.
Viele Grüße
Thomas
„Dann kannst Du doch einfach eine Tasterabfrage einbauen und hast Deinen „Breakpoint““
Ja, das ist denkbar. Nur wenn Du über den Breakpoint hinaus willst, dann musst Du auch nen Taster und nen
Eingang dafür haben. Und einen Breakpoint zu definieren, der das Programm an bel. Stelle anhält wenn bestimmte Variablen definierte Werte annehmen ist so auch nicht möglich.
Beispiel: eine Variable x wird negativ, was sie nach der implementierten Logik nie werden sollte. Da ist es praktisch dem Debugger sagen zu können „Halte das Programm an wenn x<0“.
Mit Breakpoints zu arbeiten ist eine mächtige Hilfe in der Fehlersuche. Aber wie ich hier lerne mit RoboPro nur umständlich möglich.
Viele Grüße
Thomas
Re: Debugger & Breakpoints
A breakpoint can potentially be counterproductive if it is in a time critical section.
For example, in control loops, breakpoints can be deadly; after all, the actuator continues to rotate because the feedback and the stop condition in the loop are disturbed.
More important in the design of a program is an appropriate strategy for checking its correctness. And this as an inseparable part of this design. Breakpoints, assessments, logging are a few of the many tools that could be used for this.
Important in all this is that a prediction can be made in advance about the situation that is expected at a certain place in the program and that this can also be verified.
Breakpoints and "single step" are often abused in "try and error" programming. One writes a piece of code and then uses those tools to understand what that code actually does. Frequently heard phrases are often: "The program does not do what I want.", "The program does not work." "It almost works, only this part doesn't work yet.".
However, a computer is a very stupid device. A program always does exactly what the programmer has put in his program. Unfortunately, some programmers themselves do not know what they have actually programmed.
For that reason, having a good description of what the (sub)program or loop should do is very important.
Something in verifiable terms of: if I put this in, that comes out.
I would rather have expected the question:
-) What is the strategy in this program development environment for checking the correctness of my program?
-) What tools are available for this?
-) How can these tools be used strategically?
No translation into German has been provided as I cannot verify its correctness.
For example, in control loops, breakpoints can be deadly; after all, the actuator continues to rotate because the feedback and the stop condition in the loop are disturbed.
More important in the design of a program is an appropriate strategy for checking its correctness. And this as an inseparable part of this design. Breakpoints, assessments, logging are a few of the many tools that could be used for this.
Important in all this is that a prediction can be made in advance about the situation that is expected at a certain place in the program and that this can also be verified.
Breakpoints and "single step" are often abused in "try and error" programming. One writes a piece of code and then uses those tools to understand what that code actually does. Frequently heard phrases are often: "The program does not do what I want.", "The program does not work." "It almost works, only this part doesn't work yet.".
However, a computer is a very stupid device. A program always does exactly what the programmer has put in his program. Unfortunately, some programmers themselves do not know what they have actually programmed.
For that reason, having a good description of what the (sub)program or loop should do is very important.
Something in verifiable terms of: if I put this in, that comes out.
I would rather have expected the question:
-) What is the strategy in this program development environment for checking the correctness of my program?
-) What tools are available for this?
-) How can these tools be used strategically?
No translation into German has been provided as I cannot verify its correctness.