Questions from a labscript noob

[Kelsey Justis]

Labscript>

-Can I create multiple connection tables (for various experiments or in my specific case testing a single device at a time rather than cumulatively)?

--If so, can I choose these in BLACs menu some how? ( like a field for connection table selection of possible tables created?)

-When trying to create a stop() call, I have not been able to call on t's current value, as in "stop(t+1)". To avoid tallying up t is there a way to do endtimet = get(t) to avoid say stop(31)? 

PulseBlaster>

- What is "board_number" in "# Create a pulseBlaster object connected to port 0 on??

PulseBlaster_SP2_24_100_32k(name='pulseblaster_0', board_number=0)"

--What does this refer to?

- What' s the bit about the fast clock vs the slow clock?

--Or more to the point, what devices/situations do you guys use this for? 

--Can I have multiple fast clocks?

PineBlaster>

-Do you guys use this to trigger the PCI-6733?

--If so, how do you guys connect this? (we are currently looking at the RTSI connection ports for using a masterclock signal, but the documentation for the PCI-6733 is not clear enough ,to me at least, on how this is done. We hope to sync this and other devices with the pineBlaster)

NI USB-6343

-What is the labscript naming convention for ports on this device? I am currently trying to use a clock signal from the pulseblaster as input in port 73 ("PFI 0/P1.0") and get a basic sine wave out of port 65(P0.0) without much luck. I keep getting errors in BLACs telling me the port is not found for the clockline port I insert in the "clock_terminal" parameter of the NI_PCI_6733 object creation. In short what are the port names? will port 1 thru 128 work for this device?

-Not software related, but there are obviously a lot of ports on this device. We intend to use many of them. Do you guys have a pretty/neat solution/cable on getting these ports out of the case?​ 

General>

-Do you guys have open source code for experiment logic you guys uses as an example? I was hoping to look at code for various experiments and learn what best practices are in connecting these devices to labscript.

- Any learning curves/problems that may be avoided in doing any of the above initial setup?

Thank you all for any help on these answers. 

[Chris Billington]

Hi Kelsey,

Apologies for not getting back to you earlier.

On Tue, Apr 28, 2015 at 7:28 AM, Kelsey Justis <kelsey....@gmail.com> wrote:

Labscript>

-Can I create multiple connection tables (for various experiments or in my specific case testing a single device at a time rather than cumulatively)?

--If so, can I choose these in BLACs menu some how? ( like a field for connection table selection of possible tables created?)

 

At the moment the connection table isn't settable from any GUI, it's only able to be set from your 'labconfig' file (should be <labscript_suite_directory>/labconfig/<your computer's hostname>.ini). You can certainly have multiple connection tables, and when you want to switch, change the path in the labconfig file (by commenting and uncommenting, makes it easier), and then restart BLACS to use the new connection table. Generally I don't see the need for multiple connection tables when you're actually running experiments (as the connection table should only change when your devices an their connections to each other change, and then once they change they're unlikely to change *back*), but it seems sensible enough for testing as you said.

 

-When trying to create a stop() call, I have not been able to call on t's current value, as in "stop(t+1)". To avoid tallying up t is there a way to do endtimet = get(t) to avoid say stop(31)? 

There isn't unfortunately. Typically we keep track of a t variable thoughout our scripts, declaring t = 0 at the start of a labscript script, always making calls to command output at time t,  and doing t += some_value whenever we want a delay. All the ramp methods return how long they take. For example:

  1 
from labscript import *
  2 
 
  3 
from labscript_devices.NI_PCI_6733 import NI_PCI_6733
  4 
from labscript_devices.PulseBlaster import PulseBlaster
  5 
 
  6 
 
  7 
# The below just lets us run outside of runmanager for the sake of this example:
  8 
labscript_init('test.h5', new=True, overwrite=True)
  9 
delay_time = 2
 10 
ramp_duration = 3
 11 
final_hold_time = 0.1
 12 
 
 13 
 
 14 
# Connection table:
 15 
PulseBlaster('pulseblaster_0')
 16 
 
 17 
ClockLine('ni_card_clockline', pulseblaster_0.pseudoclock, 'flag 1')
 18 
NI_PCI_6733('ni_card_0', ni_card_clockline, clock_terminal='/ni_pcie_6363_0/PFI0', MAX_name='ni_pci_6733_0')
 19 
AnalogOut('ao0', ni_card_0, 'ao0')
 20 
AnalogOut('ao1', ni_card_0, 'ao1')
 21 
 
 22 
 
 23 
# Experiment begins:
 24 
start()
 25 
 
 26 
t = 0
 27 
ao0.constant(t=t, value=2)
 28 
 
 29 
t += delay_time
 30 
ao0.constant(t=t, value=7)
 31 
t += ao1.ramp(t=t, duration=ramp_duration, initial=0, final=10, samplerate=1000)
 32 
 
 33 
t += final_hold_time
 34 
stop(t)

 

PulseBlaster>

- What is "board_number" in "# Create a pulseBlaster object connected to port 0 on??

PulseBlaster_SP2_24_100_32k(name='pulseblaster_0', board_number=0)"

--What does this refer to?

The board number refers to what number needs to be given to the Spincore API function pb_select_board() to identify the PulseBlaster, in the case that there are multiple ones connected to the same computer. If you only have one PulseBlaster, the board number is zero. If you have multiple ones, it depends on which USB port or PCI slot each one is in.

 

- What' s the bit about the fast clock vs the slow clock?

--Or more to the point, what devices/situations do you guys use this for? 

--Can I have multiple fast clocks?

Fast and slow clocks is a feature, now deprecated, that allowed us to have a rapidly updating device and a slowly updating device share a clocking signal, sort of. The 'fast clock' ticks rapidly during all function ramps, whereas  the 'slow clock' only ticks once at the start and the end of a ramp. This way an analog output could do a ramp, and a device connected to the same PulseBlaster, which did not need to ramp at that time in the experiment, would not need to have all the redundant samples for all those clock ticks. This was to support having devices with high memory (like National Instruments DAQ devices) and ones with smaller memory (like the NovaTech DDS devices) connected to the same PulseBlaster. If the Novatech DDS had to have a line in its output table for every point the NI DAQ was producing, it would run out of RAM.

This feature has been abandoned in favour of 'gated clocks' instead. Now, PulseBlasters in labscript are capable of producing multiple clocking signals. While the clock ticks, if any, coming out of all clock outputs must be the same, they are 'gated', such that if no outputs connected to a 'clock line' is changing in some interval of time, no clocking signal is produced. Devices with different memory capabilities can be put on different 'clock lines', whereas similar ones can share a ClockLine. The example code I posted above demonstrates how to do this—lines 17 and 18 show how to instantiate a ClockLine and connect a device to it.

If you have a version of labscript that talks about fast and slow clocks, then it is somewhat out of date and I would recommend updating. The above code won't work on your version and there been many improvements! If perchance you've not updated since we made an installer, we have an installer now, and the install process is much simpler.

 

PineBlaster>

-Do you guys use this to trigger the PCI-6733?

--If so, how do you guys connect this? (we are currently looking at the RTSI connection ports for using a masterclock signal, but the documentation for the PCI-6733 is not clear enough ,to me at least, on how this is done. We hope to sync this and other devices with the pineBlaster)

You can specify any terminal which is capable of triggering output ('clock_terminal' keyword argument, line 18 above). I'm not sure which ones are allowed for any given card, but certainly PFI0 is. You can see in our example, we've actually told an NI-PCI-6733 to output when digital edges arrive on a terminal on a *different NI device*, a PCIe 6363. The NI DAQ library reroutes things internally to make this possible, magically. So the two NI cards in our experiment share a clocking signal in this way. But one could equally just split the clocking signal and connect it to a PFI on the two devices individually. So if you were just using the 6733 above, you would instead have clock_terminal='/ni_pci_6733_0/PFI0', and connect the PulseBlaster clock output to PFI0 on the 6733.

