• 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 g
  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_me
  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 t
  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'
  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
  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 tha
  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 c
  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' D