Lokale Variablen in Funktionen

[tttttom]

Hallo Community,

wir verwenden RoboPro 4.7 mit TXT-Controller und ft-Kamera.

Aufgabe: Minimum eines RGB-Farbwertes berechnen.

Folgendes Problem:
Wir wollen von der Kamera die 3 Farbwerte auswerten. In einer Funktion soll das Minimum erkannt und zurückgegeben werden. Natürlich sollen die Variablen in der Funktion lokal sein. Die erstellte Funktion tut es auch mit Konstanten Parametereingaben. Wechselt man die Eingaben auf die RGB-Werte der Kamera, dann stehen die Variablen alle auf 0.

Nach Änderung der Variablen auf globale Variablen, kommen die Werte an. Aber das ist natürlich keine Lösung und führt zu anderen Problemen... (ist vielleicht ein Hinweis auf das eigentliche Thema?)

Siehe Anhang. Dort ist das rpp-File (.png Erweiterung bitte löschen)

Hinweise sind sehr willkommen.
Danke fürs Lesen und Grübeln,
Tom mit Mo

[vleeuwen]

There exist no functions in RoboPro, it is work flow with data flow for inter process synchronisation. It is not not imperative programming.
The workflow will enter and leave a subroutine.
A subroutine can start his own workflow process.
After leaving the subroutine, local variables lost their meaning.
The moment of data checking is what counts.
The workflow need to assign a value to a variable. On that moment the right data needs to be available.

Post an image of your subroutine please.
=======Google translate for what it is========================================
Es gibt keine Funktionen in RoboPro, es ist ein Workflow mit Datenfluss für die Synchronisation zwischen den Prozessen und es ist keine zwingende Programmierung erforderlich.
Der Workflow betritt und verlässt eine Unterroutine.
Nach dem Verlassen des Unterprogramms verloren lokale Variablen ihre Bedeutung.
Der Workflow muss einer Variablen einen Wert zuweisen.

Poste bitte ein Bild deiner Subroutine.

[fishfriend]

Hallo...
Es hört sich nach zwei Problemen an. Man könnte nun mit eine innere Variable mit einem anderen Namen versehen und dann beim Ausgang den Wert auf die eigentliche Variable übertragen. Aber ich denke man sollte das/die Problem(e) ansich lösen.
Wie schon vleeuwen schrieb, zeig mal dein Programm/Bild...
Mit freundlichen Grüßen
fishfriend
Holger Howey

[tttttom]

Hallo fishfreund und vieeuwen!

Danke für die Rückmeldung!!! WIr haben gerade noch mal versucht das Thema weiter einzugrenzen. Das folgende Programm zeigt das Problem:

min1.png (134.71 KiB) 3604 mal betrachtet

min2.png (117.37 KiB) 3604 mal betrachtet

Wir haben beim Eingrenzen auch gleich eine Lösung gefunden:

• Lokale Variablen in der "Funktion" weglassen.

• Keinen neuen Thread verwenden.

Hier die funktionierende Lösung:

min3.png (302.2 KiB) 3604 mal betrachtet

Und damit funktioniert dann auch unsere Zaubwürfelfarberkennung (hier noch nicht aktualisiert):

min4.png (203.29 KiB) 3604 mal betrachtet

Damit wäre das Thema erledigt. Ein Erklärung warum lokale Variablen in einer Subroutine keine Werte "annehmen" wollen wäre natürlich trotzdem spannend.

Grüße und nochmals Danke++
Tom und Mo

[vleeuwen]

It is work flow! When do you think that the local variable picks up his value?
The local variables do not exist when the value change in the main program.
You need to initialize the local value as step in your work flow.
Try this one:

Remove.JPG (51.84 KiB) 3574 mal betrachtet

[tttttom]

@vleeuwen: Yes, this is also a solution.

Also, if you use global variables instead of local ones, it works. And I think, this is irritating. Why does the global var get the value and the local one does not? In the following example, I pass a -7 and a 8 to the subroutine. The -7 is passed to a global var, the 8 is not being passed. Also the -7 is not pushed to the local var min_aus.

mixed.PNG (32.34 KiB) 3531 mal betrachtet

Regards!
Tom

[vleeuwen]

It is a workflow and not an imperative concept. This requires a different way of thinking. The mistake you are making is typical for people who have not yet fully understood the workflow with dataflow for inter-process synchronisation concept.

The global variable has already received its value somewhere, so this value is available within the subroutine.
However, the local variable does not exist until the subroutine is entered. But the workflow has not yet asked the environment for a value. And the environment has not yet been able to send a value to the local variable. You do that with the "assign" with the two "=" commands; with that you ask "what value is available at the input on that moment of asking".

