conductivity_sensors.py

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
removed obsolate todo comment

Removed

Removed

removed -1 to adjust removal of D98_cond

There is one more -1 that considered D98. fp.conductivity.cmd_conductivity_sensor_filtered_readings_override()

There is one more -1 that considered D98. fp.conductivity.cmd_conductivity_sensor_filtered_readings_override()

LEAHI-DIALIN-LDT-3479_D98 is in DD conductivity module
LEAHI-DIALIN-LDT-3479_D98 is in DD conductivity module
reverted handler to the original version. This was required to get a merge with develop to work

reverted handler to the original version. This was required to get a merge with develop to work

fixed.

fixed.

This code won't work. The sensor list missing the for loop that's populating it, and the original one is missing the M3 unpack. It's a merge of an old and a new code but both incomplete. Please re...

This code won't work. The sensor list missing the for loop that's populating it, and the original one is missing the M3 unpack. It's a merge of an old and a new code but both incomplete.

Please reference https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-3480-1 for working solution on this.

Duplicate, please remove

Duplicate, please remove

LDT-3287: updated MSG_IDs for filtered overrides. implemented filtered overrides for dd temperatures, fp temperatures, fp pressures, dd & fp conductivity

  1. … 4 more files in changeset.
WIP on develop

LDT-3372: implemented filtered conductivity overrides

  1. … 1 more file in changeset.
LDT-3173: msg ids for conductivity overrides

  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
Merge branch 'LDT-3214-override-refactor' into staging

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