uwew

Ja: /*! * @file cltf128x64.h * @brief Declaration of the LCD128x64-class WIT QObject * @date 2024-11-03 * @version 00 */ #ifndef CLTF128X64_H #define CLTF128X64_H #include "ip_connection.h" #include "bricklet_lcd_128x64.h" #include <QObject> //brauchen wir für "QT_BEGIN_NAMESPACE" #ifdef __cplusplus extern "C" { #endif /** * \defgroup cltf128x64 Klasse für TF-Steuerung */ /*! * \ingroup cltf128x64 * @brief Nothing special.\n */ #define UID_LCD128X64 "R3t" /*! * \ingroup cltf128x64 * @brief Nothing special.\n */ #define HOST "localhost" /*! * \ingroup cltf128x64 * @brief Nothing special.\n */ #define PORT 4223 QT_BEGIN_NAMESPACE namespace Ui { class cltf128x64; } QT_END_NAMESPACE class cltf128x64 { Q_OBJECT /******************************************************************************/ public: /*! * \ingroup cltf128x64 * .h: Constructor of the class "cltf128x64"\n * Nothing special.\n * @brief Constructor of the class "cltf128x64" */ cltf128x64(); /*! * \ingroup cltf128x64 * Destructor of the class "cltf128x64"\n * Nothing special.\n * @brief Destructor of the class "cltf128x64" */ ~cltf128x64(); public slots: /*! * \ingroup cltf128x64 * @brief function SetOnLCD128x64() * Initializes the LCD128x64 and register the callbacks * */ void SetOnLCD128x64(); /******************************************************************************/ private:

Ich habe eine Klasse in Qt mit dem Creator erstellt. der Aufruf der Funktion "SetOnLCD128x64()" funktioniert problemlos. Beim Connect-Befehl klappt es leider nicht. cltf128x64* cl_lcd = new cltf128x64(); // cltf128x64 ist in separater Header und Sourcecode-Datei deklariert/definiert cl_lcd->SetOnLCD128x64(); // funktioniert connect(ui->pBuLCD2SetOn, &QPushButton::clicked, &cl_lcd, &cltf128x64::SetOnLCD128x64); // verursacht Fehler die Fehlermeldung: uwMainWindow.cpp:40:5: No matching member function for call to 'connect' qobject.h:200:36: candidate function not viable: no known conversion from 'void (QAbstractButton::*)(bool)' to 'const char *' for 2nd argument qobject.h:203:36: candidate function not viable: no known conversion from 'void (QAbstractButton::*)(bool)' to 'const QMetaMethod' for 2nd argument qobject.h:396:41: candidate function not viable: no known conversion from 'void (QAbstractButton::*)(bool)' to 'const char *' for 2nd argument qobject.h:221:9: candidate template ignored: substitution failure [with Func1 = void (QAbstractButton::*)(bool), Func2 = void (cltf128x64::*)()]: no type named 'ContextType' in 'QtPrivate::ContextTypeForFunctor<void (cltf128x64::*)()>' qobject.h:270:9: candidate function template not viable: requires 3 arguments, but 4 were provided Hat jemand eine Idee woran's hängt. Vielen Dank Uwe

Also die Rückgabe-Werte der int-Funktionen (IPConnect, write und set_response) sind alle 0. Auf wundersame Weise funktioniert es jetzt - ich hab´s mehrmals probiert. Eine Ursache kann ich leider nicht erkennen. Ich probiere jetzt mal verschiedene Bricklets aus und melde mich gegebenenfalls wieder. erst mal vielen Dank

Lasse ich die destroy-funktion drin erhalte ich ebenfalls 0

Ich habe lcd_128x64_destroy auskommentiert. Rückgabewert von lcd128x64_write = 0

Folgendes habe ich noch vergessen: Ich verwende einen iMac, mit QT 6.7.1. Der Brickviewer erkennt das LCD128x64 und kann auch schreiben.

