Jump to content

FlyingDoc

Members
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    459

  • Benutzer seit

  • Letzter Besuch

 Inhaltstyp 

Posts erstellt von FlyingDoc

    Update RED Image auf aktuelle Debian Version + QT und OpenGL

    in Software, Programmierung und externe Tools

    Geschrieben

    Hab einen früheren Stand des Image eingespielt. Jetzt bekomme ich folgenede Meldungen. 

    sh-5.1# apt remove libegl1-mesa
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 xserver-xorg-core : Breaks: libgl1-mesa-dri (< 18.0.5) but 13.0.6-1+b2 is to be installed
                     Recommends: default-logind or
                                 logind
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
sh-5.1# apt remove libegl1-mesa-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'libegl1-mesa-dev' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 468 not upgraded.
sh-5.1#

    Es ist also nur noch  libegl1-mesa installiert.

    Update RED Image auf aktuelle Debian Version + QT und OpenGL

    in Software, Programmierung und externe Tools

    Geschrieben

    Das kommt dann als Ausgabe 

    sh-5.1# sudo apt remove libegl1-mesa
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libegl1-mesa-dev : Depends: libegl1-mesa (= 2:10.3.2-1) but it is not going to be installed
 libqt5gui5 : Depends: libegl1 but it is not going to be installed
 libqt5webkit5 : Depends: libegl1 but it is not going to be installed
 libwebkitgtk-1.0-0 : Depends: libegl1-mesa (>= 7.8.1) but it is not going to be installed or
                               libegl1-x11
                      Recommends: gstreamer1.0-plugins-base (>= 1.0.3) but it is not going to be installed
                      Recommends: gstreamer1.0-plugins-good but it is not going to be installed
 xserver-xorg-core : Depends: libegl1-mesa but it is not going to be installed or
                              libegl1 but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

     

    Update RED Image auf aktuelle Debian Version + QT und OpenGL

    in Software, Programmierung und externe Tools

    Geschrieben · bearbeitet von FlyingDoc

    Hallo. Nach langer Zeit habe ich mal wieder eine Frage.

    Mein HUD Projekt habe ich wieder aufleben lassen. Das Programm habe ich auf OpenGL umgestellt.

    Nun bin ich dabei das RED Image auf die aktuelle Debian Version anzuheben.

    Das Debian ist soweit fertig. Nur hapert es noch bei der QT Installation.

    Vielleicht könntet ihr mich hier unterstützen. Wenn ich QT instllieren möchte schmeisst er noch Fehler aus.

      

    sh-5.1# apt-get install qt5-default
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libqt5gui5 : Depends: libegl1 but it is not going to be installed
 libqt5webkit5 : Depends: libegl1 but it is not going to be installed
 qt5-default : Depends: qtbase5-dev but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

    Wenn ich nun apt --fix-broken install mache kommt folgende Meldung

      

    sh-5.1# apt --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  libegl1
The following NEW packages will be installed:
  libegl1
0 upgraded, 1 newly installed, 0 to remove and 423 not upgraded.
103 not fully installed or removed.
Need to get 0 B/29.5 kB of archives.
After this operation, 76.8 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 195335 files and directories currently installed.)
Preparing to unpack .../libegl1_1.3.2-1_armhf.deb ...
Unpacking libegl1:armhf (1.3.2-1) ...
dpkg: error processing archive /var/cache/apt/archives/libegl1_1.3.2-1_armhf.deb (--unpack):
 trying to overwrite '/usr/lib/arm-linux-gnueabihf/libEGL.so.1', which is also in package libegl1-mesa 2:10.3.2-1
