Minimal example of a shot?

[jondoesntgit]

Hello all,

I'm trying to get my feet wet with a minimal working example:

from labscript import start, stop
from labscript_devices.PineBlaster import PineBlaster
from labscript_devices.NI_DAQmx.models.NI.PCIe_6363 import NI_PCIe6363

PineBlaster(name='pb', usbport='COM4)
NI_PCIe_6363(name='ni6363', parent_device=pb.clockline, clock_terminal='PXI1Slot18/PFIO', MAX_name='PXI1Slot18', acquisition_rate=1e3)

start()
stop(1)

When I load this up in blacs and run it, right above the shot queue, I get a bit of text that says "Running (program time: 0.081s)... 2021-08-19_0040_connection_table_0.h5" that never updates.

On Blacs, I have a green checkmark next to the my NI 6363 window, and on the Pineblaster window I get an alternating green check mark and hourglass sign. The status at the bottom of the pine blaster window alternates between "Buffered mode - State: status_monitor (main_worker)" and "Buffered mode - State: idle"

It doesn't seem like the shot ever completes... I expected it to complete after doing nothing for one second, and then for me to be able to look at some output file in RunViewer. Does anyone have any advice on what the actual behavior should be?

Is it a problem if there is no physical clockline connecting the PineBlaster and the NI 6363?

[philipstarkey]

Hi Jonathan, I suspect you will need at least one output on the NI card and to actually do something with the channel between start and stop (e.g. go high, then low for a digital channel)

The failure mode you are seeing suggests no instructions have been programmed into the pineblaster and it probably doesn't report end of experiment status correctly under those circumstances - thus getting stuck indefinitely.

[jondoesntgit]

Good suggestions. Will troubleshoot tomorrow and report back on the results.

…

On Aug 19, 2021, at 3:57 PM, Phil Starkey ***@***.***> wrote:  Hi Jonathan, I suspect you will need at least one output on the NI card and to actually do something with the channel between start and stop (e.g. go high, then low for a digital channel) The failure mode you are seeing suggests no instructions have been programmed into the pineblaster and it probably doesn't report end of experiment status correctly under those circumstances - thus getting stuck indefinitely. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[dihm]

Jonathan,

As a quick side note, you'll actually need to use two DAQ channels due to how the DAQmx labscript class works. Luckily that is described fairly well via an error when the script is compiled.

[jondoesntgit]

Ok, here is the updated connection table and code:

from labscript import start, stop, AnalogOut, DigitalOut
from labscript_devices.PineBlaster import PineBlaster
from labscript_devices.NI_DAQmx.models.NI_PCIe_6363 import NI_PCIe_6363

PineBlaster(name='pb', usbport='COM4')
NI_PCIe_6363(name='ni6363', parent_device=pb.clockline, 
    clock_terminal='/PXI1Slot18/PFI0', MAX_name='PXI1Slot18', acquisition_rate=1e3)

DigitalOut(name='pin_a', parent_device=ni6363, connection='port0/line9')
DigitalOut(name='pin_b', parent_device=ni6363, connection='port0/line10')

start()
t=0
pin_a.go_high(1)
pin_a.go_low(2)
stop(3)

I still get the same problem. The only difference now is that it hangs at "Running (program time: 5.098s)..." above the shot queue.

Note that there is currently no wire connecting the pine blaster to the NI 6363 PFI0 port. Please advise if this is a problem.

[chrisjbillington]

Hi Jonathan, Your script looks fine, I can't see anything you're doing wrong. The lack of a clockline connection on the NI DAQ will result in an error at the end of the shot - saying "not enough edges received, check that it's plugged in" or similar - but you're not getting that far yet! Sounds like an issue with the pineblaster. It should: a) not take 5 seconds to program a couple of instructions (though that's not necessarily the PineBlaster, could be something else in BLACS being slow) and b) tell BLACS when a shot has finished. Does the PineBlaster's output go high and low in manual mode, if you click the button in the BLACS GUI? You could also test the pineblaster works via e.g the serial monitor in the Arduino IDE (or any other interactive serial interface). The commands it supports and an example program you could program into it manually can be found in the README in its repository: https://github.com/labscript-suite/pineblaster The BLACS worker code for the device ( https://github.com/labscript-suite/labscript-devices/blob/master/labscript_devices/PineBlaster.py) is not super complex, and is peppered with asserts checking that the pineblaster is responding as expected, which would seem to rule out it being completely broken. If you modify your local copy to add printlines, perhaps you can work out which aspect of the programming is slow - this output will be visible in the pineblaster's BLACS tab's output pane (the terminal icon in the top right of the tab). You might want to verify that the device knows it is the master pseudoclock (self.is_master_pseudoclock in transition_to_buffered). There was a change in h5py not long ago that has modified the type of strings returned from datasets, causing some issues for us such as labscript-suite/labscript-devices#85. So although this is probably not related to the issue you're having, it's at the top of my mind at the moment to be on the lookout for strings coming out of HDF5 files being the wrong datatype - so perhaps keep that in mind if you're debugging! Hope that helps and let me know how you go, Chris

