Open Bodeeen opened 8 years ago
Hi @Bodeeen,
I do not find the same problem when running the module outside the GUI even though it is still run from a QThread?
are you sure about this?
Also, could you please provide a minimal working example?
@hoechenberger I now also tried running it the inside the QtGui/QApplication without threading at all, and still the same OSError appears sporadically. This to me further corroborates that is is not the threading but the fact that it's run inside the QtGui/QApplication that is somehow causing a memory issue. Since the error only occurs when running inside this larger application I don't really know how to provide you with a MWE. I tried removing as much of the (to me) irrelevent code in the function that creates and writes to tasks. It seems though that the simpler i make the function the less likely I am to cause the error. I understand this is a very vague problem description but due to the seemingly randomness of the error I'm struggling to give any more concrete clues...
I also experienced a very strange issue while trying to find some rime and reason for this error. This occurred when I ran the module on its own, outside the application. Then the function ran nicely the first time I generated the tasks and signals. But the second time the error "Task specified is invalid or does not exist. Status Code: -200088" was raised when trying to write to the digital output task. The wierder thing is that when adding a print(np.ones(1)) before the dotask.write(...) call everything works nicely. It could also be "fixed" by adding similar line in the driver for example before the line: number_of_channels = self.get_number_of_channels() in the digital output write function of the libnidaqmx wrapper. But if adding the line both in the module and in libnidaqmx causes the error to appear again? I find it confusing how a print line can change the behaviour of my code...
I don't know if the two above issues are related at all, but since I can't dismiss the possibility I though I should mention them both.
The lines shown below fix the problem on their own, but adding both of them causes the issue to occur again.
Hi, thanks for your detailed response. This certainly seems like a locking problem to me. Which version of NI-DAQmx are you using, and on what platform (OS and Python distro/version)? Do you run the code from the command line or from within an IDE?
Also, you state:
This occurred when I ran the module on its own, outside the application.
Would it be possible for you to provide this module so I could have a look? You may also send it to me privately, richard.hoechenberger@gmail.com
I will be busy for the next couple days though, so I cannot promise how long it is going to take me to really look into this :)
Hi, I am using the pylibnidaqmx wrapper with the PCI6731 card. While starting tasks in a QThread from a lager GUI the error in the title is raised in a seemingly random way, i.e. it is not rasied every time but and I have not managed to surely recognize any pattern as to when it is raised. Could it have to do with the fact that it is run from a QThread? I do not find the same problem when running the module outside the GUI even though it is still run from a QThread? I am running an AnalogOutputTask and a DigitalOutputTask with the do task following the ao/SampleClock and the Error occures when either the dotask.write or the aotask.write is called, also seemengly randomly.
Traceback (most recent call last): File ".\control\Scan.py", line 344, in run dotask.write(full_do_signal, layout = 'group_by_channel', auto_start = False) File ".\control\libnidaqmx.py", line 3636, in write data.ctypes.data, ctypes.byref(samples_written), None) File ".\control\libnidaqmx.py", line 268, in CALL r = func(*new_args) OSError: exception: access violation reading 0x000007FE11896450