<sb0>
ysionneau, also, the user probably should not need to know anything about tasks
<sb0>
if load_sample_values is called again before the full playback, and this *will* happen if an experiment is aborted and restarted, your code must automatically cancel the previous task
<ysionneau>
17:20 < sb0> ysionneau, pxi6733 controller is fully done and tested, right? < load_sample_values has been tested and works, though I need to add the "cancel the previous task", ping() doesn't work yet, so far it always return True
<ysionneau>
as I've been told by Katie yesterday
<ysionneau>
I need to find another way of testing the presence of the hw
<sb0>
what's the return value of daq.DAQmxGetDevSerialNum?
<sb0>
don't assume that bindings use exceptions ...
<ysionneau>
in fact it does not seem to use exceptions
<sb0>
self.tasks should not be a list, just one element/None
<ysionneau>
my angle of attack here is to try to get the serial number and compare it with the one of pxi6733
<ysionneau>
return value of daq.DAQmxGetDevSerialNum is just a success/failure flag I think, but don't know for sure
<ysionneau>
data should contain the serial num
<sb0>
C functions that fail often do not fill in their output data, so I'd check that return value
<sb0>
isn't that documented?
<ysionneau>
my next move was to ask Katie to add prints of data value and return value and so on
<ysionneau>
return value wasn't very clear, let me check
<ysionneau>
the documentation page I found just gives the prototype, saying return value is int32
<ysionneau>
ack about tasks which should not be a list, since a user can now create as many DAQmx instance as it needs for different devices/analog_output combinations
<sb0>
hmm, really?
<sb0>
how does that work? run several controllers?
<ysionneau>
yes
<sb0>
targeting the same device?
<sb0>
does it work?
<ysionneau>
it should
<ysionneau>
since it create tasks targeting device/outputs couples
<ysionneau>
but I don't think Katie tested this (several simultaneous outputs/controllers)
<sb0>
won't it also target the same clock line?
<ysionneau>
you give the clock line as parameter when instanciating the DAQmx
<ysionneau>
so you could use different clocks if you wish
<ysionneau>
or use the same
<sb0>
as far as I know the use case is clocking out several waveforms synchronously from the same clock
<sb0>
won't the DAQmx driver break if you have multiple processes trying to access the same clock line on the same device?
<ysionneau>
That's something I need to ask Katie to test for
<ysionneau>
I hope not
<ysionneau>
if it does, I can refactor to use one task per multiple analog outputs
<sb0>
that may be easier to use anyway
<sb0>
otherwise you need to run lots of controllers on different TCP ports, have many entries in the ddb, and then the mediator needs to aggregate connections to several controllers and check that they are all configured to use the same clock line
<ysionneau>
humm ok
<sb0>
the "bytes(args.device, "ascii")" probably should be done in pxi6733/driver.py
<ysionneau>
ok
<sb0>
also, doing dubious things like accessing the same device from multiple processes is generally a bad idea. even if it is supposed to work, it may tickle race conditions or other bugs in the driver.
<ysionneau>
right, I will refactor then
<ysionneau>
It does not need much changes to support this anyway
<ysionneau>
(if I understood well the API)
<GitHub172>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vIqVm
<GitHub172>
artiq/master 37c7ea3 Sebastien Bourdeauducq: gui: TTL override support
<ysionneau>
do you recommend I parse the channel string specified by the user to find out how many channels there are?
<ysionneau>
or do I put a "channel_number" parameter?
<ysionneau>
I would go for the simpler "channel_number" parameter solution
<sb0>
how would that "channel_number" work?
<ysionneau>
in DAQmx() __init__ I replace device arg by channels arg, then if the user provides channels="Dev1/ao1:4" he must supplies also channel_number=4
<sb0>
why?
<ysionneau>
this is needed to validate the "values" array size, and also to provide the "number of samples per channel" to the DAQmx API
<sb0>
ah, you mean the user has to count the channels themselves. no, that's obviously unacceptable.
<ysionneau>
ok
<ysionneau>
then parsing it is
<sb0>
isn't there an API that returns the number of channels you have selected?
<ysionneau>
I'm searching but I don't think there is
<sb0>
if not, i'd suggest dumbing down the specification system
<ysionneau>
I can just ask the user for an array of single channels like ["dev1/ao1", "dev1/ao2"] and then concatenate it myself
<ysionneau>
if that's what you mean by that
<sb0>
yes
<ysionneau>
all right
<sb0>
we don't have to support the NI channel selection mini-language, and Python eval() is a superior alternative to it anyway
<sb0>
but I'd be really surprised if the API wouldn't tell you how many channels you got