Errors were encountered while processing:
 /var/cache/apt/archives/libegl1_1.3.2-1_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

    Da ich nun noch lange kein Linux Spezi bin frage ich ob mir jemand hilfreich unter die Arme greifen kann.

    Das Programm an sich ist zu 60 % fertig und alle Anzeigen und Menüs laufen.

    Ausserdem will ich versuchen die den Desktop nicht zu laden sondern das ganze ohne diesen laufen zu lassen. Dazu müsste ich nur noch rausfinden welche Bibliothek ich dazu laden muss. Die Umstellung auf OpenGL hat ja schon am PC logischer weise zur massiven Leistungssteigerung geführt.

     

    An der Optik tüftle ich noch. Das Bild muss ja im Focus auf unendlich gestellt werden. So ist es zumindestens bei den HUD in den Militärmaschinen.

    AUssage von jemanden der da öfters mitfliegt. 😏

    Ich muss mir noch die Linsen für ein Kollimator Modul besorgen, das die Lichstrahlen parralel zueinander ausrichtet und dadurch den Focus auf Uendlich ausrichtet.

    Verbindungsprobleme mit dem Brick Daemon unter Win10

    in Software, Programmierung und externe Tools

    Geschrieben

    Neue Version getestet.

    Ergebnis. Hab den Angeschlossenen IMU nicht gesehen. War einzeln angesteckt und sonst nichts.

    Nach dem ich den Deamon neu gestartet habe war der IMU in der Liste zu sehen und hat funktioniert.

    Das Log ist aber nicht exorbitand geswachsen. 

    2019-12-20 22:40:17.187668 <I> <main_winapi.c:388> Brick Daemon 2.4.1+fd1 started (as service)