We don't actually use the PineBlaster day to day, but we've tested it in the above configuration.

 

NI USB-6343

-What is the labscript naming convention for ports on this device? I am currently trying to use a clock signal from the pulseblaster as input in port 73 ("PFI 0/P1.0") and get a basic sine wave out of port 65(P0.0) without much luck. I keep getting errors in BLACs telling me the port is not found for the clockline port I insert in the "clock_terminal" parameter of the NI_PCI_6733 object creation. In short what are the port names? will port 1 thru 128 work for this device?

The strings you pass into labscript specifying the channel names are passed directly to the NI DAQmx library. So whatever names work in LabVIEW should work in labscript. Typically the digital outputs look like "port0/line0", 'port0/line1' etc and the analogs look like 'ao0', 'ao1' etc. How many 'lines' there are on a 'port' varies from device to device and you would have to check the documentation for the specific device. If you run the the NI Measurement and Automation Explorer, it should let you play around with the different outputs manually and see which corresponds to which. You can also give the channels specific names there if you want, and if you do, you can use those names in labscript code. The above example code should produce a linear ramp on the ao1 channel of the NI PCI 6733. 

 

-Not software related, but there are obviously a lot of ports on this device. We intend to use many of them. Do you guys have a pretty/neat solution/cable on getting these ports out of the case?​ 

I wouldn't say it's terribly pretty or neat, but we've made some breakout boxes for digital outputs on the PCIe-6363. Attached is a picture:

We inserted pins into the digital output port and soldered them onto some connector which we could attach a ribbon cable to, and just put a whole bunch of BNC connectors in a box. What we did is not ideal because we don't have a ground next to every line. The ribbon cable has all the digital lines in the middle and a ground on each end or something. So there is potential for cross talk between the lines. What would be better is if every line was in a twisted pair with a ground. So what we have done is not ideal.

The USB 6343 is in use in a different lab, and when I was there I don't think they were using a breakout box, just wires inserted individually into the output ports. I think. But it depends how many you're going to use and how much effort you want to go to. NI may or may not sell an expensive breakout box for any particular device. 

 

General>

-Do you guys have open source code for experiment logic you guys uses as an example? I was hoping to look at code for various experiments and learn what best practices are in connecting these devices to labscript.

We don't at present. Any code for doing an actual experiment ends up being pretty complex, It's hard to make self contained examples. But, just as an example I've attached an experiment script of ours, which is about cooling and trapping both rubidium 87 and potassium 41, and making a BEC with the rubidium. We never got as far as condensing the potassium. It might not make much sense but should demonstrate the coding style that kind of naturally evolves using a system like this! It's a bit messy of course.

- Any learning curves/problems that may be avoided in doing any of the above initial setup?

Not sure! There's the fact that if you find yourself without a connection table .h5 file, BLACS won't start, and so you'll have to compile it with runmanager at first (BLACS will then happily 'recompile' in future, so long as a .h5 file is there when it starts). I'm not sure what else.  

Thank you all for any help on these answers. 

No problem, and post back if you find other things you'd like to know about. 

Cheers,

Chris

--

Chris Billington
School of Physics
Monash University
Victoria 3800, Australia
Ph: +61 423952456

[Kelsey Justis]

Hi Chris,

Thank you very much for all of your help these answers will help a lot in getting the control system off the ground here. If I can be of any help for you guys please let me know; I am currently documenting this entire process ( i have some individual .py test files for each device tested/ing) and hope this documentation will be useful for your group and others.

I have another question. When trying to use the installer for the new version of Labscript I came across 2 issues: 1) the installer told me it could not find the optional dependency, "PyDAQmx" (although it is present where the other dependencies may be found); 2) I cannot open BLACS; I have been able to open Runmanager and compile the required connection table, and have checked the config file and tried reinstalling the entire program upon deleting the current folders and restarting. 

The second issue is of greater concern; have you all come across this?

Thank you for your help!

Best,

Kelsey

--
You received this message because you are subscribed to a topic in the Google Groups "The labscript suite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/labscriptsuite/pueMnUvv0hk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to labscriptsuit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kelsey Justis]

Hi Chris,

This issue is resolved. Professor Wright helped me identify the issue as one existent with the python path enviroment variable. It seems that when uninstalling/deleting the old version of Labscript I did not clear this variable or modify it. Thus, when installing the new version and trying to open BLACS we encountered error where BLACS wanted a more up to date version of the Labscript_utils but found only the older version referenced by the python path enviroment variable.

Other issues encountered include a required update of zprocess for LYSE.

Thank you for your continuing help.

Best,

Kelsey

[Kelsey Justis]

Hi all, 

A couple of things. I have been trying two new tests (individual scripts), one with a Novatech 409B (clocked by pulseblaster) and triggering the pineblaster with the pulseblaster.

On the novatech 409B:

-Is the novatechDDS9M class well suited for the 409B? (I see that in the class the baudrate is assigned 115000 rather than the needed 19200 for the novatech 409B); Should I write a class for this device?

On the pineblaster:

-I kept getting the error:

"

1. Traceback (most recent call last):

2.  File "C:\labscript_suite\labscript_devices\PineBlaster.py", line 277, in transition_to_buffered

3.    device_properties = labscript_utils.properties.get(hdf5_file, self.name, 'device_properties')

4. AttributeError: 'PineblasterWorker' object has no attribute 'name'"

Which has been fixed by making a modification in PineBlaster.py class file in line 277

- device_properties = labscript_utils.properties.get(hdf5_file, device_name, 'device_properties')# Changed "self.name" to "device_name".

- I am now getting a new error:

1. Exception in worker - Fri May 22, 13:43:57 :

2. Traceback (most recent call last):

3.  File "C:\labscript_suite\labscript_devices\PineBlaster.py", line 320, in transition_to_manual

4.    assert response == 'done\r\n', 'PineBlaster said \'%s\', expected \'ok\''%repr(response)

