Setting up an OpalKelly

[Fred Jendrzejewski]

Hi,

I wanted to open this topic as we got an OpalKelly for testing and now wanted to test it. Given that I expect several questions to come up, I wanted to have a common place for that.

Loading the bit file onto the OpalKelly was no problem. However, we were now wondering about the pin outputs. We could not find anything about them in the docs. Am I missing something here ?

Cheers,

Fred

[Philip Starkey]

Hi Fred,

Apologies for not documenting that anywhere. As this was originally developed for people who wished to move from Cicero to labscript, I think it was assumed people would already know the pin-out. Obviously that isn't the case so I'll add this information to the documentation soon, but for now...

The relevant signal pins are:

Clock output: JP2-17

Trigger in: JP2-46

Ext Ref Clk In: JP2-4

There are nearby ground pins at JP2-19, JP2-49 and JP2-2

Let us know how you go with using the OpalKelly!

Cheers,

Phil

--
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.

--

Philip Starkey

PhD Candidate

Teaching Associate (Sessional)

School of Physics & Astronomy

Monash University

G07A, New Horizons Centre

20 Research Way, Clayton Campus

Victoria 3800, Australia

[Fred Jendrzejewski]

Thanks for the information. We will puzzle it together now and then try to put it into our test environment.

Let’s see when we get to it.

Cheers,

Fred

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/fGw7wU6RSsY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to labscriptsuit...@googlegroups.com.

[Rohit Prasad Bhatt]

Hi all,
While trying to interface the Opal Kelly with labscript I ran into an error. I have already installed Opal Kelly Front panel version 5.0.2. I can also see my Opal Kelly in the front panel. I tried to write the simplest possible lab connection table to just see my Opal Kelly in BLACS. But on compiling it I get the error.

Here is the connection table code:
#################################
from labscript import *
from labscript_devices.CiceroOpalKellyXEM3001 import CiceroOpalKellyXEM3001

CiceroOpalKellyXEM3001(name='clock')

start()

stop(1)
#################################

And here is the error:
#################################
Traceback (most recent call last):
  File "connectiontable_Opal.py", line 8, in <module>
  File "C:\labscript_suite\labscript\labscript.py", line 2251, in stop
    generate_code()
  File "C:\labscript_suite\labscript\labscript.py", line 2146, in generate_code
    generate_connection_table(hdf5_file)
  File "C:\labscript_suite\labscript\labscript.py", line 2021, in generate_connection_table
    dataset = hdf5_file.create_dataset('connection table', compression=config.compression, data=connection_table_array, maxshape=(None,))
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\h5py\_hl\group.py", line 116, in create_dataset
    dsid = dataset.make_new_dset(self, shape, dtype, data, **kwds)
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\h5py\_hl\dataset.py", line 100, in make_new_dset
    tid = h5t.py_create(dtype, logical=1)
  File "h5py\h5t.pyx", line 1611, in h5py.h5t.py_create
  File "h5py\h5t.pyx", line 1633, in h5py.h5t.py_create
  File "h5py\h5t.pyx", line 1655, in h5py.h5t.py_create
  File "h5py\h5t.pyx", line 1568, in h5py.h5t._c_compound
  File "h5py\h5t.pyx", line 1633, in h5py.h5t.py_create
  File "h5py\h5t.pyx", line 1666, in h5py.h5t.py_create
  File "h5py\h5t.pyx", line 1487, in h5py.h5t._c_string
ValueError: Size must be positive (size must be positive)
Compilation aborted.
#################################

Also I have some questions :

1. How should I mention a clockline to be used by an NI card. For e.g. when I use the PulseblasterUSB as a master pseudoclock, I write :
ClockLine(name='clockline0', pseudoclock=pulseblaster_0.pseudoclock, connection='flag 0')

So what is the correct syntax of pseudoclock and connection attributes for Opal Kelly?

2. Does the Opal Kelly provide only one clock output channel? So if I have two or more NI cards, Should I just distribute this signals (via say BNC T connectors) to all cards?

Also in the case of PulseblasterUSB too, should I just use one clocking output for all cards or separate clock output for each NI card? What is a better practice?