2019-12-20 22:40:17.189340 <W> <main_winapi.c:396> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details
2019-12-20 22:40:19.465268 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB
2019-12-20 22:40:19.467268 <I> <libusb:windows_init> UsbDk backend is not available
2019-12-20 22:49:26.088046 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp]
2019-12-20 22:49:27.245592 <I> <network.c:304> Added new client (N: 127.0.0.1:50029, T: plain-socket, H: 940/940, B: 0, P: 0, A: disabled)
2019-12-20 22:49:35.551313 <I> <client.c:252> Client (N: 127.0.0.1:50029, T: plain-socket, H: 940/940, B: 0, P: 0, A: disabled) disconnected by peer
2019-12-20 22:49:39.023099 <I> <usb.c:414> Removing USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp]
2019-12-21 00:51:20.674954 <E> <event_winapi.c:268> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-21 00:51:20.675353 <E> <event.c:539> Event loop aborted
2019-12-21 00:51:20.676987 <I> <main_winapi.c:501> Brick Daemon 2.4.1+fd1 stopped
2019-12-21 23:07:30.674533 <I> <main_winapi.c:388> Brick Daemon 2.4.1+fd1 started (as service)
2019-12-21 23:07:30.675699 <W> <main_winapi.c:396> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details
2019-12-21 23:07:30.686123 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB
2019-12-21 23:07:30.687530 <I> <libusb:windows_init> UsbDk backend is not available
2019-12-21 23:07:30.727582 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp]
2019-12-21 23:07:34.647431 <I> <network.c:304> Added new client (N: 127.0.0.1:51074, T: plain-socket, H: 936/936, B: 0, P: 0, A: disabled)
2019-12-21 23:07:38.880840 <I> <client.c:252> Client (N: 127.0.0.1:51074, T: plain-socket, H: 936/936, B: 0, P: 0, A: disabled) disconnected by peer
2019-12-21 23:08:49.093330 <I> <network.c:304> Added new client (N: 127.0.0.1:51215, T: plain-socket, H: 952/952, B: 0, P: 0, A: disabled)
2019-12-21 23:08:57.386102 <I> <client.c:252> Client (N: 127.0.0.1:51215, T: plain-socket, H: 952/952, B: 0, P: 0, A: disabled) disconnected by peer
2019-12-22 00:06:13.795580 <I> <usb.c:414> Removing USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp]
2019-12-22 02:07:39.397166 <E> <event_winapi.c:268> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-22 02:07:39.397829 <E> <event.c:539> Event loop aborted
2019-12-22 02:07:39.399960 <I> <main_winapi.c:501> Brick Daemon 2.4.1+fd1 stopped
2019-12-22 23:06:32.050797 <I> <main_winapi.c:388> Brick Daemon 2.4.1+fd1 started (as service)
2019-12-22 23:06:32.052312 <W> <main_winapi.c:396> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details
2019-12-22 23:06:32.065926 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB
2019-12-22 23:06:32.067303 <I> <libusb:windows_init> UsbDk backend is not available
2019-12-22 23:06:32.106933 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp]
2019-12-22 23:06:35.404747 <I> <network.c:304> Added new client (N: 127.0.0.1:53396, T: plain-socket, H: 948/948, B: 0, P: 0, A: disabled)
2019-12-22 23:07:22.462057 <I> <usb.c:414> Removing USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp]
2019-12-22 23:08:19.440094 <I> <client.c:252> Client (N: 127.0.0.1:53396, T: plain-socket, H: 948/948, B: 0, P: 0, A: disabled) disconnected by peer
2019-12-23 21:06:26.097493 <E> <usb_winapi.c:119> Could not write to notification pipe: WSAECONNABORTED (71010053)
2019-12-23 21:06:26.100215 <E> <usb_winapi.c:119> Could not write to notification pipe: WSAECONNABORTED (71010053)
2019-12-23 21:06:58.502323 <I> <network.c:304> Added new client (N: 127.0.0.1:54934, T: plain-socket, H: 896/896, B: 0, P: 0, A: disabled)
2019-12-23 21:07:14.821635 <I> <client.c:252> Client (N: 127.0.0.1:54934, T: plain-socket, H: 896/896, B: 0, P: 0, A: disabled) disconnected by peer
2019-12-23 21:07:16.057508 <I> <network.c:304> Added new client (N: 127.0.0.1:54938, T: plain-socket, H: 952/952, B: 0, P: 0, A: disabled)
2019-12-23 21:07:20.838120 <I> <main_winapi.c:211> Received stop command
2019-12-23 21:07:26.060894 <I> <main_winapi.c:501> Brick Daemon 2.4.1+fd1 stopped
2019-12-23 21:24:48.974478 <I> <main_winapi.c:388> Brick Daemon 2.4.1+fd1 started (as service)
2019-12-23 21:24:48.975639 <W> <main_winapi.c:396> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details
2019-12-23 21:24:48.991629 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB
2019-12-23 21:24:48.993204 <I> <libusb:windows_init> UsbDk backend is not available
2019-12-23 21:24:49.036225 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp]
2019-12-23 21:24:49.185194 <I> <network.c:304> Added new client (N: 127.0.0.1:57447, T: plain-socket, H: 972/972, B: 0, P: 0, A: disabled)
2019-12-23 21:24:51.315636 <I> <client.c:252> Client (N: 127.0.0.1:57447, T: plain-socket, H: 972/972, B: 0, P: 0, A: disabled) disconnected by peer
2019-12-23 21:24:53.125924 <I> <network.c:304> Added new client (N: 127.0.0.1:57457, T: plain-socket, H: 984/984, B: 0, P: 0, A: disabled)

     

    Verbindungsprobleme mit dem Brick Daemon unter Win10

    in Software, Programmierung und externe Tools

    Geschrieben

    Ich habe die  Version getestet. Geht nicht. Innerhalb von ein paar Minuten war das Log von 0 auf 244 MB angestiegen.

    Ich habe mal die ständig kommenden Einträge minimiert. Es ist immer der selbe. Deswegen die Sternchen.

      

    2019-12-16 22:38:06.442993 <I> <main_winapi.c:376> Brick Daemon 2.4.1 started (as service)
