Re: [ARTIQ] controller management

Hello, On 01/03/2015 10:51 AM, Robert Jördens wrote: >>> I would just point the managers to the master where they can get their >>> (current, versioned) subset of the devicedb. They can cache that if >>> really needed. >> >> Then the master depends on the controllers to be able to run >> experimen

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

Hi, On 01/06/2015 04:43 AM, Slichter, Daniel H. wrote: > Is there an on-die 100-ohm differential termination for LVDS signals > at VCCO = 2.5V? Yes. > Either way, it's actually a physically shorter distance from the SMA > connector to the FPGA (~5 cm) than from the FMC connector to the > FPGA,

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/06/2015 01:55 PM, Sébastien Bourdeauducq wrote: > Routing each SYNC_CLK to the FPGA with matched trace lengths all the way > is also an option. Using one IDELAY and one IOB register per input (all > clocked from the same network) should result in low skew. Or sample SYNC_CLK with a

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/06/2015 03:26 PM, Sébastien Bourdeauducq wrote: > Or sample SYNC_CLK with a discrete flip-flop or latch near each DDS chip > and trigger them with a skew-matched on-board clocking network pulsed by > the FPGA through a scanned ODELAY. Then low-performance multiplexers, > shar

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/07/2015 02:02 AM, Slichter, Daniel H. wrote: >> All SYNC_CLKs need to be matched (ideally to less than a SYSCLK >> cycle) so that the FPGA can properly detect when they are aligned, >> and a shared bus will not achieve that. > > This is not necessarily required, I had thought. What we nee

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/08/2015 07:17 AM, Slichter, Daniel H. wrote: >> The phase of that distant DDS will also be off by roughly the >> propagation delay. > > See above; this is not an issue because we don't really care about > the absolute phase difference between DDS chips at the plane of the > DDS outputs, just

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/09/2015 01:12 AM, Slichter, Daniel H. wrote: > You mean to use essentially as a thresholding phase detector? In > other words, directly measuring the phase of the output signal > instead of the phase of the SYNC_CLK? Yes. > We could potentially > implement this, but I would do it in additi

Re: [ARTIQ] Implementing a saveion function

On 01/13/2015 07:39 AM, Gaebler, John wrote: > I would think the outer loop would break if the ion is lost and > continue if the ion is recovered but maybe keep going until 100 > successes are achieved (has a line like if usesequence: i=i+1). For > duty cycles, if the user has a specific goal for d

Re: [ARTIQ] PXI6733 controller

On 01/22/2015 02:08 AM, Joe Britton wrote: > * The "waveform advance" pulse to the 6733 is what causes its output to > transition from one ADC channel (voltage) to another. We usually > generate this pulse from the FPGA not from a periodic clock (eg crystal > oscillator). This makes it possible to

Re: [ARTIQ] PXI6733 controller

On 01/22/2015 01:07 PM, Joe Britton wrote: > Yes, one pulse is required per sample. One way of doing this might be to > have a fixed frequency clock that is gated by a RTIO channel. I'd rather put that oscillator in the FPGA, as it would need to be synchronized with the RTIO core to get repeatable

[ARTIQ] NIST press release

Hi, here is the ARTIQ story on NIST news: http://nist.gov/pml/div688/grp10/open-source-software-for-quantum-information.cfm Thanks all for your support! Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] logging in controllers

Hi Joe, I have added a little description of how to use logging: http://m-labs.hk/artiq/manual/writing_a_driver.html#logging-and-error-handling-in-controllers The basic idea is to use the Python logging module normally, and let the (future) controller manager make a stderr redirection if we want

Re: [ARTIQ] driver integration

On 01/27/2015 10:03 AM, Joe Britton wrote: > class LED(AutoDB): > class DBKeys: > led = Device() > penning_rotating_wall = Device() > penning_rotating_wall.set_freq_all_phase_continuous(0.05) DBKeys is only a description of what object attributes needs to be linked to t

Re: [ARTIQ] PXI6733 controller

