Skip to content

Commit da1398b

Browse files
committedAug 19, 2015
pxi6733: fix crash when samples are all the same
When samples are all the same, min = max, which PyDAQmx does not like. This avoids the following crash reported by Kathie: C:\Users\rabi\artiq\artiq\frontend [master]> python .\artiq_rpctool.py ::1 3256 call load_sample_values 100000 'np.array([0.0,0.0],dtype=float)' Traceback (most recent call last): File ".\artiq_rpctool.py", line 112, in <module> main() File ".\artiq_rpctool.py", line 107, in main call_method(remote, args.method, args.args) File ".\artiq_rpctool.py", line 79, in call_method ret = method(*[eval(arg) for arg in args]) File "C:\Users\rabi\AppData\Local\Continuum\Anaconda3\lib\site-packages\artiq- 0.0+dev-py3.4.egg\artiq\protocols\pc_rpc.py", line 142, in proxy return self.__do_rpc(name, args, kwargs) File "C:\Users\rabi\AppData\Local\Continuum\Anaconda3\lib\site-packages\artiq- 0.0+dev-py3.4.egg\artiq\protocols\pc_rpc.py", line 134, in __do_rpc return self.__do_action(obj) File "C:\Users\rabi\AppData\Local\Continuum\Anaconda3\lib\site-packages\artiq- 0.0+dev-py3.4.egg\artiq\protocols\pc_rpc.py", line 128, in __do_action raise RemoteError(obj["message"]) artiq.protocols.pc_rpc.RemoteError: Traceback (most recent call last): File "C:\Users\rabi\AppData\Local\Continuum\Anaconda3\lib\site-packages\artiq- 0.0+dev-py3.4.egg\artiq\protocols\pc_rpc.py", line 476, in _handle_connection_cr ret = method(*obj["args"], **obj["kwargs"]) File "C:\Users\rabi\AppData\Local\Continuum\Anaconda3\lib\site-packages\artiq- 0.0+dev-py3.4.egg\artiq\devices\pxi6733\driver.py", line 117, in load_sample_val ues byref(num_samps_written), None) File "<string>", line 3, in WriteAnalogF64 File "<string>", line 2, in function File "C:\Users\rabi\AppData\Local\Continuum\Anaconda3\lib\site-packages\pydaqm x-1.3.1-py3.4.egg\PyDAQmx\DAQmxFunctions.py", line 28, in mafunction raise DAQError(error,errBuff.value.decode("utf-8"), f.__name__) PyDAQmx.DAQmxFunctions.DAQError: Minimum is greater than or equal to the maximum . Ensure the maximum value is greater than the minimum value. If using a custom scale, ensure that the scaled maximum is greater than the scaled minimum. Property: DAQmx_AO_Min Corresponding Value: 0.0 Property: DAQmx_AO_Max Corresponding Value: 0.0 Channel Name: Dev1/ao1 Task Name: _unnamedTask<4> Status Code: -200082 in function DAQmxWriteAnalogF64
1 parent c3f3763 commit da1398b

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed
 

Diff for: ‎artiq/devices/pxi6733/driver.py

+1-1
Original file line numberDiff line numberDiff line change
@@ -93,7 +93,7 @@ def load_sample_values(self, sampling_freq, values):
9393
values = values.flatten()
9494
t = self.daq.Task()
9595
t.CreateAOVoltageChan(self.channels, b"",
96-
min(values), max(values),
96+
min(values), max(values)+1,
9797
self.daq.DAQmx_Val_Volts, None)
9898

9999
channel_number = (c_ulong*1)()

4 commit comments

Comments
 (4)

sbourdeauducq commented on Aug 19, 2015

@sbourdeauducq
Member

1 is an arbitrary scale and can be very large if the samples are small. I'd apply this workaround only when min=max.

jordens commented on Aug 19, 2015

@jordens
Member

That's irrelevant. It is a 16 bit DAC with fixed output range.

But what might become relevant (not here and 6733 through) is the fact that min and max should not be automatically derived from the values. For cards that have variable output range, they could change the range depending on the output which may not be what one wants or what is expected.

fallen commented on Aug 20, 2015

@fallen
ContributorAuthor

@jordens so you think we should allow one to use an output range (min/max pair) which does not correspond to the sample values?

jordens commented on Aug 20, 2015

@jordens
Member

Yes. For 6733, you can safely (if your experiment can survive that range) set min=-10 and max=10 (but i have seen funny things at +10V, suspecting signed integer effects) globally. For other cards this can be different.

Please sign in to comment.