2019-12-16 22:38:06.444293 <W> <main_winapi.c:384> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details
2019-12-16 22:38:06.460943 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB
2019-12-16 22:38:06.462639 <I> <libusb:windows_init> UsbDk backend is not available
2019-12-16 22:38:06.518538 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp]
2019-12-16 22:38:11.020795 <I> <network.c:304> Added new client (N: 127.0.0.1:62490, T: plain-socket, H: 956/956, B: 0, P: 0, A: disabled)
2019-12-17 00:19:17.431758 <I> <client.c:252> Client (N: 127.0.0.1:62490, T: plain-socket, H: 956/956, B: 0, P: 0, A: disabled) disconnected by peer
2019-12-17 22:46:23.991284 <E> <event_winapi.c:228> Could not write to USB ready pipe: WSAECONNABORTED (71010053)
2019-12-17 22:47:26.695720 <I> <network.c:304> Added new client (N: 127.0.0.1:64583, T: plain-socket, H: 972/972, B: 0, P: 0, A: disabled)
2019-12-17 22:47:26.710409 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710460 <E> <usb_transfer.c:300> Could not submit write transfer 017785A8 (handle: 0177C7B0, submission: 13) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.710524 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710546 <E> <usb_transfer.c:300> Could not submit write transfer 017789C4 (handle: 0177C880, submission: 14) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.710618 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710643 <E> <usb_transfer.c:300> Could not submit write transfer 01778DE0 (handle: 0177C950, submission: 15) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.710687 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710706 <E> <usb_transfer.c:300> Could not submit write transfer 017791FC (handle: 0177CA20, submission: 16) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.710745 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710763 <E> <usb_transfer.c:300> Could not submit write transfer 01779618 (handle: 0177CAF0, submission: 17) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.710801 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710821 <E> <usb_transfer.c:300> Could not submit write transfer 01779A34 (handle: 0177CBC0, submission: 18) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.710856 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710874 <E> <usb_transfer.c:300> Could not submit write transfer 01779E50 (handle: 0177CC90, submission: 19) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.710908 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710926 <E> <usb_transfer.c:300> Could not submit write transfer 0177A26C (handle: 0177CD88, submission: 20) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.710965 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.710983 <E> <usb_transfer.c:300> Could not submit write transfer 0177A688 (handle: 0177D268, submission: 21) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:26.711043 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht.
2019-12-17 22:47:26.711076 <E> <usb_transfer.c:300> Could not submit write transfer 0177AAA4 (handle: 0177CF28, submission: 22) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1)
2019-12-17 22:47:38.064350 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:47:38.064393 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:47:38.064411 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:47:38.064426 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:47:38.064440 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:47:38.064454 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:47:38.064468 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:47:38.064482 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
*
*
*
*
2019-12-17 22:48:11.770978 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771162 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771193 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771212 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771226 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771240 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771254 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771268 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771282 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771296 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771301 <I> <main_winapi.c:209> Received stop command
2019-12-17 22:48:11.771310 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-12-17 22:48:11.771796 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01773818 (handle: 01770CD0, submission: 12) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.771828 <W> <usb_transfer.c:243> Leaking pending read transfer 01773818 (handle: 01770CD0, submission: 12) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.771853 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01773C34 (handle: 01770DA0, submission: 2) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.771870 <W> <usb_transfer.c:243> Leaking pending read transfer 01773C34 (handle: 01770DA0, submission: 2) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.771888 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01774050 (handle: 01770E70, submission: 3) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.771913 <W> <usb_transfer.c:243> Leaking pending read transfer 01774050 (handle: 01770E70, submission: 3) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.771930 <W> <usb_transfer.c:208> Could not cancel pending read transfer 0177446C (handle: 01770F80, submission: 4) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.771954 <W> <usb_transfer.c:243> Leaking pending read transfer 0177446C (handle: 01770F80, submission: 4) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.771970 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01774888 (handle: 017704A0, submission: 5) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.771980 <W> <usb_transfer.c:243> Leaking pending read transfer 01774888 (handle: 017704A0, submission: 5) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.771993 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01774CA4 (handle: 01770570, submission: 6) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.772004 <W> <usb_transfer.c:243> Leaking pending read transfer 01774CA4 (handle: 01770570, submission: 6) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.772016 <W> <usb_transfer.c:208> Could not cancel pending read transfer 017750C0 (handle: 01777A20, submission: 7) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.772026 <W> <usb_transfer.c:243> Leaking pending read transfer 017750C0 (handle: 01777A20, submission: 7) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.772040 <W> <usb_transfer.c:208> Could not cancel pending read transfer 017754DC (handle: 01777B30, submission: 8) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.772052 <W> <usb_transfer.c:243> Leaking pending read transfer 017754DC (handle: 01777B30, submission: 8) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.772064 <W> <usb_transfer.c:208> Could not cancel pending read transfer 017758F8 (handle: 01777C40, submission: 9) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.772087 <W> <usb_transfer.c:243> Leaking pending read transfer 017758F8 (handle: 01777C40, submission: 9) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.772115 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01775D14 (handle: 01778518, submission: 10) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5)
2019-12-17 22:48:11.772134 <W> <usb_transfer.c:243> Leaking pending read transfer 01775D14 (handle: 01778518, submission: 10) for IMU Brick 2.0 [6wVmVp]
2019-12-17 22:48:11.772454 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772476 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772488 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772498 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772509 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772519 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772530 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772539 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772550 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772574 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772584 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772594 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772604 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772614 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772625 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772635 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772646 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772656 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772666 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know
2019-12-17 22:48:11.772676 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle
2019-12-17 22:48:11.772771 <W> <libusb:libusb_exit> some libusb_devices were leaked
2019-12-17 22:48:11.774399 <I> <main_winapi.c:489> Brick Daemon 2.4.1 stopped

     

    Verbindungsprobleme mit dem Brick Daemon unter Win10

    in Software, Programmierung und externe Tools

    Geschrieben

    Hallo TF Team.

    Ich wollte es schon ewig melden, habe es aber lange verpasst, da ich arbeitsmäßig und familiär ziemlich gebunden bin im Moment.

    Bei meinem Laptop habe ich folgendes Phänomen.

    Beim Start von Win 10 kann der Daemon keine Verbindung aufbauen.

    Ich habe heute mal in die Log geschaut warum und  habe folgendes gefunden.

     

    2019-08-22 21:51:08.044366 <E> <event_winapi.c:228> Could not write to USB ready pipe: WSAECONNABORTED (71010053)