…

On Sat, 21 Aug 2021 at 04:43, Jonathan Wheeler ***@***.***> wrote: Ok, here is the updated connection table and code: from labscript import start, stop, AnalogOut, DigitalOutfrom labscript_devices.PineBlaster import PineBlasterfrom labscript_devices.NI_DAQmx.models.NI_PCIe_6363 import NI_PCIe_6363 PineBlaster(name='pb', usbport='COM4')NI_PCIe_6363(name='ni6363', parent_device=pb.clockline, clock_terminal='/PXI1Slot18/PFI0', MAX_name='PXI1Slot18', acquisition_rate=1e3) DigitalOut(name='pin_a', parent_device=ni6363, connection='port0/line9')DigitalOut(name='pin_b', parent_device=ni6363, connection='port0/line10') start()t=0pin_a.go_high(1)pin_a.go_low(2)stop(3) I still get the same problem. The only difference now is that it hangs at "Running (program time: 5.098s)..." above the shot queue. Note that there is currently no wire connecting the pine blaster to the NI 6363 PFI0 port. Please advise if this is a problem. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#80 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH64567WVOKPHABQTIYSBTT52O5XANCNFSM5COZ25HA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[jondoesntgit]

Does BLACS automatically program the PineBlaster? Or do I need to download shot instructions to the PineBlaster manually using something like MPIDE?

[jondoesntgit]

I see the code where BLACS automatically programs the PineBlaster. It looks like those commands are making it to the device.

I opened up the Arduino serial monitor and entered this example program to the device:

set 0 4 3
set 1 10 1
set 2 0 0

After each instruction gets programmed, the PineBlaster responds with ok. When I type start it says ok and then nothing else.

The PineBlaster then becomes unresponsive. I have been able to get it to be responsive again by closing the serial monitor, reopening it, typing reset, and waiting. Sometimes this doesn't work, and I try a random combination of start, reset, hello, return, and reopening the serial monitor, and eventually it works.

Both of these programs work:

set 0 0 0

set 0 4 1
set 1 0 0

but this program does not

set 0 4 2
set 1 0 0

[jondoesntgit]

This program also does not work

set 0 4 1
set 1 4 1
set 2 0 0

it starts with "ok" and then hangs.

[jondoesntgit]

I can manually toggle the Pineblaster’s output on pin 5 by clicking on the BLACS interface.

[chrisjbillington]

Great, thanks for the debugging.

Pretty clear that the PineBlaster is at fault. Remaining issues could be a hardware fault, or the PineBlaster's firmware.

Could you verify that the correct MPIDE version was used to program it, and that compiler optimisations were disabled, both as described in the REAMDE?

I don't have a PineBlaster at hand, but perhaps someone with one could verify whether the current setup instructions and available MPIDE downloads still work (I see you added a bug report about a broken link to MPIDE).

If you've followed all the instructions correctly, then the remaining explanations are a) hardware failure or b) MPIDE has been updated without a version number bump, or behaves differently on your system compared to those others are using (or have used in the past) in a way that breaks the PineBlaster's firmware.

Long shot but it could also be a hardware failure of something else, like the USB controller. But not many other possibilities!

[philipstarkey]

In case you don't want to debug why the PineBlaster isn't working, you might want to consider purchasing a $4 raspberry pi pico board instead and using it as a PrawnBlaster instead. We haven't done much in the way of maintenance for keeping up with the compilation of the PineBlaster code and the PrawnBlaster should be superior to the PineBlaster due to it's newer hardware.

[jondoesntgit]

@chrisjbillington I wasn't the one who flashed this device originally, so I can't speak to how it was done. If someone can point me to a suggested version of MPIDE (current link is broken), I can try to re-flash the device.

@philipstarkey I've ordered a Pico, and it should arrive later this week. Thanks for the tip.

[jondoesntgit]

Using the Raspberry Pi Pico solved the problem. The only issue that I encountered is that the PrawnBlaster code isn't included in the conda channel yet, so I grabbed it from a Github clone.

Thanks!