On 01/27/2015 03:48 AM, Yann Sionneau wrote: > Actually I was thinking about using the PyDAQmx project ( > http://pythonhosted.org/PyDAQmx/ ) and provide a direct access to the PyDAQmx > API through the ARTIQ RPC mechanism. > The PyDAQmx API being itself a direct wrapping/binding of the NI DAQ mx

Re: [ARTIQ] hardware design proposal for ARTIQ DDS/TTL system

Hi, I suggest: * using 3.3V everywhere so that the FMC card is compatible with other FPGA boards that use a different distribution of the FPGA banks to the FMC connector. Having two different IO voltages on LAxx violates rule 6.1 of the FMC standard and may work only on the KC705. Switching everyt

Re: [ARTIQ] hardware design proposal for ARTIQ DDS/TTL system

On 01/28/2015 12:56 AM, Slichter, Daniel H. wrote: > With this design, the amount of analog jitter is going to be pretty > nasty, and we'll need to have it pegged to less than one SYSCLK > period (~300 ps) if we want to use this for syncing. If we really > care about this kind of diagnostic being

Re: [ARTIQ] logging in controllers

On 01/28/2015 09:56 PM, Yann Sionneau wrote: > +from artiq.frontend.loglevel import verbosity_args, init_logger Looks good to me, but I'd rather put those two small functions in artiq.tools instead of creating another file. Sébastien ___ ARTIQ mailing

Re: [ARTIQ] artiq dependencies

On 01/29/2015 04:25 AM, Slichter, Daniel H. wrote: > I think it would make sense to fork external dependencies into > m-labs/artiq so that dependencies don't break over time. > > > I second the motion. What about pointing out to known good version numbers of dependencies in the ARTIQ documentat

[ARTIQ] GUI: controls

Hi, I'd like to start more discussions about the GUI before coming. I've been prototyping some of those ideas (the Glade controls loading and argument passing should work already), and I invite you to have a look at the code and try it out so that we have a solid base of discussion. Please let me

Re: [ARTIQ] GUI: controls

Hi, On 01/31/2015 06:09 AM, Britton, Joe wrote: > It might be possible to auto-generate a GUI client for a device with > an ARTIQ driver based on the existing command line clients we are > writing using argparse. The argparse description will lack information that is important for building a good

Re: [ARTIQ] GUI: controls

Hi, Are you able to run the GUI - do you see the parameters, scheduler and explorer windows? You need to run artiq_master (in the examples directory, so that it finds pdb.pyon, ddb.pyon and explist.pyon) and then artiq_gui. I made several changes since Jan 20, so you may want to upgrade from Git.

[ARTIQ] mybalsamiq mockups archive

Hi, as the mybalsamiq account keeps being suspended, I have archived the mockups here: http://m-labs.hk/artiq/gui_mockups_20150201.pdf Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] GUI: controls

On 02/03/2015 03:23 AM, Bohnet, Justin G. wrote: > I'm also interested in getting this going. I'm wondering if it will > be problem that we are trying to run the artiq GUI on Xubuntu, which > I see uses xfce for the window manager (Since Glade is connected to > Gnome window manager?) No problem. G

Re: [ARTIQ] GUI: controls

On 02/03/2015 06:37 AM, Bohnet, Justin G. wrote: > I place pdb.pyon, ddb.pyon and explist.pyon in the > artiq-dev/artiq/artiq/gui directory, along with a copy of > artiq_master and artiq_gui. You don't need to copy those files, nor touch artiq-dev/artiq/artiq/gui. Just cd to the artiq-dev/artiq/e

Re: [ARTIQ] GUI: controls

On 02/04/2015 05:12 AM, Bohnet, Justin G. wrote: > My feedback so far on the GUI elements is that they seem nice. It > feels fast and is a lot like what I had imagined. I've been able to > play around in Glade a bit and modify the design of the widget you > made to add a slider bar and connect it

Re: [ARTIQ] GUI: controls

On 02/06/2015 03:36 PM, Robert Jördens wrote: > Hmm. I fear that with this design the prevalent use case of > > a) taking an arbitrary experiment > b) choosing an arbitrary parameter from the parameter db > c) scanning the experiment over that parameter > > is more complicated than it should be.

