This CR should be closed due to bad branching. Should have been branched out of p1_staging.

RESOLVED.

Removed.

Is this print meant to be permanent? Or is it debug code?

RESOLVED

Addressed. Sean Nash [~plucia] Please check and resolve.

RESOLVED.

Addressed.

RESOLVED.

RESOLVED.

I think older classes may not have get functions for everything, but Sarina and others prefer get functions to accessing properties directly so we're trying to create get functions for every collected data.

Actually they should be in multiples of 50ms (general task). I mistakenly had a few functions written with 10ms (priority task) but that is not correct. I don't think it would cause an error, but non-multiple intervals will be floored to nearest lower multiple of 50 ms by the f/w I suspect.

RESOLVED

RESOLVED

RESOLVED

I wasn't aware the ms needed to be in multiples of 10ms. I've created a case DIAL-115 to add constraint enforcement across dialin.
For now, I think new code should incorporate some form of constraint enforcement. So if you could just apply it here in DIAL-115 I will address this in other parts of dialin.
I think the docstring describing the constraint is useful and should be kept if it's already there even if we add code to check the constraint as well.

Blood leak currently outputs the states of the state machine to the console as it changes. If we want to get the state, we will need to implement it here and for Blood Leak as well. How are the other Dialin API libraries handling it? We need to be consistent across here.

None of the functions we have check for any of these conditions. If we want to implement this in the code, we will need to remove this comment from all *.py Dialin API files and implement the checks in all *.py Dialin API files. Please let me know how you would like to proceed.