dialysate_delivery.py

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
fixed it

fixed it

This is a change from Zoltan and I am updated that into my local branch

This is a change from Zoltan and I am updated that into my local branch

for Dry Bicart , I have reserved the message ID long time back as 0x70 and its correct. I was confused after staging branch merged with my local branch, since all of my other message ID are used by...

for Dry Bicart , I have reserved the message ID long time back as 0x70 and its correct. I was confused after staging branch merged with my local branch, since all of my other message ID are used by other modules except BICART_DATA. please dis regard this question.

This is a merge issue. when I updated the code and aligned to staging , this all change happened. Need to check with Dara

This is a merge issue. when I updated the code and aligned to staging , this all change happened. Need to check with Dara

Add a blank line between functions.

Add a blank line between functions.

Is this staying? Is all of above replacing this class?

Is this staying? Is all of above replacing this class?

WIP on develop

LDT-3287: added message sent for TD. trimmed documentation

  1. … 2 more files in changeset.
LEAHI-DIALIN-LDT-3287_Dialin ability to pull B1.9 IOFP variable data has changed from B1.0
LEAHI-DIALIN-LDT-3287_Dialin ability to pull B1.9 IOFP variable data has changed from B1.0
LDT-3287: Added an initial message that is sent on class object construction for FP & DD to allow the subsystem to start publishing as the subsystem may assume no one is on the CANbus when dialin is a node.

  1. … 1 more file in changeset.
Based on the msg id, it should be here

Based on the msg id, it should be here

@zoltan , could you please confirm whether this is the correct place for BICART_DATA ?

@zoltan , could you please confirm whether this is the correct place for BICART_DATA ?

Please pull the latest staging and update the test configs regarding that. I think the dry bicart test config is already there

Please pull the latest staging and update the test configs regarding that.
I think the dry bicart test config is already there

Merge branch 'LDT-3214-override-refactor' into staging

  1. … 46 more files in changeset.
Merge branch 'LDT-3214-override-refactor' into develop

  1. … 46 more files in changeset.
I added the unique decorator back, except for the few that have aliases

I added the unique decorator back, except for the few that have aliases

Renamed, also flagged for future type change.

Renamed, also flagged for future type change.

"No one should interact with it or be aware of it's existence, so the name shouldn't matter." *it matters to those who read the code in inconsistent intervals ( like those who participate in code...

"No one should interact with it or be aware of it's existence, so the name shouldn't matter."

  • it matters to those who read the code in inconsistent intervals ( like those who participate in code review or teaching ).


"As we only have 2 version in test at the same time."

  • Currently. By summer, i'd expect dialin to be considering 1.0's, 1.9s, and 2.0s/DVTs.


We have the choice to handle the redesign effort then or now.


Edit:
Follow up comment.

Looking at the other files. Users of dialin will not be aware of existence, but developers of dialin will as it impacts the behavior of overrides like temp & pressure.

yes. that's the design consideration. Are we okay with our unit tests no longer checking for duplicate values? ( they will currently pass as i remember they expect an exception due to the unique ke...

yes. that's the design consideration. Are we okay with our unit tests no longer checking for duplicate values? ( they will currently pass as i remember they expect an exception due to the unique keyword to fail. These will not trigger an exception ).

I am not sure I can assign unique to the dynamic enums. Also with unique you can't add aliases and some(for example: temperature) overrides use the aliases to determine which msg id to call and how...

I am not sure I can assign unique to the dynamic enums. Also with unique you can't add aliases and some(for example: temperature) overrides use the aliases to determine which msg id to call and how much to shift value for it.
Making an alias is more dynamic and not needing separate variables to be maintained for this.

Enum content of Beta 1.0 and Beta 1.9 is different. The new sensors messing up the order for the old HW's override and broadcast data allocation. Making it dynamic makes it that when the beta test ...

Enum content of Beta 1.0 and Beta 1.9 is different. The new sensors messing up the order for the old HW's override and broadcast data allocation.
Making it dynamic makes it that when the beta test config is called the enums are switching content to reflect that.