5. AssertionError: PineBlaster said '''', expected 'ok'

7. Fatal exception in main process - Fri May 22, 13:43:57 :

8. Traceback (most recent call last):

9.  File "C:\labscript_suite\blacs\tab_base_classes.py", line 670, in mainloop

10.    next_yield = inmain(generator.send,results)

11.  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 68, in inmain

12.    return get_inmain_result(in_main_later(fn,False,*args,**kwargs))

13.  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 47, in event

14.    result = event.fn(*event.args, **event.kwargs)

15.  File "C:\labscript_suite\blacs\device_base_class.py", line 627, in transition_to_manual

16.    raise Exception('Could not transition to manual. You must restart this device to continue')

17. Exception: Could not transition to manual. You must restart this device to continue

From BLACS which always occurs (despite the length of the run) at the end of the run. I suspect the check done to see if the pineblaster has completed its work needs to be after the stop call or I need to send a command stopping the pineblaster. Have you guys experienced this error? I have attached the connection table/experiment logic .py file I am using for this test with the updated (as of last Friday) labscript.

Also, Professor Wright and I have been wondering how you guys prefer updates on bugs or new work/documentation to be handled. Should we continue to send periodic emails? or move towards a joint repository for commits?

Thank you for all your help, I hope this week has been a great one for you all.

Best,

Kelsey

--

[Philip Starkey]

Hi Kelsey,

On Saturday, 23 May 2015 04:59:18 UTC+10, Kelsey Justis wrote:

Hi all, 

A couple of things. I have been trying two new tests (individual scripts), one with a Novatech 409B (clocked by pulseblaster) and triggering the pineblaster with the pulseblaster.

On the novatech 409B:

-Is the novatechDDS9M class well suited for the 409B? (I see that in the class the baudrate is assigned 115000 rather than the needed 19200 for the novatech 409B); Should I write a class for this device?

 

It looks like the 409B is basically the same board as the DDS9m, but in a box (at least based on this document). However, it looks like only the 409B-AC has the required connections for external table mode triggers. Do you have the 409B-AC?

You will also want to check out this blog post, where our group details how we use a single clock signal with a "table enable" digital line to step the Novatech through the table. This is our preferred method of clocking it. However, Chris, did add an additional mode for use at NIST, which is enabled by the update_mode='asynchronous' keyword argument when the device is instantiated in labscript. I'm not familiar with the hardware configuration required to use that mode though, but hopefully Chris will fill in the gaps shortly!

The baud_rate can be set in labscript with the baud_rate=19200 keyword argument. Unfortunately it looks like you can't force your model to stay at 115200 (the DDS9m has an internal jumper to change it), so programming times will likely be slower.

We generally advocate that you create new labscript_devices classes (with appropriate names) for different models. However, since the behaviour is identical between the dds9m and 409b, you can just subclass the existing dds9m classes but not override any methods. If you later find that something behaves differently, it is easy to correct the functionality in the subclass without affecting the original. A good example of this is the PulseBlaster_No_DDS and the PulseBlasterUSB devices. The only tricky part with doing this is that you have to make sure the correct class for the BLACS worker process is chosen. This is the reason for the use of self.device_worker_class in this line, this line, and this line in the PulseBlaster classes. We'll be happy to elaborate more on this if you'd like.

On the pineblaster:

-I kept getting the error:

"

1. Traceback (most recent call last):

2.  File "C:\labscript_suite\labscript_devices\PineBlaster.py", line 277, in transition_to_buffered

3.    device_properties = labscript_utils.properties.get(hdf5_file, self.name, 'device_properties')

4. AttributeError: 'PineblasterWorker' object has no attribute 'name'"

Which has been fixed by making a modification in PineBlaster.py class file in line 277

- device_properties = labscript_utils.properties.get(hdf5_file, device_name, 'device_properties')# Changed "self.name" to "device_name".

Yep, looks like a bug introduced when some code was copy/pasted between classes. Your fix is correct!

 

- I am now getting a new error:

1. Exception in worker - Fri May 22, 13:43:57 :

2. Traceback (most recent call last):

3.  File "C:\labscript_suite\labscript_devices\PineBlaster.py", line 320, in transition_to_manual

4.    assert response == 'done\r\n', 'PineBlaster said \'%s\', expected \'ok\''%repr(response)

5. AssertionError: PineBlaster said '''', expected 'ok'

7. Fatal exception in main process - Fri May 22, 13:43:57 :

8. Traceback (most recent call last):

9.  File "C:\labscript_suite\blacs\tab_base_classes.py", line 670, in mainloop

10.    next_yield = inmain(generator.send,results)

11.  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 68, in inmain

12.    return get_inmain_result(in_main_later(fn,False,*args,**kwargs))

13.  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 47, in event

14.    result = event.fn(*event.args, **event.kwargs)

15.  File "C:\labscript_suite\blacs\device_base_class.py", line 627, in transition_to_manual

16.    raise Exception('Could not transition to manual. You must restart this device to continue')

17. Exception: Could not transition to manual. You must restart this device to continue

From BLACS which always occurs (despite the length of the run) at the end of the run. I suspect the check done to see if the pineblaster has completed its work needs to be after the stop call or I need to send a command stopping the pineblaster. Have you guys experienced this error? I have attached the connection table/experiment logic .py file I am using for this test with the updated (as of last Friday) labscript.

 

Hmm, this appears to be a bigger bug. It is related to the use of set_initial_trigger_time. The length of the pineblaster sequence is not being modified to take into account the late trigger. So while clock signals from the PineBlaster are output at the correct time, the last clock tick runs for too long (the length of the initial trigger time) and the pineblaster is non responsive until this amount of time after the sequence has finished. I suspect this is not a PineBlaster issue, but rather a PseudoClock issue deep within labscript. I'll try and look into it soon. Are you able to just trigger everything at t=0 to avoid the issue for now? Or do you need to trigger later for some reason?

Also, Professor Wright and I have been wondering how you guys prefer updates on bugs or new work/documentation to be handled. Should we continue to send periodic emails? or move towards a joint repository for commits?

 

Good question! We'd encourage you to report bugs on the issue tracker on our bitbucket repositories if you like. This makes it easier to keep track of what needs fixing!

As for collaborating on code, the best approach we have come up with is for other groups to fork all of our repositories on bitbucket. You then develop in, and run from these forks in your lab. Changes you make locally on your lab/development computers can be pushed to your fork because you own it. Once a change has been tested and debugged, you can then make a "Pull request" (from bitbucket) to have changes included in the master repository. This allows you to do lab specific development without affecting everyone else using the suite, while also providing a pathway to get your modifications included in the main distribution.

We'll probably create a developer mailing list soon so that major changes (that are expected to be merged back into the master repository) can be discussed before they are done, but in the mean time, feel free to start discussions here if you plan on making a significant change to one of the components of the suite and want some feedback on the proposal.

Let us know if you have further questions about this process (we've only recently switched to this workflow so there are bound to be things we haven't thought about yet!)

Cheers,

Phil Starkey 

[Philip Starkey]

A quick update on my last post:

I think I've fixed the PineBlaster bug (which it turns out we've known about for a while, we just didn't realise it was so critical) in my own fork of labscript. I've made a pull request here, so hopefully it will be included in the main repository soon! While we wait for the fix to be reviewed, feel free to try it out on your system and see if it resolves the PineBlaster issue.

Cheers,

[Kelsey Justis]

Phil,

 You are awesome!

Thank you.

I am testing all of these updates, and will let you know how it goes.

Best,

Kelsey

--

[Kelsey Justis]

Hey Phil,

I may have implemented this wrong, but I am not sure the fix worked. I saved the raw file pointed to as the current labscript.py. After checking the folder this file is contained in, seeing the changes are in fact made, and restarting the both BLACS and Runmanager, I did not notice a change. I also tried the recommended change of the trigger time to 0 rather than the initial arbitrarily chosen value of 7. 

Are there other files I should be incorporating?

Checking the novatech advice now.

Thanks again for all of your help:)

[Kelsey Justis]

Using the baud_rate=19200 parameter works fine with the NovatechDDS9M class.

Thank you so much.

I have attached the file used to test this device.

Best,

Kelsey

[Philip Starkey]

Hi Kelsey,

If that fix for the PineBlaster didn't work, then it is likely there is another problem as well. Can you confirm with a oscilloscope:

• that the trigger from the PulseBlaster is actually being sent to the PineBlaster, and
  
• that the PineBlaster is subsequently outputting a clocking signal as expected (you can use runviewer [or check the PULSE_SEQUENCE table for the PineBlaster in the hdf5 file] to verify against what you see on the oscilloscope)

If the PineBlaster is not being triggered (either a missing trigger or the trigger not connected correctly to the right pins), then you would likely get the error you are seeing. Let me know if these diagnostics shed any insight!

Cheers,

Phil

P.S. I guess another potential issue is if you have multiple copies of labscript and the wrong one is being imported? You could diagnose that by adding a print line to the labscript.py you think you are using (the one with my bugfix in) and verifying the print statement appears in run manager.

[Kelsey Justis]

Hi Phil,

I'll try to check this out soon; the next day I work is Friday, but I'll try to go in tomorrow or Thursday.

Best,
Kelsey

[Kelsey Justis]

Hi Phil, 

I'm not sure how to check the labscript.py matter (unless what I did-- typed print "hello" on last line without indent in the assumed labscript.py file and checked runmanager's output console without results confirms this).

For the other tests:

-I see no indication of the pineBlaster receiving the trigger upon examining the oscilloscope.