3. Opal Kelly has many pins (Official pinout : https://pins.opalkelly.com/pin_list/XEM3001). Can we make any use of other pins as well with Labscript?

Regards,
Rohit Prasad Bhatt

[Philip Starkey]

Hi Rohit,

0. The first error is because you haven't specified the serial number of the device. Really serial number shouldn't be an optional argument, so I'll fix that bug at some point. For now, you need to instantiate the device as CiceroOpalKellyXEM3001(name='clock', serial='0000000BTN') (I made up the serial number...but mine looks similar to this).

1. Because the device only supports one clockline, this is internally created for you already. If your device is named "clock" (as above) then you can access it through clock.clockline which can then be passed as an argument to an NI card or similar.

2. Technically the clock comes out of multiple pins. It's duplicated on JP2-18, JP2-21, JP2-22. But note that these are not separate clocklines that can be gated and all 4 will always have the same output for the single clockline. In theory it would be better to use one output per device (for impedance/drive current reasons) but in practice it's not likely to make a difference whether you use them or just resort to a BNC T-piece.

2.B. When using the PulseBlaster boards, it's suggested to use one output per device, because each output can be independently gated by labscript (which means less instructions per device if you aren't using them simultaneously). 

3. Not easily. The board is just a generic FPGA development board. For the CiceroOpalKellyXEM3001 labscript device, we're running FPGA firmware that is pin compatible with the Cicero control system so that it is easy for people to migrate from Cicero to labscript if they wish. As such, we're unlikely to add additional features that would break compatibility. You are welcome to develop new FPGA firmware (or modify the existing firmware) to take advantage of the other pins, and add a new device to labscript called something like "XXXXOpalKellyXEM3001" (replace "XXXX" with whatever you like). However, this particular board is at the end of it's manufacturing life, and has very little RAM to store hardware instructions. If you were going to go down the FPGA development route, there are probably better boards you could use than the XEM3001!

Let me know if you run into any other problems!

Cheers,

Phil

[Rohit Prasad Bhatt]

Hi Phil,

Thanks for the explanations. I was also wondering if it's really required to load the FPGA bitfiles onto the Opal Kelly via the front panel software? Or would labscript take care of it?

The online instructions mention to put them in labscript_devices folder.

Regards,
Rohit Prasad Bhatt

[Philip Starkey]

Hi Rohit,

BLACS will take care of it. BLACS chooses the correct firmware file based on the "reference_clock" keyword argument used in the connection table, and loads it onto the device using the Python API for Opal Kelly's Front Panel software. This of course only works if you have put the firmware files in the labscript_devices folder!

So you do need Front Panel installed, but you don't have to load the firmware file yourself. I think the BLACS tab also has a button for flashing the firmware if you power cycle the device and don't want to restart BLACS.

Cheers,

Phil

[Rohit Prasad Bhatt]

Hi Phil,
I tried to modify the lab connection table. I can see Opal Kelly in BLACS but it does not initialise properly. I also tried pressing the Flash FPGA firmware button but still the same problem.

Here is the connection table code:
#################################
from labscript import *
from labscript_devices.CiceroOpalKellyXEM3001 import CiceroOpalKellyXEM3001

from labscript_devices.NI_DAQmx.models import NI_PXIe_6535

CiceroOpalKellyXEM3001(name='clock', serial='1711000H46')
NI_PXIe_6535(name='NI_DIO_card', parent_device=clock.clockline, clock_terminal='PFI4', MAX_name='PXI1Slot3')
DigitalOut(name='DP0_0', parent_device=NI_DIO_card, connection='port0/line0')
DigitalOut(name='DP0_1', parent_device=NI_DIO_card, connection='port0/line1')

start()

stop(1)
#################################

And here is the error:
#################################

Exception in worker - Thu Mar 28, 14:44:59 :

Traceback (most recent call last):

  File "C:\labscript_suite\labscript_devices\CiceroOpalKellyXEM3001.py", line 443, in init
    global ok; import ok # OpalKelly library
ModuleNotFoundError: No module named 'ok'