Re: [ARTIQ] artiq complicated experiments

Hi, On 02/10/2015 07:04 AM, Gaebler, John wrote: > I would like to describe a compound device from a combination of dds > and rtioout devices that would do everything needed to set the > frequency for a gate pulse and also switch on and off. The dds > device is too simple since sometimes multiple

Re: [ARTIQ] KC705 support

Hi, Seems to work here, thanks for fixing! I found two other bugs while testing: * Vivado fails to generate the .bin raw binary bitstream file: https://github.com/m-labs/migen/issues/9 This breaks loading the bitstream into flash wish xc3sprog. Building with ISE works around the problem. * loadin

Re: [ARTIQ] KC705 support

Hi, Thanks Florent, I didn't find the Vivado command to generate raw binaries in the manual. Direct load with xc3sprog still does not work, but the bitgen options solve another problem: booting the FPGA from flash was also broken. Sébastien On 03/29/2015 06:21 PM, Florent Kermarrec wrote: > He

Re: [ARTIQ] external triggering; optical dipole force beatnote

On 03/31/2015 07:13 AM, Joe Britton wrote: > If the latency were deterministic and less than 1 us the scenarios I > described would work fine When you receive a trigger, the RTIO core timestamps it and the CPU uses that timestamp as "now" value. Then you delay() it by a sufficient amount to accou

Re: [ARTIQ] Logger UI

On 04/14/2015 11:29 PM, Tan, Ting Rei wrote: > List the logged values with time stamps. What kind of "logged values"? I thought the log was like a console where you output debug strings. Did you mean "results"? Sébastien ___ ARTIQ mailing list https://

Re: [ARTIQ] Pipistrello build process

On 04/21/2015 05:46 AM, Zach Smith wrote: > I'll poke though the stack trace to see if I can find a problem > somewhere in the morning, but in case this is a familiar error to > anyone I thought I'd reach out. Did you build the runtime yourself? If you used a runtime binary in conjunction with ART

[ARTIQ] result management

On 04/21/2015 02:12 AM, Tan, Ting Rei wrote: > On a similar note, is there any documentation on the workflow/communication > between the GUI and the master? There are several things I'm curious about: > > 1. When the master receive data from the core devices, how does the data get > to the GUI

Re: [ARTIQ] result management

On 04/21/2015 11:06 PM, Tan, Ting Rei wrote: > I see. Let's discuss a case that the results are PMT detection data. > In this case, I guess the core device will pass upstream an array > which resembles the histogram of the detection results. What I want > to be plotted in real time are, the histogr

Re: [ARTIQ] Draft: Minimum pulse time in with:parallel construct

Hi, On 04/29/2015 05:29 AM, Zach Smith wrote: > Adding a third TTL channel gets to ~4.5us, and a fourth ~6us. So it > looks like we're seeing extra overhead of about 1.5us per TTL line. > > Two questions: > 1) Are we missing a construct that would decrease that time? No, this is expected. What

Re: [ARTIQ] [PATCH] artiq_flash.sh: Pipistrello uses bscan_spi_lx45_csg324.bit flash proxy

On 04/30/2015 05:07 AM, iamsparti...@gmail.com wrote: > I wasn't sure whether to send patches here, send them to them to the devel > mailing list, or use pull requests on GitHub, so I hope this is OK. Mailing list is good. Thanks! ___ ARTIQ mailing list

Re: [ARTIQ] ARTIQ future details

Hi Joe, On 03/12/2015 01:43 AM, Joe Britton wrote: > Goals by beginning of May > === > Aim is to run penning trap experiment on ARTIQ > 1) run ARTIQ on KC705 with legacy TTL/DDS system (16 TTL, 8 DDS) Ethernet is working fine on the KC705 now - I have fixed the "low throughput"

Re: [ARTIQ] ARTIQ future details

On 05/02/2015 03:05 PM, Sébastien Bourdeauducq wrote: > The idle experiment is not supported when using the serial port to > communicate with the PC. If this is something we'd need, I suggest encapsulating TCP over serial using PPP: http://lwip.wikia.com/wiki/PPP