-I have also attached a picture testing the .py file (also attached) in the way I think you suggested.

I apoligize if these tests are not done correctly; please let me know if this is what you meant.

Also, I should note that I have clockline 2 from the pulseblaster coming in to pin 3 on the pine blaster and out put from pin pin 5 on the pineblaster to the oscope.

Best,

kelsey

[Philip Starkey]

Hi Kelsey,

With the labscript.py test (where you put print 'hello' at the bottom of the file), do you see the text hello in the run manager terminal? It should show up in the terminal every time you click the restart subprocess button.

A couple of other things to investigate:

• In runviewer, is there actually a pulse showing at t=0 for the trigger? It doesn't show up in the screenshot you sent, but it should hopefully be there.
• It looks like you might need to debug the PulseBlaster a little first if you are not seeing the trigger on an oscilloscope. Looking at the compiled H5 file, I think the trigger pulse will be about 400ns long. This is quite short! So you will need to configure the oscilloscope timebase accordingly  (aka 100ns/div) and set it up to trigger on a rising edge to be able to see it.
• Does the trigger line plugged into the PineBlaster (PulseBlaster flag 2) change state (when looking at it on an oscilloscope) when you click the button (labelled flag 2) on the BLACS front panel (in manual mode)?
• The 400ns trigger may be too quick for the PineBlaster to see. Try experimenting with adding trigger_minimum_duration = 2e-6 into the labscript class for the PineBlaster in labscript_devices (see example below). You might want to try other numbers (I just made up the 2us number, I unfortunately have no idea what the minimum trigger duration is)

How to modify the PineBlaster class (in PineBlaster.py)

Below is part of the code from PineBlaster.py. I've highlighted the line to add, and where to add it with a comment.

@labscript_device     

class PineBlaster(PseudoclockDevice):

    description = 'PineBlaster'

    clock_limit = 10e6

    clock_resolution = 25e-9

    clock_type = 'fast clock'

    # Todo: find out what this actually is:

    trigger_delay = 1e-6

    # Todo: find out what this actually is:

    wait_delay = 2.5e-6

    allowed_children = [PineBlasterPseudoclock]

    trigger_minimum_duration = 2e-6             # <--- Add this line, and play with the number!

    max_instructions = 15000

Hopefully one of these ideas gives some more information! The main thing is to work out what is actually coming out of the PulseBlaster and PineBlaster (if anything) and debug from there.

Cheers,
Phil

[Kelsey Justis]

Hi Phil,

With the labscript.py test (where you put print 'hello' at the bottom of the file), do you see the text hello in the run manager terminal? It should show up in the terminal every time you click the restart subprocess button.

I tried this and did not get the expected result;  is there a system environment variable or some other address reference I can reset or change? 

I'm not sure if this info is useful, but the runmanager shortcut I am clicking references a runmanager subfolder of labscript_suite, which is the same folder the labscript folder, containing the labscript.py file modified is contained in, sub folders.

Nevermind. This is really strange, I restarted the computer just now and runmanager is giving expected result upon restarting subprocess and then pressing engage. (engage is required though; either pressed on their own does not output print)

I am now getting an error from both the pineblaster and pulseblaster where neither is responding and outputing the time of non-response; restarting the devices only resets these timers.

Device Manager (WIN 7 Pro) shows both devices in typical (nothing new changed in connection to computer) positions. I have also tried a seperate program (Termite) to test that the pineBlaster does in fact respond as expected to the "hello" command.

I am currently unable to complete tests below. 

A couple of other things to investigate:

• In runviewer, is there actually a pulse showing at t=0 for the trigger? It doesn't show up in the screenshot you sent, but it should hopefully be there.

• Unfortunately, the screen shot sent is what I had; I'll try another screen shot after the next suggestions.

• It looks like you might need to debug the PulseBlaster a little first if you are not seeing the trigger on an oscilloscope. Looking at the compiled H5 file, I think the trigger pulse will be about 400ns long. This is quite short! So you will need to configure the oscilloscope timebase accordingly  (aka 100ns/div) and set it up to trigger on a rising edge to be able to see it.

• I see nothing :/.

• Does the trigger line plugged into the PineBlaster (PulseBlaster flag 2) change state (when looking at it on an oscilloscope) when you click the button (labelled flag 2) on the BLACS front panel (in manual mode)?

• No.

• The 400ns trigger may be too quick for the PineBlaster to see. Try experimenting with adding trigger_minimum_duration = 2e-6 into the labscript class for the PineBlaster in labscript_devices (see example below). You might want to try other numbers (I just made up the 2us number, I unfortunately have no idea what the minimum trigger duration is)

• Where does this variable get used? What Range of values/magnitudes would you suggest; I tired a few 1-9 nano and milliseconds as values with no results.

I've attached a picture of the error I keep seeing in BLACs; I feel kind of lost on where to search for this error.

Thank you for all your help.

Sincerely,

Kelsey

[Philip Starkey]

Hi Kelsey,

I'm sorry to hear there are now more issues :(

Given the print issue (before the restart) and the current state of BLACS since the restart, I suspect there is something wrong with python paths and the versions of libraries the labscript suite software is using.

Could you please close BLACS, reopen BLACS, wait until the tabs say "not responding", Close BLACS again and then post the BLACS.log file (should be in the BLACS folder). That will give me a better idea of what is wrong hopefully.

Cheers,
Phil

[Kelsey Justis]

​

 BLACS.log

​I left the lab earlier (hence this late message).

Before I left, I commented out the line suggested for addition in PineBlaster.py, removed the print 'hello ' line in labscript.py, and changed my connection table to test other devices without pineblaster as part of the connection table.

Now That I returned I notice now the error is not popping up. So I uncommented your suggested line and restarted both BLACs and runmanager, now I am able to toggle the flag2 on the pulseblaster and see a change on the oscope, but when I run the same .py file from before, I am getting an old error from the pineBlaster:

Exception in worker - Mon Jun 01, 20:37:41 :

Traceback (most recent call last):
  File "C:\labscript_suite\labscript_devices\PineBlaster.py", line 320, in transition_to_manual
    assert response == 'done\r\n', 'PineBlaster said \'%s\', expected \'ok\''%repr(response)