Fatal exception in main process - Thu Mar 28, 14:45:00 :

 Traceback (most recent call last):

  File "C:\labscript_suite\blacs\tab_base_classes.py", line 771, in mainloop
    next_yield = inmain(generator.send,results)
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\qtutils\invoke_in_main.py", line 103, in inmain
    return get_inmain_result(_in_main_later(fn, False, *args, **kwargs))
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\qtutils\invoke_in_main.py", line 164, in get_inmain_result
    _reraise(exception)
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\qtutils\invoke_in_main.py", line 36, in _reraise
    raise value.with_traceback(traceback)
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\qtutils\invoke_in_main.py", line 61, in event
    result = event.fn(*event.args, **event.kwargs)
  File "C:\labscript_suite\blacs\tab_base_classes.py", line 503, in _initialise_worker
    raise Exception('Device failed to initialise')
Exception: Device failed to initialise
#################################

I guess ok means Opal Kelly. So I have something missing for it. I think the Python APIs should have been installed during Front Panel software installation (I had selected the Python support checkbox during installation).

Also I connected the clock output to oscilloscope and it was already high. It turns high as soon as I power ON the computer. Is it normal?

Regards,
Rohit Prasad Bhatt

On Monday, March 25, 2019 at 9:46:39 PM UTC, Philip Starkey wrote:

Hi Rohit,

BLACS will take care of it. BLACS chooses the correct firmware file based on the "reference_clock" keyword argument used in the connection table, and loads it onto the device using the Python API for Opal Kelly's Front Panel software. This of course only works if you have put the firmware files in the labscript_devices folder!

So you do need Front Panel installed, but you don't have to load the firmware file yourself. I think the BLACS tab also has a button for flashing the firmware if you power cycle the device and don't want to restart BLACS.

Cheers,

Phil

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

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

--
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 labscri...@googlegroups.com.

[Philip Starkey]

Hi Rohit,

Unfortunately, sometimes the Opal Kelly installer doesn't detect the Python location properly (especially if you are using a Python virtual environment). The API is located here on windows: C:\Program Files\Opal Kelly\FrontPanelUSB\API\Python\

In that folder you will see the API for v2 and v3 of Python, and for 32-bit and 64-bit Python. 

Pick the one that is appropriate for your Python installation and copy the ok.py and _ok.pyd files to C:\Your\Path\To\Annaconda\Environment\Lib\site-packages\ok\

For me, this was C:\Anaconda3\Lib\site-packages\ok\ (or for a Python virtual environment C:\Anaconda3\envs\labscript_py36\Lib\site-packages\ok\ )

If there isn't an "ok" folder, create it, then copy in the two files!

If there is already an "ok" folder, delete it first (there is a package on PyPi called "ok" which is completely unrelated to Opal Kelly), then recreate the folder.

P.S. I'm unsure about the default state of the output when no firmware is loaded. It's probably unpredictable though!

Cheers,

Phil.

[Rohit Prasad Bhatt]

Hi Phil,
I tried to copy the APIs. There was no folder called "ok", so I created it in my virtual environment location as you suggested. But I still encounter a problem in BLACS.

Also I had forgot to mention that for the first compilation of the connection table (after any modification) I see a warning. But if I recompile, it says "Ready" in the Runmanager.

Here is the warning:
#################################
C:\labscript_suite\labscript_devices\CiceroOpalKellyXEM3001.py:128: UserWarning: @labscript_device decorator is unnecessary and can be removed
  class CiceroOpalKellyXEM3001(PseudoclockDevice):
C:\labscript_suite\labscript_devices\CiceroOpalKellyXEM3001.py:437: UserWarning: @BLACS_worker decorator is unnecessary and can be removed
  class CiceroOpalKellyXEM3001Worker(Worker):

#################################

And here is the error:
#################################

Exception in worker - Sat Mar 30, 11:08:50 :

