Is there any way to get information from the computer to the core without pausing? I have a set of experiments that I want to perform concurrently with the precise tracking of a certain frequency. The architecture I have in mind is that every other experiment that I perform on an ion is used to check and update this frequency, and the intervening experiments are used to study some other physics of interest.

The challenge is that the frequency check must be performed with high regularity, every 5 ms or so. This means that I cannot ever call self.scheduler.pause, which uses up quite a bit more time, I think a second or so.

Is there any way that I can load information from the computer into a buffer that the core can then check sometime later?

For example, lets say that I just want to send a single bit to the core. It could mean run the experiment, gracefully terminate, etc. One way to do it without pausing the scheduler, is to run one of my OUTPUT TTLs right into an INPUT TTL. The core regularly checks the status of this input TTL, if it finds it HIGH, it performs some action. Then, when I want to trigger said action, I open the TTL pane in the dashboard, toggle the override for the OUTPUT that runs to the input, and then change the state.

It works, but I'd like something better if possible.

Is calling get_dataset from the kernel too slow?

First of all, I can't call it from the kernel. Keeps complaining about unifying the return type regardless of how I type it. I assume I must actually have get_dataset in an RPC that declares its return type, correct?

Anyway, doing that, and running a script that collects photons from the PMT (forcing the timeline up), then gets a dataset, and then immediately sets a DDS, throws slack errors ranging from 3-10 ms.

This is workable- I could throw it in an error catcher and just keep trying until the get happens to fit within 5 ms and works successuflly.

What if I only had 1 ms to work with, as is the case in another script I am working on... any suggestions there?

I just tried having one rpc function that simply returns a class variable self.var. This function is called from core repeatedly. It takes only 2-3 ms. Then I have another asynchronous rpc that gets a dataset and updates self.var accordingly. Unfortunately, the changes that the asynchronous rpc makes to self.var don't ever seem to be noticed by the other rpc function. I knew they wouldn't directly be noticed on the core, but I thought RPC's might at least share class variables amongst each other.

    dreens Unfortunately, the changes that the asynchronous rpc makes to self.var don't ever seem to be noticed by the other rpc function.

    There may be a race condition where the other RPC runs before the asynchronous one.

    Yes, get_dataset can return several different Python types, so you need to wrap it in a function with an annotation of the expected type before using it in a kernel.

      3 months later

      so regarding getting information from computer to core without pausing... its not really possible without locking up execution for a few milliseconds, correct? Would a faster NIC help here?

      It is possible in theory but with additional ARTIQ features that have not been developed. A different NIC is unlikely to help.