AssertionError: PineBlaster said '''', expected 'ok'

Fatal exception in main process - Mon Jun 01, 20:37:41 :

Traceback (most recent call last):
  File "C:\labscript_suite\blacs\tab_base_classes.py", line 670, in mainloop
    next_yield = inmain(generator.send,results)
  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 68, in inmain
    return get_inmain_result(in_main_later(fn,False,*args,**kwargs))
  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 47, in event
    result = event.fn(*event.args, **event.kwargs)
  File "C:\labscript_suite\blacs\device_base_class.py", line 627, in transition_to_manual
    raise Exception('Could not transition to manual. You must restart this device to continue')
Exception: Could not transition to manual. You must restart this device to continue

It seems the labscript.py file is updated ( since hello printed before) with the code suggested a few emails back. 

I have attached the BLACS.log file

Heading to bed for now,

Kelsey​

 BLACS.log

​

[Philip Starkey]

Hi Kelsey,

Well I've looked over the log file and can't explain why those tabs went unresponsive. On the plus side, it sounds like it is not happening any more so I guess we shouldn't worry too much...

Back to the original problem. That error message is really what I would expect to see if the trigger doesn't happen at the right time (or the instructions programmed into the PineBlaster run too long).

So, once you verify that the PulseBlaster output works in manual mode, can you confirm (using an oscilloscope) that there is now a pulse coming from it on flag 2 during the buffered sequence? That will narrow it down to a PulseBlaster or PineBlaster issue. If you can see the pulse, please let me know how long it stays high for (it should change length with the value of trigger_minimum_duration in the PineBlaster class, down to a minimum of around 400ns)

Let me know how that goes.

Cheers,

[Kelsey Justis]

Hi Phil,

I have been able to change and see changes on the oscilloscope from a change in the line you suggested (changing trigger_minimum_duration from 2e-6 (2000 nanoseconds) down to 0.4e-6 (400 nanoseconds)).  It appears the trigger is in fact being sent, but the same error still prevails.

Thank you for this suggestion.

Best,

kelsey

[Philip Starkey]

Hi Kelsey,

So it sounds like the PulseBlaster is functioning correctly. I've tested today with our PineBlaster and PulseBlaster (DDS-II-300-AWG) and everything works fine (the prior bug fixes solve the expected problems). The trigger duration doesn't seem to matter either. By default, mine came out to be ~250ns (probably due to the different PulseBlaster board in use) and that worked. So anything longer than that will also work for the PineBlaster.

The only conclusion I can come to is that the PineBlaster is not receiving the trigger (actually, I'm assuming here that the PineBlaster works correctly if you remove the PulseBlaster and make it the master pseudoclock?). I reproduce the error you see only if I disconnect the trigger from the PineBlaster. Can you confirm how you have it wired up? I've included a picture of how I wired ours up for the test, but with labels based on the model of PulseBlaster you have (I assume you are breaking out the DB25 connector on the PulseBlaster yourself?). There are 4 connections. 2 connections go to flag 2 on the PulseBlaster (the output for flag 2 and GND). The other 2 are for the output of the PineBlaster which I hooked straight up to the Oscilloscope.

Let me know if this helps.

Cheers,

Phil

[Kelsey Justis]

Hi Phil,

Would you mind sending the pineblaster and pulseblaster.py files you have? I have this setup in the same way (checked many times through) and still end up with this error. I am pretty bewildered at this point. Unfortunately I am also leaving for the summer starting Sunday so I will now have less time/ability to try this out; we may end up using pulseblaster for now to clock everything.

I really appreciate all of your help on this! I know debugging is difficult next to devices and much more difficult from halfway around the world. Thank you so much for your time.

Sincerely,

Kelsey

[Philip Starkey]

Hi Kelsey,

Apologies with the long delay in replying. To answer your question, the PineBlaster and PulseBlaster files I've been using are the current ones on the bitbucket repositories. 

What we have discovered however, is that the version of MPIDE used to compile and flash the pineblaster code may be causing your error. It appears there have been significant changes to the way interrupts are handled, to the point where the latest version of MPIDE does not compile our code anymore. We've created updated instructions on which version of MPIDE does work. It might be worth checking this, and trying to reflash the pineblaster (remember to make sure you have disabled compiler optimisations as per the readme file with the pineblaster code - these instructions have also been updated recently).

If you have time, I'd be interested to know if compiling/flashing with MPIDE v0023-20120903, with all compiler optimisations turned off, fixes your issue.

Cheers,

Phil

[Kelsey Justis]

Hi Phil,

I am not sure if I ever replied to this. I'll check with other members of the group and see if this issue was resolved and if so how.

It has been a while since I was last working in the lab, but I will be here working pretty much full time until late May.

At this point it seems we are breaking new ground as we explore the BIAS component of Labscript; we are running into some issues trying to get this program off the ground with Labview (I am not sure if we have all of the required files for "running" BIAS ; we have installed the 4 .vip files found here: http://labscriptsuite.org/programs/bias/ but I was wondering if we also require the vision builder AI Dev kit since while BIAS is loading numerous files contained in this kit are asked for). 

I was wondering if there has been more work on BIAS (since last May) that we should know about to get this component working for us. In the mean time well continue to work on this end and let you know the progress of another lab's implementation of your team's suite.

Happy Holidays and New Year,

Kelsey

[Philip Starkey]

Hi Kelsey,

Good to hear from you again!

Unfortunately no further development has been done on BIAS. This isn't to say that BIAS won't see further development of course, but we haven't had the need to add further features yet (if we require more analysis, we usually do this in lyse as the analysis in BIAS contributes to shot length). The main author of that component (Martijn Jasperse) has finished his PhD and is now working at a new institution. I suspect his email address that monitors the mailing list may have been closed by my university by now, so I'll shoot him an email at his new address and see if he can answer your question regarding the NI requirements for BIAS. I'm fairly certain you need IMAQdx, but am unsure beyond that.

Happy new year to you as well!

Phil

[Kelsey Justis]

Thank you so much Phil (as always:).

I look forward to hearing back from you.

I hope everything is going well on your end.

Best,

Kelsey

[Philip Starkey]

Hi Kelsey,

Martijn says you will want IMAQdx which is part of "Vision Acquisition Software". You can download it for free from http://www.ni.com/download/ni-vision-acquisition-software-august-2015-f1/5486/en/ (requires you to create an NI account if you don't already have one). As far as we are aware, this is the only requirement that is not listed on the website (we'll update this shortly so that it is included too!)

Let me know if you still have issues!

Cheers,

Phil

On Wednesday, 20 January 2016 11:31:03 UTC+11, Kelsey Justis wrote:

Thank you so much Phil (as always:).

I look forward to hearing back from you.

I hope everything is going well on your end.

Best,

Kelsey

On Tue, Jan 19, 2016 at 6:15 PM, Philip Starkey

Hi Kelsey,

To unsubscribe from this group and all its topics, send an email to labscriptsuite+unsubscribe@googlegroups.com.

[Kelsey Justis]

Hi Phil,

I think I got Bias to run. Also for future reference I think BIAS will only work with a 32-bit version of Labview (after trying on 64-bit LV for a few days and flushing out all dependencies I found the underlying issue to be the msgpack.dll library file to be a mismatch with the 64bit Labview version; after repeating steps with 32 bit LV BIAS ran -- see attached .pdf for some documentation on this process).

Now I got a new challenge; I am trying to connect a camera (unfortunately perhaps not one of the 3 already being used). The camera (a Point Grey FL3-U3-13S2M-CS) needs to be implanted into the labscript/Bias ecosystem; I am currently following the instructions laid out in page 7 of the BIAS manual/setup file, but am stopped once referred to the "CameraBase VIs" documentation; I am not sure where to find this documentation. For now I am playing around with BIAS and the camera's software to see if I can happen onto a solution. 

I have never messed with Labview before this week, so this is a bit fun. Thank you for your help thus far; Ill keep you updated.

Best,

Kelsey

[Philip Starkey]

Hi Kelsey,

I've talked to Martijn again and you are correct, BIAS is only compatible with 32-bit Labview. The msgpack library has not been compiled for 64-bit, and as a result, BIAS has not been tested on 64-bit labview at all (so there may be further issues that would need to be addressed). There shouldn't be any issue with you using 32-bit Labview though as far as I can see.

In regards to the documentation, it looks like the CameraBase documentation was never written. I'll log that as a bug and see if we can get it written at some point .Unfortunately I'm not that familiar with Labview so can't write it myself. In the mean time, the best approach would be to look at how the CameraBase VIs have been overridden for the other camera implementations. These are located in the classes folder (which I think is where your new one will appear if you follow steps 1-7 on page 7 of the BIAS documentation). The best bet is probably to look at the implementation in classes/IMAQdx, although the others might be helpful too. Basically the VI name should be indicative of what it should do, and you need to implement the equivalent behaviour for your camera (calling the appropriate functions/VIs from your cameras SDK). The CameraBase VIs (in classes/CameraBase) that you are subclassing define the inputs and outputs for your VIs and you just have to fill in the logic in the middle. Just make sure you create the VIs by following the instructions in the BIAS documentation, or else they won't subclass correctly. 

Once that is done it should just be a matter of specifying the SDK name (to match the one you created) in the labscript connection table when you instantiate a Camera class. BIAS reads the connection table when it is started, and BIAS should prompt you to select one of the cameras you have defined in the connection table. BIAS will then load the appropriate Camera VIs and you should be able to test your camera in both manual mode (using the BIAS interface) and in buffered mode by hooking up a trigger line to your camera and running a shot through BLACS.

Hopefully that at least gets you started!

Cheers,

Phil

On Saturday, 23 January 2016 04:43:39 UTC+11, Kelsey Justis wrote:

Hi Phil,

I think I got Bias to run. Also for future reference I think BIAS will only work with a 32-bit version of Labview (after trying on 64-bit LV for a few days and flushing out all dependencies I found the underlying issue to be the msgpack.dll library file to be a mismatch with the 64bit Labview version; after repeating steps with 32 bit LV BIAS ran -- see attached .pdf for some documentation on this process).

Now I got a new challenge; I am trying to connect a camera (unfortunately perhaps not one of the 3 already being used). The camera (a Point Grey FL3-U3-13S2M-CS) needs to be implanted into the labscript/Bias ecosystem; I am currently following the instructions laid out in page 7 of the BIAS manual/setup file, but am stopped once referred to the "CameraBase VIs" documentation; I am not sure where to find this documentation. For now I am playing around with BIAS and the camera's software to see if I can happen onto a solution. 

I have never messed with Labview before this week, so this is a bit fun. Thank you for your help thus far; Ill keep you updated.

Best,

Kelsey

To unsubscribe from this group and all its topics, send an email to labscriptsuite+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "The labscript suite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/labscriptsuite/pueMnUvv0hk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to labscriptsuite+unsubscribe@googlegroups.com.

[Kelsey Justis]

Hi Phil,

Thank you for the quick responses. 

Regarding the camera implementation, I am currently using a Point Grey Camera (Model: Point Grey Camera Flea3 FL3­U3­13S2M­CS); because NI-Max was able to identify the camera I assumed I could use the IMAQdx class. 

(I tried earlier to create my own Point Grey class using the steps outlined in the BIAS documentation, but due to my lack of LabView experience I was not able to find where (if at all which) fields or places to enter the camera specific information (not sure what is required or where to put it), so I opted to use the IMAQdx class in hopes that this camera was covered. )

I then proceeded to use the "krb.py" file you provided earlier in our emails as an example to instantiate a camera object in both the connection table and experiment file (both attached) to see if I could insert a camera into the Labscript environment for our lab. I was able to successfully load/compile BLACS, but upon running the experiment script via Runmanager I got an error trying to connect to a server port (assumed to be BIAS); all of the aforementioned errors are documented in the last page of another attached document recording my progress on this front. 

At this time, BIAS does not recognize a camera is present, and I have tried to circumvent these errors by changing the BIAS port in the camera object definitions for the connection table and experiment file to the one found in camera.py class under labscript device utils folder; I have also tried updating the labconfig file with a BIAS:port number to resemble the information found there for BLACS, LYSE, etc.

I think it might be most helpful to see the attached documents.

Thank you for all of your help.

Best,

Kelsey

[Philip Starkey]

Hi Kelsey, 

If NI-MAX identifies the camera, I think you should be able to use it as an IMAQdx camera. If there are bugs with acquiring images, I think you can subclass the IMAQdx camera class and reimplement the VIs which are causing the bugs (we've done this for the photonfocus camera class where we only had to reimplement 2 of the IMAQdx VIs)

Regarding the BIAS error: it looks like a bug was introduced in this commit that bypassed the typecasting of the serial_number and SDK to an integer and string respectively. I suspect this is why labview is unable to read the camera attributes correctly. Could you try modifying your serial number to be the hexadecimal number 0x1E1000E75382 (so write serial_number=0x1E1000E75382 in the connection table)? That should put it in the correct format (the bug only affects serial numbers specified as strings). If this doesn't work, you may also want to try updating the version of H5Labview you are using in case the specific version specified on our website has a bug in it.

The error in BLACS is due to the fact that you have not specified the hostname or IP address for the computer running BIAS in the BLACS tab. You will notice there is a box in the GUI for you to enter the "host" (this is just above the port number on the camera tab). Enter the hostname or IP address of the PC here and then click "check connectivity". The icon further down the tab should change from a cross to a tick if it can communicate with BIAS correctly (BIAS must be running and you need to have selected a camera, see below!). If BIAS is running on the same PC as BLACS, then enter localhost or 127.0.0.1

Assuming the above fixes the two problems, when you start BIAS you should be prompted to select the camera from the connection table you wish BIAS to control (this is so you can have multiple cameras and multiple instances of BIAS). You should only see one entry, so select that and the BIAS interface should show and be controllable. Once you have reached this point, BLACS should be able to communicate with BIAS.

I also noticed that you set the effective_pixel_size to be the camera pixel size. Just a heads up, if your imaging lens system has a magnification that is not 1, you will need to adjust the effective_pixel_size in the connection table. It's obviously not a problem for now, but when you are taking images in future experiments, you'll want to set this up.

With regards to the BIAS ports, the port only needs to specified in the connection table. It does not need to be specified in the lab config (in fact the BIAS ports in the connection table must be unique, and not conflict with each other or the other ports specific in the lab config file).

Hope this solves the problems!

Cheers,

Phil

--

Philip Starkey

School of Physics and Astronomy

Monash University

You received this message because you are subscribed to the Google Groups "The labscript suite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuit...@googlegroups.com.

[Russell Anderson]

Hi Kelsey,

Glad to hear that you've got BIAS working (almost?) and thanks for debugging (and persisting in spite of) some of the idiosyncrasies. It bears pointing out that you don't need to use BIAS to use the rest of the labscript suite. It can be replaced with any other imaging system that conforms to the specification (to be posted here shortly). BIAS originally served to demonstrate that the modular architecture permits a non-Python (e.g. LabVIEW) component to co-exist with the rest of the suite. However, it is no longer under active development and your mileage may vary. It may be quite a steep learning curve as a first LabVIEW project, and is not very extensible.

Indeed, another user of the labscript suite, Ian Spielman, rapidly came to the conclusion that BIAS would not meet his requirements and developed his own imaging system to work with labscript/BLACS. While deploying the labscript suite in Tübingen, Chris Billington used a minimal camera server to work with their existing imaging system. This code amounts to the specification for a labscript camera server and will be posted shortly.

Russ

You received this message because you are subscribed to the Google Groups "The labscript suite" group.

To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuit...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Russell Anderson

School of Physics and Astronomy
Monash University

Victoria 3800, Australia
Ph: +61 431 583 798

[Russell Anderson]

On 27 January 2016 at 11:21, Russell Anderson <russell....@monash.edu> wrote:

[BIAS] is no longer under active development and your mileage may vary. It may be quite a steep learning curve as a first LabVIEW project, and is not very extensible.

That said, we continue to use it exclusively in our labs at Monash, and as Phil suggests it might only require you to modify a few IMAQdx VIs to get working with your camera. We're keen to hear how you go if you pursue this approach.

[BIAS] can be replaced with any other imaging system that conforms to the specification (to be posted here shortly). 

...

While deploying the labscript suite in Tübingen, Chris Billington used a minimal camera server to work with their existing imaging system. This code amounts to the specification for a labscript camera server and will be posted shortly.

Chris has put the bare minimum requirements of a camera server in labscript_utils/camera_server.py. The CameraServer class is specified in this file, and you can subclass it for your own system. To demonstrate this minimal working example you can use the following labscript (or similar) after running camera_server.py (in this case I used the same host that BLACS was running on).

from __future__ import division
from labscript import *
from labscript_devices.PulseBlaster import PulseBlaster
from labscript_devices.Camera import Camera

# Main device definitions
PulseBlaster('pulseblaster_0', board_number=0)

# Imaging system
Camera('dummy_camera', pulseblaster_0.direct_outputs,
       'flag 2', BIAS_port=8765, exposure_time=1e-3)

# -------- Experiment begins ----------------------------------
print('\n\nCompiling labscript...')
start()
dummy_camera.expose(name='test', t=10e-3, frametype='frame_0')

# Finish experiment
stop(20e-3)

By including the dummy_camera in the experiment connection table, a camera tab appears in BLACS.

Note: You should select "Use ZMQ" if using this type of camera server. In future we might update the Camera class in labscript_devices to automatically detect this.

When compiling and submitting shots from runmanager, the minimal camera server will indicate state, e.g.

Z:\Experiments\labscript-dev\camera_server_test\2016-Jan\27\20160127T170806_camera_server_test_0.h5

transition to buffered

done

transition to static

Russ

[Kelsey Justis]

Hi Russ,

Thank you for this information! I (and the rest of us) would like to sidestep BIAS only because it forces us to buy a Labview License and Vision Dev Mod (together $1000+ USD), but I will try to continue working on this front as well as the alternative you are suggesting. 

I think our lab is currently more inclined towards BIAS because of all the functionality already offered and honestly "the pretty GUI" and its interface (fingers crossed) with the rest of the Labscript Suite, but a free alternative is definitely better and more open for active future development that will surely be beneficial to all in the Labscript community. We currently want to just "put a camera into the system" and take 3 stills for absorption imaging and then get fancy with some pythonic analysis.

In addition to the server option recommended, is there more code in the works to provide similar functionality (image analysis, .h5 file saving, GUI, driver/connection SW, interface with BLACs) as BIAS that you would feel comfortable sharing? We could work together on this development if so.

I will try your present solution and let you know of its success (or attempt at such).

Thank you!

Kelsey

--

[Russell Anderson]

On 28 January 2016 at 08:07, Kelsey Justis <kelsey....@gmail.com> wrote:

Thank you for this information! I (and the rest of us) would like to sidestep BIAS only because it forces us to buy a Labview License and Vision Dev Mod (together $1000+ USD)

[...]

I think our lab is currently more inclined towards BIAS because of all the functionality already offered and honestly "the pretty GUI" and its interface (fingers crossed) with the rest of the Labscript Suite, but a free alternative is definitely better and more open for active future development that will surely be beneficial to all in the Labscript community.

We concur! This would be a key advantage of an alternative imaging system.

 

We currently want to just "put a camera into the system" and take 3 stills for absorption imaging and then get fancy with some pythonic analysis.

Yep, this is how we use BIAS; the optical depth calculation (from the 3 absorption imaging frames) and fitting is done using Python code. The Python code that BIAS calls (via Martijn Jasperse's excellent pybywire) can also be used as single-shot analysis routines in lyse, or as standalone scripts that post-process h5 files. The benefit of using the code through a dedicated imaging system is of course the interactivity; you can readily select ROIs, fit to subregions of the image, and see line-outs.

In addition to the server option recommended, is there more code in the works to provide similar functionality (image analysis, .h5 file saving, GUI, driver/connection SW, interface with BLACs) as BIAS that you would feel comfortable sharing?

I wish! Having seen the skeleton requirements for a labscript camera server, it is tempting to imagine what might be possible (and how) using something like PyQtGraph, but we don't have the resources to dedicate to this in the short term. I'd be thrilled to see such a system developed by others, though, and we'd be happy to provide consultative support to such development.

I will try your present solution and let you know of its success (or attempt at such).

Okay, thanks.

 

[Kelsey Justis]

Hi Phil,

Thank you for all of your suggestions. I have had some success and some "not so success". 

I am now able to select the camera when running BIAS but still not able to connect BLACS to BIAS; I believe this to be due to the error given by BIAS (recorded in attached .pdf). I think this error comes from the subvis of the IMAQdx camera class; I am not sure how to "reimplement the the vis" is this done by simply following the instructions outlined in the BIAS documentation of will I need to make additional changes via Labview? If so, how difficult is this? (Where do I go in Labview to make the needed changes/how do I know what changes to make?)

Also I realize this help/knowledge has been pretty unilateral; if it is helpful I could edit/update some of the labscript documentation to be more adapted to the novice/undergraduate user.

Thank you,

Kelsey

[Philip Starkey]

Hi Kelsey,

Those errors appear to indicate the BIAS is unable to find the VIs associated with the IMAQdx class. You can usually change this (possibly by opening the IMAQdx.lvclass file) but it might be a good idea to just relocate BIAS to LabVIEWs user.lib folder (this is where the BIAS documentation suggests installing it and I'm not sure we've tried it anywhere else).

Our working installations have BIAS located in C:\Program Files (x86)\National Instruments\LabVIEW <insert year>\user.lib\bias2 (so the files will have paths like C:\Program Files (x86)\National Instruments\LabVIEW <insert year>\user.lib\bias2\BIAS.vi, C:\Program Files (x86)\National Instruments\LabVIEW <insert year>\user.lib\bias2\classes\.... etc). Moving BIAS here will hopefully help it find all the files.

If this doesn't fix it, I'd suggest opening every VI in the bias folder and making sure it can find all of its dependencies (usually LabVIEW prompts you upon opening a VI to locate a dependency if it can't find it - but I suspect this doesn't work for just opening BIAS.vi since it is dynamically choosing which camera class to use at runtime)

Cheers,

Phil

--

Philip Starkey

School of Physics and Astronomy

Monash University

[Kelsey Justis]

Hi Phil,

I have tried your recommendations and recorded the results in the updated attachment. Unfortunately I have not been able to get BIAS to work at this time and I think I will take a break to try out Russ' alternative; I would still like to get BIAS to work if nothing else because it feels so close to working and we've both been putting a lot of time into this.

Thank you for your continued help.

Have a great weekend!

Best,

Kelsey

[Philip Starkey]

Hi Kelsey,

It is difficult to diagnose the issue from the error message in that screenshot (it is a very generic error). I think if you click the "stop" button it should hopefully take you to the place in the code where the error is occurring (and highlight it briefly). If you can provide that information it should give us a better idea of what is wrong (or you may even be able to see what the issue is yourself).

Cheers,

--

Philip Starkey

School of Physics and Astronomy

Monash University

[Russell Anderson]

Hi Kelsey,

As per Phil's recommendation, please send further information about the "Open File" error, i.e. what sub VI this is occurring in and which file is not found.

Upon reading your notes, I noticed the following things which may or may not be causing trouble:

• On page 3 of your notes, the camera is listed in the Point Grey DriverControlGUI as using the Point Grey driver (version 2.7.3.18). Technical Application Note TAN2013011, Using Point Grey USB3 Vision Cameras with National Instruments’ Vision Acquisition Software, suggests using the National Instruments driver instead, for this camera to be used with NI-IMAQdx.
  
  
• This may explain why the camera does not appear as an NI-IMAQdx device in NI-MAX, on page 6 of your notes. Instead, it shows up as a generic USB camera in this list. This screen capture from the above application note shows what the NI-MAX window looks like when the camera is registered as an NI-IMAQdx device.
  
  
• Once you have installed the camera as an NI-IMAQdx device by following the instructions on the above application note, confirm that you are able to "Snap" frames in NI-MAX. (This may be possible even if the camera is identified as a generic USB camera, but do so after you've registered the third-party driver in the Point Grey DriverControlGUI.)
  
  
• On page 22 of your notes, you've said

still cant do anything:/ activated license is need for NIIMAQdx;

evaluation mode will not allow me to use this:/:

 What do you mean by this? I think NI-IMAQdx should work with an evaluation copy of NI Vision Acquisition Software. If you're unsure whether you have NI-IMAQdx, check that the IMAQdx Function Palette is present in LabVIEW (Under View >> Functions Palette >> Vision and Motion). It might not be present due to this issue.

• The second dialog in the final screen grab in your notes (page 23) "Can't find pybywire server.... Start server?" is normal. It is a prompt to start a (locally running) pybywire server for LabVIEW to communicate with Python. Click "Yes" to start the server. It might take several seconds the first time you do this.

Russ

On 30 January 2016 at 06:49, Kelsey Justis <kelsey....@gmail.com> wrote:

I have tried your recommendations and recorded the results in the updated attachment. Unfortunately I have not been able to get BIAS to work at this time and I think I will take a break to try out Russ' alternative; I would still like to get BIAS to work if nothing else because it feels so close to working and we've both been putting a lot of time into this.

--

Russell Anderson

School of Physics and Astronomy
Monash University

Victoria 3800, Australia

[Kelsey Justis]

Hi Phil and Russ,

I am no longer able to get to this menu; the program is stopping on a loading icon even after reopening BLACS, Labview, and restarting computer. Ill have to try some more things in the morning to see what has changed. I'll let you know if I find anything else.

I've attached the same doc with pictures of the screen it is caught on; I can open cameraconnect.vi for both the IMAQdx and camerabase class though without a problem. 

More to follow soon,

Kelsey

[Russell Anderson]

To isolate the specific problem of establishing a connection with the camera using IMAQdx, you might also like to try:

1. Open <path to BIAS>\classes\IMAQdx\CameraConnect.vi. If there are missing IMAQdx VIs, this should be detected in this step.
   
2. Enter the camera serial number in the "Serial Number" control (if it is not already present).
   
3. Press Ctrl + E to show the VI's block diagram (or use Window >> Show Block Diagram).
   
4. Add a breakpoint before the FP.Close command at the rightmost point of the block diagram (see attached).
   
5. Add a probe to the CameraInfo indicator (hidden on the front panel of the VI).
   
6. Run the VI. Record any errors and the status of the CameraInfo probe in the Probe Watch Window (see attached).

Russ

[Kelsey Justis]

Hi Russ and Phil,

I want to thank you for all of your help! This is extremely helpful and I do not want to have to lean so much on you guys; I realize you have lives too and not being paid for tech support. Thank you for your time and patience.

I have tried many of your suggestions and tried to document as best as possible the process.

To directly address your questions in the pass emails I'll write responses here below also:

On Sun, Jan 31, 2016 at 7:59 PM, Russell Anderson <russell....@monash.edu> wrote:

To isolate the specific problem of establishing a connection with the camera using IMAQdx, you might also like to try:

1. Open <path to BIAS>\classes\IMAQdx\CameraConnect.vi. If there are missing IMAQdx VIs, this should be detected in this step.
   
2. Enter the camera serial number in the "Serial Number" control (if it is not already present).
   

Did I need to also enter something for camera name?

I entered the serial number as hexadecimal (and made sure the unit selected was hexadecimal); the serial number entry box accepted 1E1000E75382 but not 0x1E1000E75382 (with the extra 0x).

2. Press Ctrl + E to show the VI's block diagram (or use Window >> Show Block Diagram).
   
3. Add a breakpoint before the FP.Close command at the rightmost point of the block diagram (see attached).
   
4. Add a probe to the CameraInfo indicator (hidden on the front panel of the VI).
   
5. Run the VI. Record any errors and the status of the CameraInfo probe in the Probe Watch Window (see attached).

Russ

 

 

I have attached 3 pictures with the information I got from the probe. 

On 1 February 2016 at 09:56, Russell Anderson <russell....@monash.edu> wrote:

Hi Kelsey,

As per Phil's recommendation, please send further information about the "Open File" error, i.e. what sub VI this is occurring in and which file is not found.

 When I click stop Bias stops running. If I hit continue Bias continues to run but nothing happens. An error does not appear for either option clicked.

If BLACS is running/open when I run Bias I get an error 56 (see attached pic) suggesting a network connection error; when I search online the most common issue is stated to be when the server expects/or does not expect and ip address for the host name rather than a string. I tried going around this by trying Bias with BLACS open and host name as both an IP address (Phil suggested: 127.0.0.1)  or string as "localhost"; I did not remember this error occurring when Phil first suggested using either of these two options. 

This error does not appear though if I enter the IP address found by asking google my IP (IP: 129.170.194.141); when this is entered I go back to error 7 the open file error where buttons clicked do nothing from what I can tell.

Upon reading your notes, I noticed the following things which may or may not be causing trouble:

• On page 3 of your notes, the camera is listed in the Point Grey DriverControlGUI as using the Point Grey driver (version 2.7.3.18). Technical Application Note TAN2013011, Using Point Grey USB3 Vision Cameras with National Instruments’ Vision Acquisition Software, suggests using the National Instruments driver instead, for this camera to be used with NI-IMAQdx.
  
  

I thought I had done this via NI-Max already, but I guess this is another way to select the driver from the Point Grey's program flycapture. Thank you for suggesting this document; I chose this driver through Fly capture following the instructions in the document. Now the driver is set via this method.

• This may explain why the camera does not appear as an NI-IMAQdx device in NI-MAX, on page 6 of your notes. Instead, it shows up as a generic USB camera in this list. This screen capture from the above application note shows what the NI-MAX window looks like when the camera is registered as an NI-IMAQdx device.
  
  

I have recorded the appearance in the attached doc; I think the way it appears in NI-Max has changed since Point Gray made their documentation. 

• Once you have installed the camera as an NI-IMAQdx device by following the instructions on the above application note, confirm that you are able to "Snap" frames in NI-MAX. (This may be possible even if the camera is identified as a generic USB camera, but do so after you've registered the third-party driver in the Point Grey DriverControlGUI.)
  
  

I was able-see attached doc. 

• On page 22 of your notes, you've said

still cant do anything:/ activated license is need for NIIMAQdx;

evaluation mode will not allow me to use this:/:

This comment was in reference to the last image on this page where a menu showed text leading me to believe that NI-IMAQdx needed a license not in evaluation form; the status field in this menu (in the pic on page 26) said "For evaluation only. Activation is required for the licensed version." and the description field said "does not require a license" for NI-IMAQIO and NI-IMAQ but not for NI-IMAQdx. 

 

 What do you mean by this? I think NI-IMAQdx should work with an evaluation copy of NI Vision Acquisition Software. If you're unsure whether you have NI-IMAQdx, check that the IMAQdx Function Palette is present in LabVIEW (Under View >> Functions Palette >> Vision and Motion). It might not be present due to this issue.

I am not able to select this menu at this time- see attached doc; I was however able to see IMAQdx present in the functions menu when i tried to edit it via tools (ended up changing nothing, but saw it present nonetheless). 

• The second dialog in the final screen grab in your notes (page 23) "Can't find pybywire server.... Start server?" is normal. It is a prompt to start a (locally running) pybywire server for LabVIEW to communicate with Python. Click "Yes" to start the server. It might take several seconds the first time you do this.

Thank you for letting me know. I have assumed I should also always have "Use ZMQ" checked in BLACS; is this right? Noted in the attached doc, I continued to have the pybywire server connection fail.

Russ I will try the alternative cameraserver.py suggestion tomorrow and let you know how it went.

Thank you guys,

Kelsey

[Kelsey Justis]

Hey Russ,

Wanted to update you on the success/results of implementing this suggestion of an alternative route.

I got the results/output you predicted in your email after some trial and error.

I was wondering if I was supposed to have images in the h5 file or if I need to have something to save image files captured; trying to figure out what kind of data is being stored (if any) and how to access it. Seems as though Chirs Billington had his images stored elsewhere as FITS images in "an external program"; should my camera being doing this also?

I have attached the record on this front.

Thank you for your suggestion!

Best,

Kelsey

On Wed, Jan 27, 2016 at 1:21 AM, Russell Anderson <russell....@monash.edu> wrote:

--