maling

Members
  • Content Count

    8
  • Joined

  • Last visited

  1. Hi @attila, (Re accepted answer) That's solved it! I made the szerr.value modification, and did not get any error messages. But your example code (which runs perfectly!) helped me realize why: I think the issue isn't from the dwf library. My device connection step (FDwfEnum) was much more complicated than what you posted - I had originally based it on the Enumerate.py example, since I needed the device serial numbers and thought the other debug information might be useful. When I modified my device connection step to use only the dwf library (cutting out most of the En
  2. Hi @attila, See below for an illustration of what does, and does not, produce the failure. The full code base is a bit large - if you need a full working example, let me know and I can do some rearranging. Of the functions below, GetSpectrum() does not produce the failure, while GetSpectra() does. Thank you! All nine devices are first connected. They each have the following configuration applied: DLLs.FDwf(dwf.FDwfAnalogImpedanceReset, [hdwf]) DLLs.FDwf(dwf.FDwfAnalogImpedanceModeSet, [hdwf, c_int(8)]) # 0 = W1-C1-DUT-C2-R-GND, 1 = W1-C1-R-C2-DUT-GND, 8 = AD I
  3. Hi @attila, I still have it on my list to try @reddish's pydwf project, but I believe that the above implementation is sufficient to catch any error messages which are generated. Given that no error messages are being produced, I was hoping you might have additional insight into possible causes of the failure. It feels very much like the failure is related to some manner of delayed communication with the Analog Discovery II. I don't have enough expertise to understand what might be happening under the hood, but I would be happy to provide example code if that would be useful. Th
  4. That sounds amazing - I'll definitely take a look.
  5. Hi @attila, Ah, thank you, that explains a lot. I've tried implementing FDwfGetLastErrorMsg using the following wrapper: def FDwf(self, fun, args): if fun(*args) == 0: # If the function returns 0, that means an error has occurred. print('') print('There has been an error while calling ' + str(fun) + ' with arguments' + str(args)) print('') # We have to go find the error szerr = create_string_buffer(512) self.dwf.FDwfGetLastErrorMsg(szerr) # Th
  6. Another possibility, though I would be surprised if this were the case - does DWF 3.14.3 support Python 3? This post implies it may not, although perhaps the "updated" date in 2021 is deceptive: https://digilent.com/blog/waveforms-sdk-is-now-updated-to-include-python-3/
  7. Hi @attila Thanks for the reply! I just checked on the power issue (there was a chance - my USB hub could only supply 36 W.) However, dividing the Discovery II's between two identical hubs at 36 W each, the error still occurs with exactly the same behavior. I have tried to use FDwfGetLastErrorMsg(sz) as you suggested, but without the immediate return statements. Does the immediate return statement change the behavior of the function? Example: bool myfunc(){ FDwf...(.) FDwf...(..) ... } myfunc() FDwfGetLastErrorMsg(sz) print(sz)
  8. Hello all! I've been working with the WaveForms SDK for over a year now to control a collection of nine Digilent Analog Discovery II's connected to a powered USB hub. For the most part, it's been great - but recently I've encountered a problem that I can't seem to debug. This is primarily because on encountering most errors within the SDK, the SDK appears to abort the main Python script's execution silently, without raising an exception in Python. In this case, I've attempted to use FDwfGetLastErrorMsg, but no error is recognized by this method either. Question 1: Is there a mor