Version 2.0 release

[ThomasAkam]

@alustig3 - I woudl like to get the v2.0 release out soon so think we should stop working on new functionallity and get the last bits ready for the release. Is there anything else functionallity wise you want to include in this release? Otherwise I think the main things are updating the docs and checking the data import is working OK for the new data files. Are you happy to do the bits of the docs relating to the changes that you've implemented, and I'll do the bits relating to mine?

[alustig3]

Moving forward with a release sounds good to me. Yes I will contribute documentation.

[alustig3]

When testing the frame_trigger class I am getting a bad checksum:

I am running the following modified blinker.py task code:

# A simple state machine which flashes the blue LED on the pyboard on and off.
# Does not require any hardware except micropython board.

from pyControl.utility import *
from devices import *

board = Breakout_1_2()

# Define hardware (normally done in seperate hardware definition file).

blue_LED = Digital_output("B4")
frame_trigger = Frame_trigger(pin=board.BNC_2, pulse_rate=60)  # Instantiate Frame_trigger on breakout board BNC_2


# States and events.

states = [
    "LED_on",
    "LED_off",
]

events = []

initial_state = "LED_off"

# State behaviour functions


def LED_on(event):
    if event == "entry":
        timed_goto_state("LED_off", 0.5 * second)
        blue_LED.on()
    elif event == "exit":
        blue_LED.off()


def LED_off(event):
    if event == "entry":
        timed_goto_state("LED_on", 0.5 * second)


# Run end behaviour


def run_end():  # Turn off hardware at end of run.
    blue_LED.off()

[ThomasAkam]

@alustig3 I think I'm finished updating the code and docs for the v2.0 release. The Frame_trigger class appears to be working OK on my machine, I'm not sure what was causing the bad checksum but it seems to be fixed, could you check if you still get the error?

Is there anything else you think needs updating/fixing before the release?

[alustig3]

@ThomasAkam, I am still getting a bad checksum when using Frame_trigger. I've tried to debug a little bit on this branch: https://github.com/alustig3/pyControl/tree/frame_trigger_bad_checksum if you want to see if you can replicate.

Is there anything else you think needs updating/fixing before the release?

• I made some final documentation changes more small changes docs#25
• Is there any special instructions or warning that should be added to the upgrade section of the docs with regards to going from v1 to v2?

[ThomasAkam]

@alustig3 I cannot reproduce the bad checksum error on my machine.

Looking at the output in the image you sent I think the problem must be to do with how the data bytes sent by the Frame_trigger are being converted into python arrays. The content of those arrays should just be pulse numbers, so should start at 1 and increment by 1 each sample, as seen here where I print them to the log each time an analog chunk is recieved:

I suspect that the problem is that the byteorder is different in the data sent from the pyboard from that which the comptuer python is expecting when it converts the data to bytes. This could either be because the byteorder different on Mac than windows, or because it is different on the pyboard D to the pyboard 1.1. Can you test if modifying pycboard.py line 482 to explicitly specify the byte order fixes the problem:

data = np.frombuffer(content_bytes[2:], dtype="<" + self.sm_info.analog_inputs[ID]["dtype"])

[alustig3]

@ThomasAkam the np.frombuffer line did not fix the problem.

I also modified my debug statement to be:

bad_msg = f"Bad {data}\t{content_bytes[2]},{content_bytes[6]},{content_bytes[10]}\t\t{content_bytes}"

(updates here:alustig3@bc6ae88)

I got the following output:

so it looks like the data is there, but packed with 3 zero bytes in between each value...

I think this is likely a Mac problem. I currently and debugging with a d-series board, but originally had the problem with a v1.1 board. I also downgraded the firmware to micropython v1.12 and it did not make a difference.

[ThomasAkam]

Hmmm, I think we expect there to be 3 zero bytes between each value becuase these are 4 byte integers and for numbers 1-255 only the last of the 4 bytes should be non-zero. However it looks like first byte of the first sample in each chunk is missing as there are only two zero bytes before the non-zero byte. Does the Analog_input class work correctly?

[alustig3]

@ThomasAkam The problem is the datatype "l" is different on my mac.

import struct
for dtype in ("bhil"):
    print(f'{dtype} = {struct.calcsize(dtype)}')

gives

b = 1
h = 2
i = 4
l = 8

so on line 481 of pycboard

data = array(self.sm_info.analog_inputs[ID]["dtype"], content_bytes[2:])

it was creating an array of 3 8-byte values instead of 6 4-byte values

I haven't had time to come up with a clean solution yet. I tried replacing line 301 of hardware.py with

self.bytes_per_sample = struct.calcsize(data_type)

but it did not make a difference. Let me know what you think.

[ThomasAkam]

Thanks @alustig3. I think a simple fix may be just to use i and I dtypes rather than l and L as they appear to be 4 byte length on pyboard windows and mac. I've pushed a commit to the dev branch that does this, can you verify that it fixes the problem.

[alustig3]

@ThomasAkam that fixes the problem. Thanks!