fixed

Fix typo

I think that's what is usually shown, the first 7 char, but in this case it might have been a typo

Was it a regulatory requirement before to have 7 characters from commit ID or something we implemented?

No need, in a different CR I have a module that pulls the Alarm ID, Reject Reason and Msg Ids directly from the FW. After that's merged, this file won't be needed any more manual update.

For more information check LDT-5205 CR, file: utils\ enum_updater.py

In FW we pre-populated Alarm IDs up to 300 to help with the reservation process. Would this also benefit dialin if we reserve up to 300?

· /leahi_dialin/common/generic_defs.py	(-13, +361)	| History	| Source	| Diff
· /leahi_dialin/common/td_defs_proxy.py	(-0, +15)	| History	| Source	| Diff
· /leahi_dialin/dd/dialysate_delivery.py	(-2, +4)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/balancing_chamber.py	(-7, +5)	| History	| Source	| Diff
· /leahi_dialin/td/treatment_delivery.py	(-0, +2)	| History	| Source	| Diff
· /leahi_dialin/utils/abstract_classes.py	(-0, +56)	| History	| Source	| Diff

]]> Tue, 21 Jul 2026 16:14:03 -0700 Zoltan Miskolci https://devapps.diality.us/changelog/leahi-dialin?cs=4bbcf07a714e5b38fb117023694cb0be0bd3815d https://devapps.diality.us/changelog/leahi-dialin?cs=4bbcf07a714e5b38fb117023694cb0be0bd3815d Zoltan Miskolci committed 4bbcf07 on branch LDT-5152-handler_refactor, LDT-5205-dd_nvm_update and 4 more in leahi-dialin - fixed msg_id imports - updated td treatment

· /leahi_dialin/common/override_templates.py	(-5, +5)	| History	| Source	| Diff
· /leahi_dialin/dd/dialysate_delivery.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/fp/filtration_purification.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/protocols/CAN.py	(-1, +3)	| History	| Source	| Diff
· /leahi_dialin/td/modules/treatment.py	(-125, +137)	| History	| Source	| Diff
· /leahi_dialin/td/proxies/ui_proxy.py	(-1, +2)	| History	| Source	| Diff
· /leahi_dialin/td/treatment_delivery.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/utils/abstract_classes.py	(-1, +1)	| History	| Source	| Diff

]]> Tue, 21 Jul 2026 09:52:43 -0700 Vendor - TEL - Arpita Srivastava https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-3735-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-3735-1 Vendor - TEL - Arpita Srivastava Closed LEAHI-DIALIN-LDT-3735-1 ]]> Tue, 21 Jul 2026 09:13:52 -0700 Zoltan Miskolci https://devapps.diality.us/changelog/leahi-dialin?cs=3f4937e339925dde0b95f08e49969f8983c5cba4 https://devapps.diality.us/changelog/leahi-dialin?cs=3f4937e339925dde0b95f08e49969f8983c5cba4 Zoltan Miskolci committed 3f4937e on branch LDT-5152-handler_refactor, LDT-5205-dd_nvm_update and 4 more in leahi-dialin Refactor changes #1

· /leahi_dialin/common/msg_defs.py	(-152, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/dialysate_delivery.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/alarms.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/balancing_chamber.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/blood_leak.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/concentrate_pump.py	(-2, +2)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/conductivity_sensors.py	(-2, +2)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/dd_test_configs.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/dialysate_pump.py	(-2, +2)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/drybicart.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/events.py	(-142, +109)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/gen_dialysate.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/heaters.py	(-2, +2)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/levels.py	(-2, +2)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/mixing_cntrl.py	(-1, +1)	| History	| Source	| Diff
… 49 more files in changeset.

]]> Tue, 21 Jul 2026 07:29:20 -0700 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-3735-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-3735-1 Raghu Kallala finished reviewing LEAHI-DIALIN-LDT-3735-1 LEAHI-DIALIN-LDT-3735_System Data and Logs - DD - Non-Volatile Memory - 04: DEV - Feature Implementation ]]> Mon, 20 Jul 2026 12:34:32 -0700 Dara Navaei https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-5152-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-5152-1 Dara Navaei started review LEAHI-DIALIN-LDT-5152-1 ]]> Mon, 13 Jul 2026 14:46:50 -0700 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-3735-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-3735-1 Tiffany Mejia and Michael Garthwaite finished reviewing LEAHI-DIALIN-LDT-3735-1 LEAHI-DIALIN-LDT-3735_System Data and Logs - DD - Non-Volatile Memory - 04: DEV - Feature Implementation ]]> Sun, 12 Jul 2026 23:43:02 -0700 Behrouz NematiPour https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4484-1/#c30436 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4484-1/#c30436 Behrouz NematiPour replied to Zoltan Miskolci in LEAHI-DIALIN-LDT-4484-1

