Programmierung des TXControllers ohne RoboPro

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
Benutzeravatar
hefeteig
Beiträge: 56
Registriert: 01 Nov 2010, 15:17

Programmierung des TXControllers ohne RoboPro

Beitrag von hefeteig » 15 Jul 2013, 11:57

Hallo,
ich mache mir seit längerer Zeit Gedanken darüber, wie ich den TXController ohne RoboPro, sondern mit den Funktionen die mir die ftlib.dll bereitstellt programmieren kann.
Es geht mir dabei um den Aufbau eines solchen Programmes und nicht um die Umsetzung (dies ist ein Fall für sich).
Wie würdet ihr z.B. so etwas wie Prozesse bei RoboPro realisieren, ohne dass das ganze Programm blockiert.:?:
Phseudocode:

Code: Alles auswählen

solange I1.Tasterstatus ungleich gedrückt
    tue garnichts
ende solange 
SetOutMotorValues (hd,0,0,130,0)
Arbeitet ihr mit Events z.B. OnClick Event eines Tasters?

Wenn man mit der ftlib programmiert hat man viele Möglichkeiten den TXController anzusteuern, allerdings habe ich feststellen müssen,
dass es sehr komplex ist Dinge die in RoboPro selbstverständlich sind selbst umzusetzen.
Ich würde mich deshalb sehr freuen, wenn sich jemand finden würde, mit dem man Ideen dazu austauschen könnte.

Gruß Hefeteig

Ad2
Beiträge: 306
Registriert: 31 Okt 2010, 22:20

Re: Programmierung des TXControllers ohne RoboPro

Beitrag von Ad2 » 15 Jul 2013, 15:40

Hi,

I hope you read English. Programming a TX in online mode (i.e. the program is running on the PC) is not difficult and not that much different from other PC programming. For the TX you need the ftMsclib which resembles the ftlib but has some important differences. Both have the concept of a transferarea and a transfer thread. The idea is that the PC and the controller have a copy of the transferArea and the transferThread copies them back and forth. In the ftlib the use of the transferArea was essential, in the ftMscLib the use of function calls has eliminated the need for direct access to the transferArea. For instance advanced motor control is difficult to use by directly manipulating the transferArea. The transferThread of the ftlib had several notification mechanisms (callbacks for messages and transfers, events and windows messages). Using e.g. windows messages, a windows program could handle the arrival of a new copy of the transferArea in the same way it would handle a button message, namely in the main windows message loop, this provided a kind of 'tick' to the program. The ftMscLib does not have this mechanism anymore, instead it has callbacks on some specific events but not on the change of a TX input. So the only way to know whether in input has changed is to poll the input by means of the GetInIOValue function or the corresponding value in the transferArea.
The best implementation of the polling loop depends on platform. In e.g. Delphi it may be different than in a console application. You may use multithreading but that will create its own problems. The best strategy is usually to have a single loop that never blocks, you check an input and if there is something to do you take action, if not you continue with the loop. This usually means that you have to explicitly maintain a 'state'. Let's assume you want to detect the press of a button, you could have a loop waiting for the input to become low followed by a loop waiting for the input to become high before you take action. Such program will block twice before doing anything. A much better approach is to use a state variable, the state represents in this case the previous value of the input. Now if the 'state' is low and the input is high you have a button press and you take action otherwise you just continue with your other tasks (don't forget to copy the input to the 'state'). The program never blocks so it will remain responsive to other events.
Hope this helps

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Programmierung des TXControllers ohne RoboPro

Beitrag von vleeuwen » 16 Jul 2013, 09:44

In addition to Ad his contribution.

The FtTxService (available in the fischertechnik download area) for MS-RDS 4 knows already the concept of Notifications (kind of events) for sensor state changes (I1..I8 and C1..C4).

Benutzeravatar
hefeteig
Beiträge: 56
Registriert: 01 Nov 2010, 15:17

Re: Programmierung des TXControllers ohne RoboPro

Beitrag von hefeteig » 27 Jul 2013, 20:28

Hello,
Polling is also my procedure, but I am not very happy with that.
My idea was a polling loop, but also some threads (like processes in RoboPro).
The problem is clear: ftMscLib is not really build for multithreading programms.
So, my idea was to start a single thread in the polling loop of the main thread but the main thread waits until the single thread had checked for example if I2 is pressed.
After that it does the same thing with the other threads.
The result is a program, that consists of multiple threads, but this threads are not running at the same time.

What do you think about my idea?

MFG
Hefeteig

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Programmierung des TXControllers ohne RoboPro

Beitrag von vleeuwen » 31 Jul 2013, 01:40

Real Concurrency is part of MS Robotics Developer Studio.
This is more than multi threading.
The generation of the sensor notification is done by a Multi media-thread and dispatched to different processes (thread, different cores or even different processors).
Because of the leak of events (callbacks) in the FtMscLib, the generation of the events is done by polling for the moment.
These events are generating different threads (processes).

Antworten