2019-08-22 21:52:09.341898 <I> <log_winapi.c:173> Log Viewer connected to info pipe
2019-08-22 21:52:23.436638 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)

     

    Die Verbindung funktioniert erst, wenn ich den Daemon Dienst neu starte.

     

    2019-08-22 21:53:48.196921 <I> <main_winapi.c:209> Received stop command
2019-08-22 21:53:48.196922 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-08-22 21:53:48.197252 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-08-22 21:53:48.197274 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-08-22 21:53:48.197308 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054)
2019-08-22 21:53:48.200701 <I> <main_winapi.c:489> Brick Daemon 2.4.0 stopped
2019-08-22 21:53:49.534941 <I> <main_winapi.c:376> Brick Daemon 2.4.0 started (as service)
2019-08-22 21:53:49.555603 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB
2019-08-22 21:53:49.556743 <I> <libusb:windows_init> UsbDk backend is not available
2019-08-22 21:53:49.596024 <I> <usb.c:194> Added USB device (bus: 1, device: 4) at index 0: IMU Brick 2.0 [6wVmVp]
2019-08-22 21:53:49.941343 <I> <log_winapi.c:173> Log Viewer connected to info pipe

     

    Ich vermute mal, das mein Rechner einfach zu schnell startet und etwas noch nicht geladen ist was der Daemon beim USB benötigt.

     

    Vom Start bis zum Login Screen sind es rund 10 Sekunden.

    Vielleicht kann man das Problem ja beheben in dem man vor dem Verbindungsversuch testet ob die benötigte Treiberkomponente schon im Windows geladen ist. :o

     

    P.s.

    Könntet iht die Länge des Logfile begrenzen. Mir hat der Daemon meine Platte mit dem Logfile völlig vollgeschrieben.

    Also alles wenn eine bestimmte Größe erreicht ist die ältesten Beiträge abschneiden.

    Das waren dann mehrere GByte. ( Kein Scherz)

    Und da hatte ich nur eine 256 GByte Systemplatte.

    Jetzt 1 TByte. ;D

    Er Protokolliert ja alles. Und wenn jede Sekunde ein Fehlereintrag kommt geht das ratz fatz. ;D

    Ich habe mich gewundert warum meine Systemplatte irgend wann bis auf das letzte Byte gefüllt war.

    Da schliesst man ja nicht sofort drauf.

     

    Start RED Brick

    in Anfängerfragen und FAQ

    Geschrieben

    Das das Feld auf Disconnect wechselt hat noch nichts mit der Verbindung zum RED zu tun.

    Das bedeutet einfach nur das du zum lokalem Brickdemaon Verbindung hast.

     

    So. Weiter.

     

    1. Hast du im Red schon die SD Karte mit dem IMG ( also quasi die Festplatte mit Betriebssystem)

    2. Wenn der RED an ist, müsste die Grüne LED auf dem RED blinken.

    Das zeigt an das dir Deamon auf dem RED läuft. Sonst siehst du ihn nicht im Brick Viewer!

    Auch wenn der RED läuft.

    Industrial Digital In 4 Bricklet 2.0 Callback funktioniert nicht

    in Software, Programmierung und externe Tools

    Geschrieben

    Ich arbeite gerade an beiden Varianten.

    Mit neuem Image (da muß ich aber noch viel anpassen) und mit dem Versuch den Daemon zu aktualisieren.

     

    Dabei kommt folgender Fehler.

    2019-01-14 17:33:21.309458 <I> <main_linux.c:291> Brick Daemon 2.3.2+redbrick started (pid: 2023, daemonized: 0)

    brickd: symbol lookup error: brickd: undefined symbol: libusb_free_pollfds

     

    Ich habe den Daemon nach eurer Anleitung mit

    # On RED Brick

    wget http://download.tinkerforge.com/tools/brickd/linux/brickd_linux_latest+redbrick_armhf.deb

    sudo dpkg -i brickd_linux_latest+redbrick_armhf.deb

     

    aktualisisert. Der Daemon startet aber wie schon beschrieben nicht.

     

    Industrial Digital In 4 Bricklet 2.0 Callback funktioniert nicht

    in Software, Programmierung und externe Tools

    Geschrieben

    Hallo TF Team.

    Erst einmal ein gesundes und erfolgreiches Jahr 2019!

     

    Ich habe folgendes Problem.

    Ich hab die IDI4 V2 in mein Programm eingebunden und bekomme den Callback nicht zum laufen.

    Ich benutze die aktuellen Bindings. DIe Firmware ist auch aktuell.

    Fehler werden nicht produziert.

    Der Callback wird aber nicht ausgelöst.

     

    Ich habe dann den IDI im BrickViewer V2.3.16 angeschaut.

    Dort werden die Eingänge ebenfalls nicht angezeigt!

    Egal welchen Zustand sie haben. Die Eingangs LED der DI zeigen aber den jeweiligen Zustand korrekt an.

    Was mache ich falsch?

     

    Das Programm ist in C++ geschrieben.

     

    Stapel.jpg.837a6047169b7b7634e8ff06f1e127fa.jpg

    BrickDaemon startet nicht...

    in Allgemeine Diskussionen

    Geschrieben

    Das ist ein nur bei Windows 10 auftretender Fehler.

    Der Deamon selber läuft schon. Kann aber den virtuellen Port nicht zur Verfügung stellen.

    Es hilft nach dem Windows Start den Dienst einfach mal zu beenden und neu zu starten. Irgend ein Dienst im System der gebraucht wird, startet zu spät.

    Zum Dienstneustart infach folgendes machen.

     

    Auf dem Desktop mit der Maus auf das Computericon für den PC gehen

    -> rechte Maustaste

    -> Verwalten anwählen

    -> Punkt Dienste und Anwendungen -> Dienst auswählen

    In der Dienstiste den Brickdeamon suchen und anklicken

    -> Oben in der Symbolleiste das Symbol |> (für Dienst neu starten) anklicken

    Der Dienst wird dann beendet und neu gestartet.

    Dannach funktioniert alles wie gewünscht.

    Reihenfolger der ipcon.EnumerateCallback

    in Software, Programmierung und externe Tools

    Geschrieben

    Allerding funktioniert die Funktion nicht solllage wie alle Enumerate Callbacks ausgelöst nicht wurden.

     

    Das habe ich ganz einfach gelöst.

    Ich habe einen Timer der bei einem EnumerateCallback gestartet wird.

    Dieser läuft als Singel Shot. Jedesmal wenn ein EnumerateCallback kommt, wird er wieder angeschubst. Das Timout ist so groß gewählt, das der Timer sein Callback erst auslösen kann wenn kein EnumerateCallback  mehr eintrifft. Dann wird die Sortierfunktion ausgelöst.

    Mit der Zeit musst du dann experimentieren. All zu groß muss sie aber nicht sein. Alles im Bereich von msec. ;)

    Reihenfolger der ipcon.EnumerateCallback

    in Software, Programmierung und externe Tools

    Geschrieben

    Doch. Das kann man sehrwohl.

     

    Ich baue meine Programme so auf.

     

    Der Callback gibt ja die Position (char position) zurück und wenn es ein Bricklet ist an welchem Master (char *connected_uid) es verbunden ist.

     

    void cb_enumerate(const char *uid, const char *connected_uid, char position, uint8_t hardware_version[3], uint8_t firmware_version[3], uint16_t device_identifier, uint8_t enumeration_type, void *user_data)

     

    Ich sammle alles in einer Tabelle und sortiere dann zum Schluß.

    Die RS232 oder RS485 bekommen bei mir der Reihenfolge nach einen Namen verpasst.

    COM1 , COM2 .......

    So spreche ich sie dann auch an.

    Genau so verfahre ich mit allen Bricklet.

    Aus den Eingängen wird dann DI0 DI1 DI........ Ausgängen DO0 DO1 DO......

     

    Mir ist egal an welchem Master diese hängen. Wichtig ist nur die Reihenfolge.

    Also z.B. Der erste DI der gefunden wird ist DI0. Egal an welchem Master im Stack.

    Wobei ich beim ersten Master anfange zu sortieren.

    Wo die Master im Stack hängen bekommt man beim Callback mitgeteilt.

     

    Der Callback empfängt sieben Parameter:

     

        uid: Die UID des Bricks/Bricklets.

        connected_uid: Die UID des Bricks mit dem das Brick/Bricklet verbunden ist. Für ein Bricklet ist dies die UID des Bricks mit dem es verbunden ist. Für einen Brick ist es die UID des untersten Master Bricks in einem Stapel. Der unterste Master Brick hat die Connected-UID "0". Mit diesen Informationen sollte es möglich sein die komplette Netzwerktopologie zu rekonstruieren.

        position: Für Bricks: '0' - '8' (Position in Stapel). Für Bricklets: 'a' - 'd' (Position an Brick).

        hardware_version: Major, Minor und Release Nummer der Hardwareversion.

        firmware_version: Major, Minor und Release Nummer der Firmwareversion.

        device_identifier: Eine Zahl, welche den Brick/Bricklet repräsentiert.

        enumeration_type: Art der Enumerierung

×
×
  • Neu erstellen...