Zoltan and I had a meeting, and the counter solution he provided works better than mine.
He explained to me that my proposed solution has flaws.
RESOLVED.

· /leahi_dialin/common/generic_defs.py	(-0, +100)	| History	| Source	| Diff
· /leahi_dialin/common/td_defs_proxy.py	(-0, +6)	| History	| Source	| Diff
· /leahi_dialin/td/modules/alarms.py	(-168, +343)	| History	| Source	| Diff
· /leahi_dialin/utils/abstract_classes.py	(-0, +128)	| History	| Source	| Diff

]]> Mon, 06 Jul 2026 15:08:42 -0700 Vendor - TEL - Santhoshkumar Reddy Alasandagutti https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4160-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4160-1 Vendor - TEL - Santhoshkumar Reddy Alasandagutti Closed LEAHI-DIALIN-LDT-4160-1 ]]> Thu, 02 Jul 2026 15:11:45 -0700 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4160-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4160-1 Vinayakam Mani finished reviewing LEAHI-DIALIN-LDT-4160-1 LEAHI-DIALIN-LDT-4160_[Request] Get function for full detailed Alarm Table ]]> Wed, 01 Jul 2026 14:28:52 -0700 Zoltan Miskolci https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4484-1/#c30320 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4484-1/#c30320 Zoltan Miskolci replied to Behrouz NematiPour in LEAHI-DIALIN-LDT-4484-1

The approach of what this code does and the conversion module are similar in function but a differ on maintenance and flexibility.
1. The conversion module's bytearray to value methods work, but they require manual logistic around the indexing. It's the user's responsibility to handle where the reading starts and you need to code the handler for that (previous approach with MsgFieldPositions), It's inflating the method. I worked hard to remove the need for indexing where the value starts. Instead of the previous struct.unpack approach, where you needed to maintain the type, you will be needing to maintain the conversion methods that are being called, so it would be the same as before, you still need to mind the indexing, which was the main reason of changing from this approach.

2. In the current approach, you declare the type and pass it to a processor that dynamically handling the unpack type (based on the set datatype) and the indexing for that. This works much better and easier to maintain, as you can just insert a new value when it's added to the FW, and don't need to adjust all your indexes for the reading.

Example #1, changing build type from U16 to U08:

• with the conversion approach, you need to change the function used, and update the starting index for all the following methods.
• with the current approach you change the Datatype.U16 to Datatype.U08 and that's all you need to do.

Example #2: adding a new variable fpga_micro after fpga_minor, with U08 type:

• with the conversion approach, you add the bytearray_to_byte, update the indexes for all the following reads.
• with the current approach you insert an element after the fpga_minor with a value ('fpga_micro', Datatype.U08), and nothing more needed

RESOLVED for now.

I would not do that because the function names and messages for each project should be different to avoid confusion.
I think that is fine for now.

RESOLVED.

even though we are sending U08 at Firmware. Due to structure padding Raw message for priority is converted as 16 bits. While receiving we need to read them as U16. Here is my debug values [CortexR4] ALARM_PROP_T size = 22 bytes
byte[0] = 0x03
byte[1] = 0x00
byte[2] = 0x6F
byte[3] = 0x00
byte[4] = 0x01
byte[5] = 0x00
byte[6] = 0x00
byte[7] = 0x01
byte[8] = 0x00
byte[9] = 0x00
byte[10] = 0x01
byte[11] = 0x00
byte[12] = 0x00
byte[13] = 0x01
byte[14] = 0x00
byte[15] = 0x00
byte[16] = 0x01
byte[17] = 0x00
byte[18] = 0x00
byte[19] = 0x01
byte[20] = 0x0A
byte[21] = 0x00

This is structure defined at firmware side
struct AlarmTableRequestPayload

;
typedef struct AlarmTableRequestPayload ALARM_PROP_T;

So the same channels are used for both the Leahi and Denali?
I am not talking about how collisions are handled; that is handled by the CAN driver, not the FW or SW.
My point is that the CAN Channels by themselves do not have the meaning we want; they are only a priority.
As we defined them, we gave them a meaning as a category; therefore, it is better to name them the Denali/Leahi Channels rather than the CAN Channels.

RESOLVED.