Traceback (most recent call last):

  File "C:\labscript_suite\labscript_devices\CiceroOpalKellyXEM3001.py", line 448, in init
    from ok import ok
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\ok\ok.py", line 26, in <module>
    _ok = swig_import_helper()
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\ok\ok.py", line 22, in swig_import_helper
    _mod = imp.load_module('_ok', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.

Fatal exception in main process - Sat Mar 30, 11:08:50 :

 Traceback (most recent call last):
  File "C:\labscript_suite\blacs\tab_base_classes.py", line 771, in mainloop
    next_yield = inmain(generator.send,results)
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\qtutils\invoke_in_main.py", line 103, in inmain
    return get_inmain_result(_in_main_later(fn, False, *args, **kwargs))
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\qtutils\invoke_in_main.py", line 164, in get_inmain_result
    _reraise(exception)
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\qtutils\invoke_in_main.py", line 36, in _reraise
    raise value.with_traceback(traceback)
  File "C:\ProgramData\Anaconda2\envs\Labscript\lib\site-packages\qtutils\invoke_in_main.py", line 61, in event
    result = event.fn(*event.args, **event.kwargs)
  File "C:\labscript_suite\blacs\tab_base_classes.py", line 503, in _initialise_worker
    raise Exception('Device failed to initialise')
Exception: Device failed to initialise
#################################

In the Opal Kelly Front Panel software the API is for Python 3.6 but I have 3.7 installed. Could this be an issue?

Regards,
Rohit Prasad Bhatt

On Thursday, March 28, 2019 at 11:50:27 PM UTC, Philip Starkey wrote:

Hi Rohit,

Unfortunately, sometimes the Opal Kelly installer doesn't detect the Python location properly (especially if you are using a Python virtual environment). The API is located here on windows: C:\Program Files\Opal Kelly\FrontPanelUSB\API\Python\

In that folder you will see the API for v2 and v3 of Python, and for 32-bit and 64-bit Python. 

Pick the one that is appropriate for your Python installation and copy the ok.py and _ok.pyd files to C:\Your\Path\To\Annaconda\Environment\Lib\site-packages\ok\

For me, this was C:\Anaconda3\Lib\site-packages\ok\ (or for a Python virtual environment C:\Anaconda3\envs\labscript_py36\Lib\site-packages\ok\ )

If there isn't an "ok" folder, create it, then copy in the two files!

If there is already an "ok" folder, delete it first (there is a package on PyPi called "ok" which is completely unrelated to Opal Kelly), then recreate the folder.

P.S. I'm unsure about the default state of the output when no firmware is loaded. It's probably unpredictable though!

Cheers,

Phil.

[Philip Starkey]

Hi Rohit,

You can ignore the compilation warning. It's just due to the way we're changing how labscript_devices works. It's a warning saying the class is doing something unnecessary (but harmless).

It's possible your main issue is a Python 3.7 problem. I would use conda to create a Python 3.6 environment to test in. You don't need to install the whole labscript suite to test, just copy the "ok" module in and try and import it in a terminal (using: import ok).

Also, just to confirm, the _ok.pyd file does exist in the ok folder?

Let me know how it goes!

Cheers,

Phil

[Rohit Prasad Bhatt]

Hi Phil,
So it looks like I have passed the previous error but I still see a new error.

Since we plan to use Opal Kelly as a master pseudo-clock on a different experiment, I installed Labscript in a Python 3.6.7 virtual environment on the computer for that experiment. I also copied both API files to proper environment location. The connection table code remains the same.

The error I see is :
#################################
Exception in worker - Sun Mar 31, 14:40:12 :

Traceback (most recent call last):

  File "C:\labscript_suite\labscript_devices\CiceroOpalKellyXEM3001.py", line 464, in init
    assert self.dev.OpenBySerial(bytes(self.serial)) == self.dev.NoError
TypeError: string argument without an encoding

Fatal exception in main process - Sun Mar 31, 14:40:12 :

 Traceback (most recent call last):

  File "C:\labscript_suite\blacs\tab_base_classes.py", line 786, in mainloop
    next_yield = inmain(generator.send,results)
  File "c:\programdata\miniconda3\envs\labs_36\lib\site-packages\qtutils\invoke_in_main.py", line 103, in inmain

    return get_inmain_result(_in_main_later(fn, False, *args, **kwargs))

  File "c:\programdata\miniconda3\envs\labs_36\lib\site-packages\qtutils\invoke_in_main.py", line 164, in get_inmain_result
    _reraise(exception)
  File "c:\programdata\miniconda3\envs\labs_36\lib\site-packages\qtutils\invoke_in_main.py", line 36, in _reraise
    raise value.with_traceback(traceback)
  File "c:\programdata\miniconda3\envs\labs_36\lib\site-packages\qtutils\invoke_in_main.py", line 61, in event
    result = event.fn(*event.args, **event.kwargs)
  File "C:\labscript_suite\blacs\tab_base_classes.py", line 498, in _initialise_worker

    raise Exception('Device failed to initialise')
Exception: Device failed to initialise
#################################

Regards,
Rohit Prasad Bhatt

On Saturday, March 30, 2019 at 11:34:54 AM UTC+1, Philip Starkey wrote:

Hi Rohit,

You can ignore the compilation warning. It's just due to the way we're changing how labscript_devices works. It's a warning saying the class is doing something unnecessary (but harmless).

It's possible your main issue is a Python 3.7 problem. I would use conda to create a Python 3.6 environment to test in. You don't need to install the whole labscript suite to test, just copy the "ok" module in and try and import it in a terminal (using: import ok).

Also, just to confirm, the _ok.pyd file does exist in the ok folder?

Let me know how it goes!

Cheers,

Phil

[Philip Starkey]

Hi Rohit,

Unfortunately I'm having trouble testing a solution because my Opal Kelly board is no longer being recognised by my PC. 

That said, I think the temporary solution for you is to change the line it is crashing on to:

assert self.dev.OpenBySerial(self.serial) == self.dev.NoError

I was able to see the same error you did, but can't test if this is the correct fix due to not having working hardware. 

I'm guessing there is either something different about certain Opal Kelly Front Panel versions, or possibly a Python 2.7 vs 3.6 bug in my code, which is why the serial needed to be wrapped in bytes() on the PC I used to develop this code. Once I get working hardware I'll work it out properly, but for now I would just go ahead and make this change to your local copy to get it to work!

P.S. You may run into a similar issue with the line self.dev.ConfigureFPGA(bytes(fpga_path)). Presumably removing bytes() will also fix that too if you get an error.

Hopefully this is the last of the bugs!

Cheers,

Phil.

[Rohit Prasad Bhatt]

Hi Phil,

Thanks for the suggestion. The issue is now resolved. I already used Opal Kelly to trigger NI card to produce signals. I made changes in both lines as you had suggested.

However I sometimes see unexpected error during running shots. I will try to make a systematic run and then get back to you with more details.

Thanks again.

Regards,
Rohit Prasad Bhatt

[Philip Starkey]

Hi Rohit,

Did you ever manage to track down the unexpected error you were seeing?

FYI, I have now included fixes for the previous issues in the main labscript suite respository, and it should now be compatible with both Python 2.7 and Python 3.6 (but not 3.7 as this requires Opal Kelly to recompile their library and release a new version of front panel...however when that is done it should also work). No need to update anything though as you fixed them by hand, but updating to new versions of the labscript suite won't require you to reapply the manual changes!

Cheers,

Phil

[Rohit Prasad Bhatt]

Hi Phil,

I am sorry for the late reply.

Actually after the Opal Kelly started working I did not really dig into the case when I saw the error. However the Opal Kelly is not yet deployed in the experiment so I could test it. But since I am working on a different part of the experiment, I think I will do it later.

So I definitely had to change both the lines (self.dev.OpenBySerial and self.dev.ConfigureFPGA) as you had suggested. After that everything was shown fine in BLACS. But then (as I vaguely remember) when I tried to run too short a code (like switch ON one DIO), I got an error about too less samples written.  The error did not occur on using more channels, but I really have not yet tested it systematically.

I know that because of a DAQmX issue, one always has to use even number of channels. But this error was something different.

Also thanks for the fixes. I will post an update here when I run a re-check of the issue I had encountered.

Regards,

Rohit Prasad Bhatt

[Apoorva Hegde]

Hi Philip, 

We have connected the same Opal Kelly but now to a different PC where we have installed labscript in python 3.6 virtual environment. I am replying to this thread because now I have the exact same error where it says that the device failed to initialise. Here's the error I get:

----------------------------------------------------------------

Exception in worker - Fri Sep 13, 14:54:38 :

Traceback (most recent call last):

  File "C:\labscript_suite\labscript_devices\CiceroOpalKellyXEM3001.py", line 467, in init
    assert self.dev.OpenBySerial(self.serial) == self.dev.NoError
AssertionError

Fatal exception in main process - Fri Sep 13, 14:54:38 :

Traceback (most recent call last):

  File "C:\labscript_suite\blacs\tab_base_classes.py", line 848, in mainloop
    next_yield = inmain(generator.send,results)
  File "C:\python\envs\nalicontrol\lib\site-packages\qtutils\invoke_in_main.py", line 103, in inmain

    return get_inmain_result(_in_main_later(fn, False, *args, **kwargs))

  File "C:\python\envs\nalicontrol\lib\site-packages\qtutils\invoke_in_main.py", line 164, in get_inmain_result
    _reraise(exception)
  File "C:\python\envs\nalicontrol\lib\site-packages\qtutils\invoke_in_main.py", line 36, in _reraise
    raise value.with_traceback(traceback)
  File "C:\python\envs\nalicontrol\lib\site-packages\qtutils\invoke_in_main.py", line 61, in event
    result = event.fn(*event.args, **event.kwargs)
  File "C:\labscript_suite\blacs\tab_base_classes.py", line 544, in _initialise_worker

    raise Exception('Device failed to initialise')
Exception: Device failed to initialise

-------------------------------------------------------------------

I have tried every solution that was discussed in this post such as keeping the FPGA bit files in the labscript_devices folder, creating the 'ok' folder as you suggested and copying the API configuration files onto it. I still get the same error. I had a look into CiceroOpalKellyXEM3001. py file. I see that there's a line (line 466) that says self.serial = bytes(self.serial). I tried compiling the BLACS by commenting this line. But I can't get rid of this issue.  Do you have any furrther suggestion for me?

Thanks!

Cheers,

Apoorva 

On Monday, April 1, 2019 at 5:16:53 PM UTC-7, Philip Starkey wrote:

Hi Rohit,

Unfortunately I'm having trouble testing a solution because my Opal Kelly board is no longer being recognised by my PC. 

That said, I think the temporary solution for you is to change the line it is crashing on to:

assert self.dev.OpenBySerial(self.serial) == self.dev.NoError

I was able to see the same error you did, but can't test if this is the correct fix due to not having working hardware. 

I'm guessing there is either something different about certain Opal Kelly Front Panel versions, or possibly a Python 2.7 vs 3.6 bug in my code, which is why the serial needed to be wrapped in bytes() on the PC I used to develop this code. Once I get working hardware I'll work it out properly, but for now I would just go ahead and make this change to your local copy to get it to work!

P.S. You may run into a similar issue with the line self.dev.ConfigureFPGA(bytes(fpga_path)). Presumably removing bytes() will also fix that too if you get an error.

Hopefully this is the last of the bugs!

Cheers,

Phil.

[Philip Starkey]

Hi Apoorva,

That looks like a slightly different error. It seems that the assertion is failing, indicating that the code is correct, but couldn't connect to the device.

Can you confirm if the OpalKelly Front panel software can see the board?

Also, make sure that the FrontPanel software is not running while BLACS is as only one program can use the board at a time (You will likely need to revert any changes you've made to the BLACS device class as well as I'm reasonably confident it is correct).

If FrontPanel works, but BLACS still doesn't, then there is something else wrong that I don't understand and we'll have to do some debugging together to get to the bottom of it!

Cheers,

Phil

To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/604a54a5-7147-422f-8f54-39d97a01bb85%40googlegroups.com.

[Apoorva Hegde]

Hi again Philip, 

You were right. The FrontPanelSDK  was open while the BLACS was running. I guess this was the whole problem. Now I closed the  FrontPanelSDK and the Opal Kelly compiles without any error.

Thanks a lot for your help!

Cheers, 

Apoorva 

On Friday, September 13, 2019 at 8:07:30 AM UTC-7, Philip Starkey wrote:

Hi Apoorva,

That looks like a slightly different error. It seems that the assertion is failing, indicating that the code is correct, but couldn't connect to the device.

Can you confirm if the OpalKelly Front panel software can see the board?

Also, make sure that the FrontPanel software is not running while BLACS is as only one program can use the board at a time (You will likely need to revert any changes you've made to the BLACS device class as well as I'm reasonably confident it is correct).

If FrontPanel works, but BLACS still doesn't, then there is something else wrong that I don't understand and we'll have to do some debugging together to get to the bottom of it!

Cheers,

Phil

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

[Philip Starkey]

Hi everyone,

FYI the latest Opal Kelly SDK (FrontPanel v5.2) now apparently supports every version of Python from 3.5 up. Hopefully this means people using the Opal Kelly XEM3001 based pseudoclock won't be stuck on old Python versions anymore! I haven't tested that it works correctly with our labscript_devices implementation, but previous SDK updates have worked without issue.

Cheers,

Phil