Hallo. Ich arbeite mich derzeit in die Verwendung von Tinkerforge-Modulen mit QtCreator ein. Gestartet bin ich mit dem LCD128x64. Dabei hänge ich an folgendem Problem fest: Der folgende Code (main.cpp) schreibt nur dann auf das LCD128x64, wenn ich vor dem write-Befehl den destroy-Befehl absetze! Woran könnte das liegen? Herzlichen Dank für eure Hilfe #include "startwindow.h" #include <QApplication> #include "ip_connection.h" #include "bricklet_lcd_128x64.h" #define HOST "localhost" #define PORT 4223 #define UID "24Pm" int main(int argc, char *argv[]) { // Neu IPConnection ipcon; ipcon_create(&ipcon); // Create device object LCD128x64 lcd; lcd_128x64_create(&lcd, UID, &ipcon); // Connect to brickd if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect\n"); return 1; } // Don't use device before ipcon is connected // Clear display lcd_128x64_clear_display(&lcd); lcd_128x64_destroy(&lcd); // Write "Hello World" starting from upper left corner of the screen lcd_128x64_write_line(&lcd, 0, 0, "Hellllllllllo World"); QApplication a(argc, argv); StartWindow w; w.show(); return a.exec(); }

Guten Morgen Jürgen. Vielen Dank für Deine Info. Ich habe zum Thema "Thread" mal ein Video (c++ Tutorial von Pilzschaf Nr. 68) angeschaut. Jetzt weiss ich so ungefähr, was man unter einem Thread versteht. Machen Threads auch beim "SingleCore"-Prozessor des RED-Bricks (Cortex A8) Sinn? Meinen aktuellen Source-Code habe ich mal als Datei angehängt. Das Programm compiliert fehlerfrei und läuft auch fehlerfrei. _P202007MS02_Dosiersystem.cpp. Allerdings tritt folgendes Problem auf: Wenn ich eine der Pumpen im Intervall-Betrieb (LCD-Button "Inter" auf dem angehängten Bild) starte, dann macht diese Pumpe genau das, was sie soll. Das LCD ist jedoch für weitere Eingaben blockiert. Erst nach einer unreprodzierbaren Zeitspanne, sind dann plötzlich Eingaben möglich. Die zugehörige Funktion: /** * Die folgende Funktion startet die Pumpe und macht die Anzahl Schritte, die übergeben wurde. * Die Motorsteps per second werden ebenfalls zuvor berechnet und übergeben. * Über die Callbackfunktion wird sie nach einer gewissen Zeit (Delay-Time) wieder aufgerufen. * */ void PumpMotorStartIntervalMode(PeristalticPump *DummyPump) { /* Anfang - Variablen lediglich zur Kontrolle und nicht für Betrieb */ uint16_t currVel; int32_t currPos; int32_t remainSteps; uint16_t stackVolt; uint16_t externVolt; uint16_t currConsumpt; char retPos; /* Ende Variablen zur Kontrolle */ uint16_t DosingFactor = 1; uint16_t MotorSpeedmLPerHour; uint16_t MotorSpeedStepsPerSecond; uint32_t NumberOfStepsPerHour; uint32_t NumberOfStepsPerDosingPeriod; uint8_t mode = STEPPER_STEP_MODE_EIGHTH_STEP; DosingFactor = (DummyPump->DosingIntervalTimeMinute_Value + DummyPump->DelayIntervalTimeMinute_Value) / DummyPump->DosingIntervalTimeMinute_Value; NumberOfStepsPerHour = PUMP_FULL_STEPS_PER_ROUND * mode * DummyPump->RoundsPer100mL / 100 * DummyPump->FlowMLPerHour_Value * DummyPump->CalibrationFactorPercent_Value / 100; NumberOfStepsPerDosingPeriod = NumberOfStepsPerHour * (DummyPump->DosingIntervalTimeMinute_Value + DummyPump->DelayIntervalTimeMinute_Value) / 60; MotorSpeedStepsPerSecond = NumberOfStepsPerHour / 3600 * DosingFactor; stepper_set_motor_current(DummyPump->pStepper, STEPPER_CURRENT); stepper_set_step_mode(DummyPump->pStepper, mode); stepper_set_max_velocity(DummyPump->pStepper, MotorSpeedStepsPerSecond); stepper_enable(DummyPump->pStepper); for (uint16_t i = 1; i < DosingFactor; ++i) { stepper_set_current_position(DummyPump->pStepper, 0); // stepper_drive_forward(DummyPump->pStepper); stepper_set_steps(DummyPump->pStepper, NumberOfStepsPerDosingPeriod); millisleep(DummyPump->DelayIntervalTimeMinute_Value * 6000); } // stepper_set_steps(DummyPump->pStepper, 5000); /** Kontrollausgabe zur Überprüfung am Bildschirm */ std::cout<< std::endl << "PumpMotorStartIntervalMode(PeristalticPump *DummyPump)\n"; sprintf(text03, "Dos: %2d\tDel: %2d\t DF: %2d\t Steps/h: %d\t Steps/Period: %d\t, Step/sec: %d", DummyPump->DosingIntervalTimeMinute_Value, DummyPump->DelayIntervalTimeMinute_Value, DosingFactor, NumberOfStepsPerHour, NumberOfStepsPerDosingPeriod, MotorSpeedStepsPerSecond); std::cout << "text03: " << text03 << std::endl; /* Ende Kontrollausgabe*/ } Vielleicht liegt die Ursache des Problems aber gar nicht in der Funktion selbst, sondern in den CallBack-Einstellungen in der main(): lcd_128x64_register_callback(&pLCD128x64, LCD_128X64_CALLBACK_GUI_TAB_SELECTED, (void (*)(void))cb_gui_tab_selected, &ActivePump ); lcd_128x64_register_callback(&pLCD128x64, LCD_128X64_CALLBACK_GUI_BUTTON_PRESSED, (void (*)(void))cb_gui_button_pressed01, &LCDTabIndex ); rotary_encoder_v2_register_callback(pump[0].pEncoder, ROTARY_ENCODER_V2_CALLBACK_COUNT, (void (*)(void))cb_InputEncoder, &pump[0]); rotary_encoder_v2_register_callback(pump[1].pEncoder, ROTARY_ENCODER_V2_CALLBACK_COUNT, (void (*)(void))cb_InputEncoder, &pump[1]); rotary_encoder_v2_register_callback(pump[2].pEncoder, ROTARY_ENCODER_V2_CALLBACK_COUNT, (void (*)(void))cb_InputEncoder, &pump[2]); rotary_encoder_v2_set_count_callback_configuration(pump[0].pEncoder, 200, true, 'x', 0, 0); rotary_encoder_v2_set_count_callback_configuration(pump[1].pEncoder, 200, true, 'x', 0, 0); rotary_encoder_v2_set_count_callback_configuration(pump[2].pEncoder, 200, true, 'x', 0, 0); lcd_128x64_set_gui_button_pressed_callback_configuration(&pLCD128x64, 300, true); lcd_128x64_set_gui_tab_selected_callback_configuration(&pLCD128x64, 300, true); Noch eine Anmerkung: Derzeit compiliere und starte ich das Programm noch auf einem Windows-PC mit Code::Blocks. Herzlichen Dank für weitere Tips im Voraus. Uwe

Hallo Markus. Vielen Dank für Deine Infos. Ich schau mir die Thread-Geschichte und das Projekt mal an. Gruss Uwe

Hallo Markus. Vielen Dank für Deine Rückmeldung. Das Problem ist, dass ich eigentlich noch Programmier-Anfänger bin. Was ich suche: Wenn das Dosiersystem gestartet ist, brauche ich für jede Pumpe einen Timer, der sagt "Dosiere jetzt x Min, danach pausiere bitte y min". Ich weiss, dass es eine sleep-Funktion gibt. Den Begriff "Thread" habe ich zwar schon gehört, hab mich aber bisher nicht damit beschäftigt. Mir fehlt im Moment die Idee, wie man solche Timer in C/C++ erstellt und in ein Programm einbindet (Stichwort Interrupt?) Grüsse Uwe

Hallo Ich habe ein Dosiersystem mit drei Peristaltikpumpen, gesteuert mit je einem Stepper Brick. Die Software ist in C/C++ geschrieben. Das Ganze funktioniert grundsätzlich. Bei folgender Problemstellung komme ich aber nicht weiter: Wenn die Dosiervolumina sehr klein sind, drehen sich die Motoren auch entsprechend langsam. Dann würde ich gerne auf Intervallbetrieb umstellen (d.h. 1 Minute dosieren, 9 Minuten Pause, 1 Minute dosieren, 9 Minuten ....). Hat jemand eine Idee, wie man das umsetzen kann? Zusatzinfo: Der TF-Stapel besteht aus Step-Down Power Supply, RED-Brick, 3 Stepper-Bricks, 3 Rotary Encoder 2.0 und 1 LCD128x64-Display. Ein Real Time Clock Bricklet wäre vorhanden ist aber bisher nicht integriert. Herzlichen Dank für eure Tips Uwe

Das Problem mit dem Encoder-Bricklet kriege ich jetzt durch die Warteschleife in den Griff und ich kann an meiner Dosierstation weiterarbeiten. Sollte ich dabei noch auf nützliche Informationen stossen, dann schreibe ich es hier ins Forum. Nochmals vielen Dank für die Unterstützung. Gruss Uwe

Problem Nr. 1 ist erledigt - ich habe die aktuelle Version des Brick-Viewers draufgespielt🙂. Zu Problem Nr. 2, Farbenspiel: Das Joy-It-Display ist vollflächig weiss, rot, grün, blau, dunkel im 2-sec-Abstand, wenn beim Einschalten das Joy-It-Display über den HDMI-Port mit dem RED-Brick verbunden und eingeschaltet ist. Trenne ich dann HDMI-Verbindung, so erscheint beim erneuten Einstecken des HDMI-Kabels der gewohnte TF-Desktop. Boote ich den RED-Brick über den grünen Kreis unten rechts auf dem Desktop, gelange ich zum erwähnten Farbenspiel. Starte ich den Brick-Viewer auf dem RED-Brick und führe ich dort einen Reboot durch komme ich zum gleichen Ergebnis. Abhilfe schafft nur das Trennen der Verbindung zwischen Joy-It und RED-Brick. .An dieser Stelle muss ich mal ein herzliches Dankeschön für die kompetente und schnelle Hilfestellung loswerden.

Guten Morgen. Vielen Dank für die Rückmeldungen. Zum Tipp mit dem Warten in der main(): Habe einfach eine for-Schleife mit printf("a") eingebaut. Mit dieser Schleife funktioniert es, d.h. das Programm reagiert auf den Encoder, auch wenn der RED-Brick nicht an einem Computer hängt. Welche Infos wären noch nützlich für die Ursachenforschung?

Danke für die Rückmeldung. Wenn ich das Programm vom PC aus starte dann liefert printf("return value: %d \n",rotary_encoder_v2_set_count_callback_configuration(&RotEnc01, 500, false, 'x', 0, 0)); auf der Console: "return value: 0" Im Brick Viewer Log hat es folgende Einträge drin: wobei "KcD" die UID meines Rotary Encoders 2.0 ist. Leider weiss ich nicht, wo der RED-Brick den printf-Befehl ausgibt. Deshalb habe den Wert auf dem LCD128x64 ausgeben lassen. Auch da liefert die Funktion den 0 als return-value, wenn ich das Dosiersystem ohne den PC starte. Ich hoffe, diese Infos bringen etwas Licht ins Dunkel. Dann habe ich noch zwei kleine Probleme: 1. Im Moment ist der RED-Brick nicht in der Lage das C/C++-Update durchzuführen. Er meldet zwar nach Ewigkeiten (>45 min) dass das Update erfolgreich war. Es ist aber nach wie vor Version 2.1.30 installiert. Suche ich dann erneut nach Updates, dann meldet er wieder, dass eine neue Version vorhanden ist. Das Spiel beginnt von vorn. 2. Wenn ich ein LCD-Display von Joy-It anschliesse (nur HDMI, nicht USB für touch), dann sehe das Farbenspiel, egal ob ich zuerst den Brick oder das Display einschalte. Erst wenn ich den HDMI-Anschluss trenne und neu verbinde, erscheint der Linux-Desktop und das blaue TF. Hat da jemand eine Idee? Gruss Uwe