[ARTIQ] Qt and pyqtgraph

Hi, I had a close look at Qt and pyqtgraph and they are actually pretty nice, as they already implement several features we have talked about: * workspace/dock environment: including tabbed docks, support for splitting a dock into a separate window e.g. for multi-head setups (double click on the d

Re: [ARTIQ] GUI spec.

Hello, On 05/21/2015 10:48 AM, Robert Jördens wrote: > On Tue, May 19, 2015 at 9:48 PM, Sebastien Bourdeauducq > wrote: >> The description of the fits in this document is problematic. The fits are >> done in the analyze() method of the experiments, running on the master and >> possibly updating

Re: [ARTIQ] AD9914 programming details

On 05/22/2015 05:07 AM, Robert Jördens wrote: > Modulation seems to be especially hard as it will make the > bus sharing even harder. What will modulation bring from a physics perspective? DRTIO and an army of small FPGAs would solve the DDS bus sharing issues... Sébastien __

[ARTIQ] remote imports

On 06/03/2015 02:59 AM, Robert Jördens wrote: >> And as I have pointed out before, proper remote imports with asyncio are >> > difficult (though not impossible) as they require modifying the AST of >> > remotely imported modules to turn their own import statements into >> > something asyncio-friend

[ARTIQ] TTL monitoring/injection panel

Hi, here is a screenshot of the current GUI for TTL monitoring and injection. The TTL channels and their names are retrieved from the device database. Channels that are in override have their value displayed in bold red. Overriding channels is done via the context menu. Opinions? Sébastien

Re: [ARTIQ] FW: TTL monitoring/injection panel

On 06/06/2015 03:10 AM, Bohnet, Justin G. wrote: > Can the TTL 'tab' be broken out from the DDS tab and explorer tab? Yes, like any other dock it can be moved around anywhere in the GUI and broken out into a separate window. > What does it mean that the 0 of ttl0 is red? > What determines how ma

[ARTIQ] fire-and-forget RPC / inter-CPU communication

Hi, do we still care about the "fire-and-forget RPC" feature? (i.e. support scenarios where the core device does not wait for the RPC return value from the network before continuing kernel execution, applicable only when the RPC return value is unused of course) If so, how fast should those fast

Re: [ARTIQ] fire-and-forget RPC / inter-CPU communication

On 06/12/2015 11:17 PM, Robert Jördens wrote: >> it may make sense to make choices that optimize the inter-CPU >> > communication speed in the SoC. (Florent and I are debating whether we >> > should have a shared L2 cache for both CPUs, which would e.g. make the >> > transfer of small messages betw

Re: [ARTIQ] Building Artiq from source

Hi, On 08/04/2015 05:05 PM, Chris Ballance wrote: > When I try to make the runtime I get unknown argument errors: > $ cd ~/artiq-dev/artiq/soc/runtime && make runtime.fbi > CC isr.o > clang: error: unknown argument: '-mhard-mul' > clang: error: unknown argument: '-mhard-div' Those two argu

Re: [ARTIQ] Building Artiq from source

I just changed it. Thanks for your helpful resolution of the problem. Sébastien On 08/04/2015 06:39 PM, Christopher Ballance wrote: > Hi, > > The problem was that I was not using the clang binary that I built. My > distribution (Ubuntu 15.04) has clang installed in /usr/bin/clang. The > insta

Re: [ARTIQ] KC705 DDS/TTL card status

Hi, On 08/12/2015 10:00 AM, Benjamin K. Stuhl wrote: >I'm writing to inquire about the status of the DDS/TTL (really just > the TTL) breakout cards that were described on this list back in Jan/Feb > [1]: have the designs been finished? Have any been built, or tested? The hardware we ended up

[ARTIQ] TTL direction on I2C IO expander

On 08/14/2015 12:22 AM, Slichter, Daniel H. wrote: > But then we won't be able to use the TTLs properly until I2C is > implemented. What kind of time scale would you see for having the > I2C running correctly? We can give you a demo board for the I2C chip > (TCA6424A) to help with the I2C debuggi

Re: [ARTIQ] Using the analyze() pipeline

On 08/20/2015 01:24 AM, Tan, Ting Rei wrote: > I am still getting myself familiar with the GUI. Two others question I have > now are: > > 1. Regeneration of GUI parameter tool: after adding a parameter tool into the > script, e.g. self.attr_argument("Boo1", BooleanValue(True)). I will need to >

Re: [ARTIQ] embedded RPC server

Hi, On 08/20/2015 11:34 PM, Neal Pisenti wrote: > I've started to think about how ARTIQ could be integrated with the > various arduino-based devices we have operating around the lab > (controlling things like slow DACs, DDSs, doing temperature/humidity > logging, etc.), and would like to write a p

Re: [ARTIQ] documentation on 'scannable'

Hi, here: http://m-labs.hk/artiq/manual/core_language_reference.html#module-artiq.language.scan Sébastien On 08/21/2015 01:28 AM, Tan, Ting Rei wrote: > Hi, > > > > I’d like to request more documentation on ‘scannable’. I.e. how to set > the scan range for different scan type (linear, rando

[ARTIQ] AD9914 support status and questions

Hi, I've been doing some hardware tests on the QC2 AD9914 DDS system. Many things are working (tested using the runtime test mode): * basic read/write of the registers, reset values match the datasheet * 10 cycles of ddstest * selection of different slots on the backplane * reset - a modified

Re: [ARTIQ] code reuse with ARTIQ

Hi, Multiple inheritance can be problematic (due to namespace clashes) when there are lots of libraries. I would rather do sub-objects (similar to the existing device drivers), e.g. def build(self): self.std_prepare = StdPrepare(*self.dbs()) You can then get rid of the std_/std_detect_ prefi

Re: [ARTIQ] some comments about artiq_gui

On 08/23/2015 12:48 AM, Tan, Ting Rei wrote: > 2. Master Menu bar so user containing a list of the tabs, e.g. > DDS, explorer, log…. > > - This is so that user can open these tabs from these menu bar > after closing them. Currently there is no way for the user to do this. The fact

Re: [ARTIQ] some comments about artiq_gui

On 08/23/2015 12:48 AM, Tan, Ting Rei wrote: > 1. Separate dock for parameter tool. > > - Currently the parameter tool for each experiment is tied to > the experiment explorer. We would like them to be separated, and in > principle user would be able to parameter tool for different

Re: [ARTIQ] some comments about artiq_gui

On 08/24/2015 10:40 PM, Tan, Ting Rei wrote: > 1. Separate dock for argument editor > I don't see any conflict putting the submit button and options at either > location. For now, let's just put them with the explorer. Well, both options are bad. Putting them on the editor duplicates widgets and

Re: [ARTIQ] some comments about artiq_gui

On 08/24/2015 11:02 PM, Tan, Ting Rei wrote: > Well, we need to put them somewhere on the screen. To save screen place, I > would put them with the explorer, and the button will submit the experiment > highlighted in the explorer. I don't like that design. What is the use case for the multiple

[ARTIQ] management system/Git tutorial

Hi, I have written another "Getting started" tutorial that covers the management system including Git integration: http://m-labs.hk/artiq/manual/getting_started_mgmt.html It would be good if everyone participating in the discussions next week goes through it. Best, Sébastien

Re: [ARTIQ] ClockGen TTL

On 08/27/2015 09:18 AM, Neal Pisenti wrote: > What is the purpose of splitting out the `build` function (instead of > setting acc_width, etc. in the `__init__` method) It's an oversight. A previous device management mechanism used build() and I missed that one when refactoring. Thanks for reportin

Re: [ARTIQ] AD9914 support status and questions

Hi Raghu, thanks for your helpful information. The DDS is working now :) Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Using the analyze() pipeline

On 08/27/2015 04:20 AM, Tan, Ting Rei wrote: > The reason for this is we would like to see the GUI to be updated without > running the experiment. Then run "artiq_client scan-repository" manually. That doesn't run the experiment, and if you can edit Python scripts, you can use the command line.

[ARTIQ] API change: merger of results and parameters into "datasets"

Hi, ARTIQ now uses the single concept of "dataset" to manage the data exchanged with experiments, which we discussed briefly during the last visit. A dataset is created using the set_dataset() method of HasEnvironment, which takes a key/value pair. Its last arguments are flags that determine how

Re: [ARTIQ] ARTIQ API Changes :: python3.5, datasets, setattr_*

On 10/16/2015 12:05 PM, Joe Britton wrote: > Due to changes in conda deployment use the main build channel instead of > the dev channel. Actually you should have both right now. The main channel is for stable/released software that is manually built, while the dev channel is for automatically buil

Re: [ARTIQ] ARTIQ add-in architecture

On 10/19/2015 05:32 AM, Joe Britton wrote: > The present need (#146 ) to > organize the codebase This issue does not relate to the codebase organization, only to the conda packages. Sébastien ___ ARTIQ mailin

Re: [ARTIQ] API change: merger of results and parameters into "datasets"

On 10/21/2015 03:35 AM, Joe Britton wrote: > $ artiq_client does not have an option for specifying persistence flag It does: $ artiq_client.py set-dataset -h [...] -p, --persist make the dataset persistent ___ ARTIQ mailing list https://ssl.serverra

Re: [ARTIQ] logging and log levels within an experiemtn

On 10/21/2015 03:05 AM, Joe Britton wrote: > As it stands I gather that it's all logged but only the subset that > matches the Minimum level choice in the Log GUI is displayed. This > is good but insufficient for monitoring log messages of importance to > a particular debugging session. Especially

[ARTIQ] dataset type support

Hi, could you provide input on what types should be supported in the datasets? See: https://github.com/m-labs/artiq/issues/145#issuecomment-149405559 Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] ARTIQ hotkeys

Hi, What exactly should the hotkeys do in ARTIQ, and what are their use cases? As I understand, the idea is to assign hotkeys to experiments in the explorer, and pressing one will run the associated experiment with the arguments currently set for it in the right panel of the explorer. Are there

Re: [ARTIQ] ARTIQ hotkeys

On 10/24/2015 01:17 AM, Tan, Ting Rei wrote: > 2. Can be programmed as a 'panic button'. Where this experiment will > stop whatever that is running and put the system back to a 'safe' > state. How exactly should that work? Request graceful termination of all experiments in a pipeline associated wi

Re: [ARTIQ] ARTIQ hotkeys

On 10/24/2015 05:38 AM, Britton, Joe wrote: > * Submit Experiment :: Submit to scheduler new instance of whatever program > is selected in Explorer. > * use case is obvious > * Say, CTRL-S Done. > * Re-submit Experiment :: P is whichever program has focus in > Explorer. Request graceful

[ARTIQ] automated cancellations

On 10/25/2015 02:48 AM, Robert Jördens wrote: > "dequeue all instances" would do it. Then you can fire two shortcuts. Ok. I guess that would be "request graceful termination of all instances". Are there other "automated cancellation" features that would be nice to have? As you point out, clearin

Re: [ARTIQ] API change: merger of results and parameters into "datasets"

On 10/25/2015 11:55 PM, Joe Britton wrote: > Alternately, consider adding an option to set_dataset(timeseries=True). The filtering in artiq_influxdb already provides this feature. You can add a prefix or suffix to those datasets to be forwarded to InfluxDB, and configure filtering accordingly. >

Re: [ARTIQ] API change: merger of results and parameters into "datasets"

On 10/26/2015 02:27 AM, Joe Britton wrote: > Indeed, I could temporarily add a new entries to > influxdb_patterns.pyon. Presently, this requires stopping and > restarting artiq_influxdb which is problematic if a single influxdb is > used by multiple experiments. No, you can use artiq_rpctool (port

[ARTIQ] experiment restart

On 10/26/2015 12:14 AM, Joe Britton wrote: > A (key binding) way to > "clear the queue" (in some meaningful way without removing the default > experiment) or maybe to "dequeue all instances" would do it. Then you > can fire two shortcuts. > > > Good point. An alternative approach

[ARTIQ] influxdb filter setup

On 10/26/2015 09:30 AM, Sébastien Bourdeauducq wrote: > On 10/26/2015 02:27 AM, Joe Britton wrote: >> > Indeed, I could temporarily add a new entries to >> > influxdb_patterns.pyon. Presently, this requires stopping and >> > restarting artiq_influxdb which is probl

Re: [ARTIQ] ARTIQ shortcuts

Hi, On 10/24/2015 01:16 AM, Robert Jördens wrote: > On Fri, Oct 23, 2015 at 6:56 PM, Sébastien Bourdeauducq > wrote: >> What exactly should the hotkeys do in ARTIQ, and what are their use cases? >> >> As I understand, the idea is to assign hotkeys to experiments in the &

Re: [ARTIQ] ARTIQ hotkeys

On 10/24/2015 01:30 AM, Robert Jördens wrote: > Ting Rei could bind a single high-prio panic-experiment and have that > experiment clear the queue in whichever way it wants and do whatever > cleanup it desires. The scheduler now exposes the relevant APIs: http://m-labs.hk/artiq/manual/management_s

[ARTIQ] startup kernel

Hi, To provide more flexibility, the core device can now run a "startup kernel" stored in the flash when it boots. The startup kernel should perform operations such as initializing DDSes, putting bidirectional TTLs that are meant to be used semi-permanently as outputs into that mode, talking to t

[ARTIQ] multiple explorer docks vs. memos

Hello Ting Rei, Supporting multiple explorer docks poses a few problems that have to do with synchronizing them, making sure that at least one explorer stays open (or providing a user-friendly way to create a new explorer if they are all closed), and implementing potential interactions with the sc

Re: [ARTIQ] multiple explorer docks vs. memos

On 11/09/2015 11:34 PM, Tan, Ting Rei wrote: > The use case I was imaging for the multiple explorer is not > necessarily restricted to argument references. The way I would use it > is to use an explorer for 'run' and the other for 'analyze'. Would that be on the same experiment? Because in that ca

[ARTIQ] multiple log docks

Hi, the latest ARTIQ now supports having several log docks. New docks can be created via the right-click context menu. The GUI makes sure that at least one log dock stays open by showing close buttons on docks only when at least two are open. This requires a patched pyqtgraph: https://github.com

Re: [ARTIQ] Fwd: multiple explorer docks vs. memos

Hi, On 11/12/2015 05:32 AM, Robert Jördens wrote: > Can we separate the "explorer" (the file system-like tree) from the > "experiment" dock and make the entire thing behave more like a regular > application where you have one tree representation dock of your > "project" and at most one dock for ea

Re: [ARTIQ] precisions on GUI features

On 11/20/2015 11:00 AM, Britton, Joe wrote: > The use scenario is juggling a long-running experiment (over, say, > hours). From a data analysis perspective it's annoying to try to glue > together several datasets that were generated due to restarting (eg > to reschedule or change priority). This i

Re: [ARTIQ] precisions on GUI features

On 11/21/2015 08:26 AM, Robert Jördens wrote: > Alternatively, if buttons are really needed, they could become > part of the arguments of an experiment (e.g. pressing button "foo" of > a meta-experiment "Bar", does something like "Bar().build(foo=True)" > and then Bar can submit an appropriate expe

Re: [ARTIQ] precisions on GUI features

On 11/21/2015 04:35 AM, Britton, Joe wrote: > To be explicit, an experiment selected in the Explorer determines the > contents of two tabbed panes "Experiment Configuration" and > "Experiment Results" which show a list of e.g. Scan widgets and a > list of user-defined plots, respectively. The conte

Re: [ARTIQ] Fwd: Fwd: multiple explorer docks vs. memos

On 11/14/2015 08:32 AM, Robert Jördens wrote: >> That would only occur when the user selects the same experiment in at least >> two explorers. The synchronization is only about handling this corner case >> correctly. > > I don't see why that corner case needs to be supported. > Did that only becam

Re: [ARTIQ] November status report

On 11/24/2015 12:41 AM, Joe Britton wrote: > Thank you for the progress report. Some questions. > > Regarding 2), can you say more about the new MiSoC. What's new about > it? Essentially it was discussed here: https://github.com/m-labs/misoc/issues/17 > What does it mean for "builds to be out-of

Re: [ARTIQ] displays/plotting v2

On 11/24/2015 06:50 AM, Joe Britton wrote: >> * Each display is operated by one subprocess, which displays and manages one >> window on the screen. The window gets embedded into a pyqtgraph dock by >> artiq_gui. The embedding can be done with XEmbed on Unix, > > Will the subprocess have access to

Re: [ARTIQ] ARTIQ shortcuts

On 11/26/2015 11:34 AM, Robert Jördens wrote: > In many cases one just fires a calibration > or verification experiment without wanting a window to pop up then > having to close it again. What about using the shortcuts (which can have buttons in addition to the F-key mappings) instead of the explo

[ARTIQ] using Matplotlib in a ARTIQ GUI applet

Hi, Here is a simple example of how to use Matplotlib in a GUI applet, for people who prefer this plotting library. Note that Matplotlib is very slow compared to pyqtgraph, and on a low-end PC it will take a few seconds to update a simple plot. Use this command in the applets dock: /path/mat

[ARTIQ] turning experiment docks into MDI windows

Hi Ting Rei, what would you think about making the ARTIQ GUI look like this, with the experiment argument editors replacing the *.ui files: http://web.univ-pau.fr/~puiseux/enseignement/python/tutoQt-zero/images/10/fenetre-03.png The main differences with the pyqtgraph-based UI are: - experimen

Re: [ARTIQ] turning experiment docks into MDI windows

On Monday, February 15, 2016 11:09 PM, Slichter, Daniel H. wrote: My main question: how long would it take to change the GUI implementation over to this proposed model? Not long I believe, the code in ARTIQ is rather modular and so far my experience with those parts of Qt has been relatively h

[ARTIQ] ARTIQ-1.0 feature freeze

Hi, I think we are close to a point where we should make a stable branch of ARTIQ. The idea is to get a series of stable versions that contain a good set of features that at lab could use on a regular basis for a substantial period (>= 6 months), and that we would maintain (fix bugs) without

Re: [ARTIQ] ARTIQ-1.0 feature freeze

On Thursday, February 18, 2016 10:42 AM, Robert Jördens wrote: I am working on the PDQ2 related items. Yes, the PDQ2 is for 1.0 (and tagged accordingly in the issue tracker); AFAIK most labs need the PDQ? ___ ARTIQ mailing list https://ssl.serverrau

[ARTIQ] TTLInOut directions

Hi, On Friday, February 19, 2016 01:45 AM, Slichter, Daniel H. wrote: I haven't been able to test the clock generator (to look for phase slippage) because I can't get a signal from either the ClockGen pin AFAICT you are using the ClockGen correctly. Have you double-checked the gateware source

[ARTIQ] GUI working with conda packages

Hi, we have fixed all major problems with conda and Qt5. If you want to try out the new GUI, it should work with a regular ARTIQ installation as per the manual. Let me know of any problems. Sebastien ___ ARTIQ mailing list https://ssl.serverraum.org

Re: [ARTIQ] installing ARTIQ

Hi, On Tuesday, 15 March 2016 6:32:19 PM HKT Jonathan Mizrahi wrote: > I am trying to get ARTIQ installed on a Windows system using the KC705 > board, following the instructions > here. This has proven > difficult and frustrating (and not yet successf

Re: [ARTIQ] installing ARTIQ

On Wednesday, 16 March 2016 3:55:53 AM HKT Jonathan Mizrahi wrote: > Ah, adding the dev channel allowed me to install it. The installation > instructions say that the dev channel is only necessary to use the > development version of ARTIQ, so I had not added it. Well, there aren't any non-developm

<    1   2   3   4   >