search

analogdevicesinc / libsmu

Software abstractions for the analog signal exploration tools.
http://analogdevicesinc.github.io/libsmu/
BSD 3-Clause "New" or "Revised" License
31 stars 31 forks source link

rework: arbitrary waveforms with repeat off #91

Open damercer opened 7 years ago

damercer commented 7 years ago

I'm sure but I think there may be a problem with the channel.arbitrary() wave shape. When the repeat flag is set to 1 it works but with repeat flag set to 0 the program hangs never coming back from session.run(2000) with the length of the waveform also equal to 2000 samples or if session.run() request is greater than wave samples. But it seems to work when length of waveform is greater than number of samples in session.run() i.e wave is 4000 samples and session.run(2000). I thought the last sample value is repeated until end of run? At any rate the program should not hang.

Doug

radhermit commented 7 years ago

Currently, not much is done the way of hand-holding and making sure one is balancing write, read, and run calls, at best exceptions are thrown. Since the entire model changed, from requesting sample data for writing which always generated new values on demand to explicitly writing in sample data, it doesn't repeat the last sample value anymore either.

It now should throw a timeout exception if you're running too many unbalanced reads and/or writes and bump up against queue size limitations (assuming ignore_dataflow is false). I might have to decouple write timeout exceptions from read() exceptions to make things more granular because right now ignore_dataflow=True ignores everything.

Finally session.run(2000) should work now if the waveform is equal in length. I'd advise using session.get_samples() from now on too for noncontinuous usage, it takes care of calling run() internally, will break up a request into multiple runs if the requested sample count is larger than the internal queues, and should handle multiple devices transparently.

I probably should add similar request splitting to the various session/device/channel read() so they can handle requests larger than the internal queue size as well.

radhermit commented 7 years ago

I forgot to add arbitrary() is no more, use write() directly. The same thing will probably happen to constant() down the line in order to provide a consistent interface. I'm thinking of making the waveform rework be similar to how using numpy is, i.e. you'll generate a data buffer using a selected function/signal and then pass that buffer off to be written.

damercer commented 7 years ago

These changes might be making things easier for you but this sort of radical change from master makes it very difficult for users of the software ( like me ). I was hoping that the higher level functionality of master would be maintained as is?

Can you at least suggest how to mimic the previous functionality? I can't always guarantee that the user will make his waveforms the same length as the scope time sweep.

What do you mean arbitrary() is no more and will probably happen to constant()? Please provide the same higher level simplifications to model the functions in master as you promised more then 6 months ago.

Doug

radhermit commented 7 years ago

Having arbitrary() remain makes little sense because it's basically a write() alias. The others probably can remain, they'll just wrap creating data buffers of the specified waveform and writing them as cyclic.

Having unbalanced writes/reads works now for noncontinuous mode when used with session.get_samples() if I forgot to mention that above. For example you can write a 100000 sample buffer for both channels, and then do session.get_samples(20000) for 5 calls. However, currently data write timeouts will occur if you request more samples then you have written, in other words the last sample value is not repeated until the end of the run at the moment. If this breaks lots of things for you, I can look at re-adding that.

damercer commented 7 years ago

Write and Arbitrary are both descriptive words for that operation, however, in the context of generating waveforms along with functions for sine, square, sawtooth, stairstep etc. arbitrary is more descriptive so that along with the desire to keep to the spirit of the usage in master is why I'm asking to keep the arbitrary function.

Starting from which build number does unbalanced writes/reads work so I know which one I should be using? When will you have this fixed "currently data write timeouts will occur if you request more samples then you have written" ? The other case is not what I was complaining about. "If this breaks lots of things for you, I can look at re-adding that." Yes, please.

Doug

radhermit commented 7 years ago

Both requests should be fixed now whenever 1.0.889 finishes building.

Note that fallback values will currently only be used in noncontinuous mode if sample values have been written to the related channel during the current run. In other words, buffer timeouts will still occur if you try to request data in SVMI and SIMV modes if you haven't written anything yet.

If it makes sense to enable this for continuous mode too, I can probably do that.

damercer commented 7 years ago

Now getting following error message with build 904 installed. .arbitrary() worked with older install before arbitrary() was removed/reverted, no changes to code. Repeat Flag set to 1.

Traceback (most recent call last): File "C:\Documents and Settings\DELL\My Documents\RPI\ADiscovery\ALM\rework\alice-desktop-1.2.pyw", line 12573, in Analog_In() File "C:\Documents and Settings\DELL\My Documents\RPI\ADiscovery\ALM\rework\alice-desktop-1.2.pyw", line 1661, in Analog_In Analog_Time_In() File "C:\Documents and Settings\DELL\My Documents\RPI\ADiscovery\ALM\rework\alice-desktop-1.2.pyw", line 1847, in Analog_Time_In BAWGEnab() File "C:\Documents and Settings\DELL\My Documents\RPI\ADiscovery\ALM\rework\alice-desktop-1.2.pyw", line 6719, in BAWGEnab UpdateAWGA() File "C:\Documents and Settings\DELL\My Documents\RPI\ADiscovery\ALM\rework\alice-desktop-1.2.pyw", line 6212, in UpdateAWGA CHA.arbitrary(AWGAwaveform, AWGARepeatFlag.get()) # set repeat flag File "pysmu\libsmu.pyx", line 708, in pysmu.libsmu.Channel.arbitrary (C:\projects\libsmu\bindings\python\pysmu\libsmu.cpp:12229) File "pysmu\libsmu.pyx", line 676, in pysmu.libsmu.Channel.write (C:\projects\libsmu\bindings\python\pysmu\libsmu.cpp:11936) File "pysmu\libsmu.pyx", line 465, in pysmu.libsmu.Device.write (C:\projects\libsmu\bindings\python\pysmu\libsmu.cpp:8855) ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

Doug

radhermit commented 7 years ago

It was a bad interaction between boolean checks and numpy arrays, fixed in 1.0.905.

damercer commented 7 years ago

Never mind seems to have been due to operator error. Sorry. Repeat off seems to work as expected now.

radhermit commented 7 years ago

If you can describe examples or ideas for documentation that can help others avoid issues such as this, let me know. Next on my list alongside reintegrating function generator support is writing up more docs and test suite support. I'm open to adding more docs/examples as necessary to help describe usage better.