• Content Count

  • Joined

  • Last visited

About Torfey

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you very much @attila You finding that mistake in my code, plus your path length patch, now has my code running with 3.7.19-2 on debian linux! Very mysterious why it ever worked which, of course, makes finding the problem that much harder. (And I thought I'd gone through every single dwf call looking for discrepancies from the docs!) I will pass along your suggestion about the trigger to my engineers. It does sound much simpler. Cheers and thanks again!
  2. Hi @attila Have tried 3.7.19-2. Seems to get past the startup trouble of 'stack smashing'. Thank you. However, now the scope never goes from 'arm' state to 'triggered'. Exact code works with 3.5.4. Will try some more tests to see if it's a startup timing issue. But if you have any ideas... Cheers.
  3. Thanks @attila I'm curious though. I understand you to be talking about path length to the files on the filesystem, yes? The executable I run has 19 chars for the python binary (/usr/bin/python2.7). It uses the standard installation libraries for debian python2.7 (/usr/lib/python2.7/dist-packages) for its import lines. I 'cd' to the dir where my .py files are. Then run /usr/bin/python2.7 The total length of the absolute path to is 34 chars. The is where the .deb file installs it, /usr/lib/ So I'm not seeing an obvious place going over 200 chars, but I might be misunderstanding you. I also don't know what 'bundle mode' is, but maybe for my purposes it doesn't matter. Is there a way I can rearrange my .py files to test whether a shorter path fixes it? I just tried moving to a short path of /p/p/ and still get 'stack smashing'. Cheers.
  4. Not sure if it's useful since I don't have full code or debug symbols, but running gdb and printing the backtrace I get: #0 0x00007ffff5c46688 in ?? () from /lib/x86_64-linux-gnu/ #1 0x00007ffff5c476f8 in _Unwind_Backtrace () from /lib/x86_64-linux-gnu/ #2 0x00007ffff6fe6526 in __GI___backtrace (array=<optimized out>, size=64) at ../sysdeps/x86_64/backtrace.c:109 #3 0x00007ffff6f10d62 in backtrace_and_maps (do_abort=0, [email protected]=2, written=false, fd=15) at ../sysdeps/unix/sysv/linux/libc_fatal.c:47 #4 0x00007ffff6f641af in __libc_message ([email protected]=2, [email protected]=0x7ffff7056cb3 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:172 #5 0x00007ffff6fe9aa7 in __GI___fortify_fail ([email protected]=0x7ffff7056c9b "stack smashing detected") at fortify_fail.c:31 #6 0x00007ffff6fe9a70 in __stack_chk_fail () at stack_chk_fail.c:28 #7 0x00007fffdbc59155 in DwfAttach() () from /usr/lib/ #8 0x6d7269662f736d72 in ?? () #9 0x2e2e2f2f65726177 in ?? () #10 0x642f65726168732f in ?? () #11 0x2f746e656c696769 in ?? () #12 0x6d726f6665766177 in ?? () #13 0x61776d7269662f73 in ?? () #14 0x696769642f2f6572 in ?? () #15 0x7661772f746e656c in ?? () #16 0x662f736d726f6665 in ?? () #17 0x2f657261776d7269 in ?? () #18 0x726f6c707845452f in ?? () #19 0x682e72746d567265 in ?? () #20 0x0000000000007865 in ?? () #21 0x0000000001595d10 in ?? () #22 0x00007ffff7deee38 in dl_open_worker (a=<error reading variable: Cannot access memory at address 0x6f66657661772f7c>) at dl-open.c:577
  5. Thanks @attila With 3.7.13 still getting *** stack smashing detected ***: /usr/bin/python2.7 terminated Segmentation fault I put back 3.5.4 and it works.
  6. I had a working Debian 8 production system using python2.7 to talk to an Analog Discovery 2. I decided to update the .deb packages to be current and now I get "Segmentation fault" "stack smashing detected" when I try to start my python program. I was using the amd64.deb files: digilent.adept.runtime 2.16.6 digilent.waveforms 3.5.4 (for the file) Upgraded to digilent.adept.runtime 2.17.1 digilent.waveforms 3.7.5 Also on the system is digilent.adept.utilities 2.2.1. I tested just upgrading the runtime package and my program works. Upgrading the waveforms package (and thus causes the segfault. Any thoughts on how I might track down where the problem is?
  7. Thanks. I was able to use the FDwfEnum and FDwfEnumSN calls to get the serial number of the devices and associate them with the idxDevice device index. Then, knowing from outside which serial number AD2 is wired where, can then look up that SN's index.
  8. I'm using two Analog Discovery 2's in an embedded Debian linux environment using the python interface with my own code. I need to be able to know which physical scope I'm connecting to when I open both scopes because even though the usb assignment might change, the wiring won't. So I need to know in software which scope is which. Can you suggest a way to choose which scope to connect to? Or, failing being able to know ahead of time, what's the easiest way to know which scope I've connected to and possibly close it and switch to the other? Thanks.
  9. Thank you. I hadn't seen in the docs that the return value of FDwfAnalogInConfigure was testable, so thanks for suggesting that. We call FDwfAnalogInConfigure with start=true, then loop on FDwfAnalogInStatus, waiting for 'done' state, but with a timeout of 2s (our external trigger runs at ~10 Hz). Code is modeled on samples/py/ In this loop is when I normally see the 'armed', 'triggered', and finally 'done'. When we have trouble, the system goes to 'ready' and stays there until it hits my 2s timeout . I've just now added a test of FDwfAnalogInConfigure's return value before I enter my loop, but in a short test, it appears the return value must equal 1, because I'm not getting the extra log messages I added if the 'return_value != 1'. So even though we're triggering 10x a second, we're not going to 'armed', etc, within my 2 second timeout window. Sometimes. Fwiw, over a 5 day test, average time till getting stuck on 'ready' was 40min. Shortest was 10s. Longest 4h. Not sure if it's related to load on the system causing usb timeouts. But the load is only background linux, x-windows, and drawing results of this data collection to screen on an Intel NUC i5.
  10. Working on Debian 8.6 in python 2.7, trying to figure out what the 'ready' state of the AD2 means and how I can get back to running mode. We configure the AD2 to run continuously, collecting multiple subtraces and combining them into a larger trace. The system happily runs, sometimes for hours or days, reporting states of 'arm', 'triggered', and 'done' repeatedly. But at some point with an unknown-to-me cause, it flips to a 'ready' state and our data collection stops. I don't know what FDwf python command to issue to get it back to triggering and taking data. As it is, I close and delete the python AnalogDiscovery object and create a new object, thus re-initializing our AD2 connection. But my guess is that I shouldn't have to do this to start up again. Can someone tell me to proper way to get back to taking data after getting bumped out to 'ready' state? Thanks.
  11. So maybe 'ulimit' is unrelated to threading.stack_size. threading.stack_size(512*1024) doesn't segfault (at least not immed), but I'm still getting bad data when initializing from one level down in subroutine.
  12. Thanks. The stack size on my linux seems to default to 8 KiB. I've done 'ulimit -s 32768' to allow a process in that shell to try to increase more than the default. But any call to threading.stack_size(32*1024) in my python leads to a segfault. I haven't tracked down yet who is segfaulting. This is on an Intel NUC i5 with 64bit debian linux and 16G RAM. I carefully went through all our calls from python to the C digilent library to make sure my variable types used in the calls matched what was declared in the dwf.h file. (ctypes.c_int() & ctypes.c_double() for example) but that made no difference to the strange behavior I get if push my initialization down one level into a subroutine instead of in _init_ of a class. Had hoped that a wrong type was subtly corrupting the stack. I haven't been able yet to confirm my hunch, but the bad raw data I get back after initializing from a subroutine 'appears' to be a first chunk of the trace then repeated two more times.
  13. We're using the 64 bit packages for Debian, writing our own python 2.7 code to access the provided AD2 library using 'ctypes' module. I'm trying to track down a tricky bug and wondering what the library was compiled with: C or C++ ? Is the dwf.h definition file exactly correct with regards to parameter types (char vs unsigned char Trying to see if the size of the parameters, ctypes.c_bool() vs ctypes.c_int(), e.g., matters. Or c_byte() vs c_ubyte(). Since afaik C doesn't have 'bool' type, knowing if this is a C++ library would help me decide. Similar inconsistencies: Example code snippet: /usr/share/digilent/waveforms/samples/py/ #TRIGSRC trigsrcNone = c_byte(0) trigsrcPC = c_byte(1) But dwf.h, that presumaly the library was compiled with: typedef unsigned char BYTE; typedef BYTE TRIGSRC; const TRIGSRC trigsrcNone = 0; const TRIGSRC trigsrcPC = 1; where my reference tells me 'c_ubyte' is what we should be using for 'unsigned char', not c_byte(). Going by the dwf.h file, I would not use the definition examples provided in, but change to c_ubyte(), for example. In the end, most of these probably won't matter, but the bug I'm chasing seems to involve corruption of the runtime stack (moving a FDwf call into a subroutine gives different behavior than calling it from one up), so I'm being paranoid about the ctypes interface since it's easy to make a mistake there. This on Debian 8.6 with installed: +++-=======================-================-================-=================================================== ii digilent.adept.runtime 2.16.5 amd64 Digilent Adept Runtime ii digilent.adept.utilitie 2.2.1 amd64 Digilent Adept Utilities ii digilent.waveforms 3.3.7 amd64 Digilent WaveForms Thanks much.
  14. I ended up ordering an Intel NUC NUC5i5RYH on Sept 8. Installed a fresh Debian 8.5 3.16.0-4-amd64 x86_64 (as opposed to the 'upgraded' 32bit os I was using on the old VersaLogic Iguana board). So far it seems to be working. In my hunting for a solution before, I came across posts (not about AD2, but, say, cameras) about people having problems with various usb chips. I didn't try to track any of that down. So it was a roll of the dice whether this NUC setup would work. I believe the NUC only has usb 3 ports. I chose the 5i5 instead of the newer 6i5 because I wasn't sure if the 'stable' Debian would support the newer video. I'm very frustrated with all my experience with usb attached devices. It always seems to be iffy and the suggested solution on other forums to 'unplug and replug' a device isn't very helpful when you're trying to write code that will take data uninterrupted for months at a time. On the other hand, all my work with ethernet connected devices has gone very well and been stable. I would really like it if the Digilent made the Analog Discovery 2 available with a native ethernet connection to it instead of just usb. For what it's worth, the messages I got on the fresh build on the Intel NUC are below. Note that here it's using the xhci_hcd driver vs the ehci_hcd driver on the previous board. My new system info: $ uname -a Linux deb-nuc5i5 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux Attach same Analog Discovery 2 to usb port. It was found by usb system and reported in /var/log/messages: Sep 13 11:56:50 deb-nuc5i5 kernel: [67138.510732] usb 1-2: new high-speed USB device number 5 using xhci_hcd Sep 13 11:56:50 deb-nuc5i5 kernel: [67138.643726] usb 1-2: New USB device found, idVendor=0403, idProduct=6014 Sep 13 11:56:50 deb-nuc5i5 kernel: [67138.643734] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Sep 13 11:56:50 deb-nuc5i5 kernel: [67138.643738] usb 1-2: Product: Digilent USB Device Sep 13 11:56:50 deb-nuc5i5 kernel: [67138.643742] usb 1-2: Manufacturer: Digilent Sep 13 11:56:50 deb-nuc5i5 kernel: [67138.643745] usb 1-2: SerialNumber: 210321A1A55D Sep 13 11:56:50 deb-nuc5i5 mtp-probe: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2" Sep 13 11:56:50 deb-nuc5i5 mtp-probe: bus: 1, device: 5 was not an MTP device Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.674342] usbcore: registered new interface driver usbserial Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.674353] usbcore: registered new interface driver usbserial_generic Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.674362] usbserial: USB Serial support registered for generic Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675541] usbcore: registered new interface driver ftdi_sio Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675564] usbserial: USB Serial support registered for FTDI USB Serial Device Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675642] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675668] usb 1-2: Detected FT232H Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675670] usb 1-2: Number of endpoints 2 Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675671] usb 1-2: Endpoint 1 MaxPacketSize 512 Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675672] usb 1-2: Endpoint 2 MaxPacketSize 512 Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675673] usb 1-2: Setting MaxPacketSize 512 Sep 13 11:56:51 deb-nuc5i5 kernel: [67139.675767] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 Start waveforms program. It successfully finds device. But then message to /var/log/messages after: Sep 13 11:57:36 deb-nuc5i5 kernel: [67183.913434] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 Sep 13 11:57:36 deb-nuc5i5 kernel: [67183.913446] ftdi_sio 1-2:1.0: device disconnected Though waveforms is still connected and running. This was different from what I saw on the VersaLogic Iguana board. So, many things changed and I can't tell what one made the difference: different usb chip on motherboard, causing different driver selection, or 64bit vs 32 bit os.