Such problems also regularly arise when using on/off sensors.
The workflow should ask for a value, it is not an event concept.
In workflow there are no events!!!!!

The workflow element "command" is sending on that moment to existing variables only.
Global variables can change value anywhere, be aware of that. Using global variable can give side effects.
I your example, you don't see the change of the local value. This because the workflow left the subroutine directly after this action.
Put a timer delay just before that the workflow is leaving the subroutine!!!

[vleeuwen]

To study the effects in workflow you will need to delay the progression of the workflow:

Remove.JPG (60.73 KiB) 3517 mal betrachtet

Have fun with the workflow concept, is is very powerful and less complex than the lower level Python interpreter language.

[tttttom]

Thanks vleeuwen for your valuable help

For all who read this, please see the following examples. I hope this avoids irritation:

This is a simple way to show what the behaviour is:

Bild1.png (119.58 KiB) 3459 mal betrachtet

And if you cascade it you run into problems:

Bild2.png (114.52 KiB) 3459 mal betrachtet

The stack problem is because of the use of a global variable. So the solution is to avoid global variables and if local variables are needed, you have to push values explicitly to them like vleeuwen has shown.

So for me this thread is closed. Have a nice christmas time ...
Tom

[vleeuwen]

I your main is not a workflow process to start.
I don't think using global variables in subroutines within the workflow concept is the right way to fundamentally solve this kind of problem.
"Push" isn't the right word for what's really happening either. This is a misconception.
In workflow, it is always the workflow node (element) that initiates an action. In this case the command element "asks" for a value, which is not a "push" and send it to the next actif data flow elements.
Working with workflow is like using a foreign language. You have to start thinking, designing and reasoning in the associated concept.

The last example only shows the result and does not explain why this is happening.
And it is precisely this statement that is important in order to properly grasp the underlying concept and therefore also be able to design and code with it in a good way.

[vleeuwen]

I did some more tests.
Also to see what makes the different when there is no workflow process in the main.
And I try to reproduce your error message, which was not the case.
However it is not possible to add an rpp or zip to here.
For the zip with the rpp's, send me you e-mail address.

[vleeuwen]

Image of the 3 test programs about the behaviour of variables under workflow.
What does the workflow?
A mains need at least 1 workflow process.

Experimenten(RoboPro variables).jpg (100.75 KiB) 3349 mal betrachtet

The 3th main, without any workflow process does work nicely. No errors!
The 4 subroutines at the right are the same for all 3 main programs.

[vleeuwen]

I added a very nice 4th test main example.

Experimenten(RoboPro variables).jpg (120.32 KiB) 3312 mal betrachtet

[tttttom]

I reproduced the error on a Windows10-virtual machine:

Bild1.png (48.83 KiB) 3261 mal betrachtet

[vleeuwen]

The main problem in your example is the lack of a workflow process that controls the actions over time.
The double "pass" here is one workflow action.
It seems that the code underlying this action is being created simultaneously with some sort of recursion around the access to the global variable.
General: A subroutine is not really re-enterable.

When I split up it in two workflow actions, the data flow is working fine..

Experimenten(RoboPro variables)2.jpg (24.55 KiB) 3240 mal betrachtet

[MasterOfGizmo]

I reproduced the error on a Windows10-virtual machine:

Das sieht ja in der Tat nach einem Fehler in RoboPro aus. Das was Du da gebaut hast ist ja einfache Kombinatorik. Das sollte zu keinem Stack-Überlauf führen, solange Du keine Rekursionen baust. Aber das hast Du ja nicht, solange Du Deine Pass-Funktion nicht innerhalb der Pass-Funktion selbst verwendest.

Wenn man das wirklich nur über die Zeit bzw. über ein Register lösen kann, dann wäre das schade, denn das hieße, dass Deine Berechnung unnötig verlangsamt wird. Vielleicht wendest Du Dich an fischertechnik. Das wäre ja wieder ein Grund mehr, doch noch etwas Support für RoboPro zu leisten.

[vleeuwen]

I perform so more tests.
There is a recursion in the updating mechanisme of the global variables in both the subroutines.

[MasterOfGizmo]

There is a recursion in the updating mechanisme of the global variables in both the subroutines.

That's a bug, anyway and should be fixed.

[vleeuwen]

Semantically, placing multiple global variables (RoboPro) directly behind each other is useless and can even lead to errors. In terms of design, I wouldn't really want to see such constructions.
It remains to be seen whether this is a bug or whether it sometimes works well due to side effects

[MasterOfGizmo]

Semantically, placing multiple global variables (RoboPro) directly behind each other is useless and can even lead to errors. In terms of design, I wouldn't really want to see such constructions.

That's a continuous assignment. What's wrong with that? Ask fotoopa, he does that all the time in his FPGA designs.