bn approves

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.

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.

· /leahi_dialin/common/dd_defs.py	(-5, +7)	| History	| Source	| Diff
· /leahi_dialin/common/msg_ids.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/dd/modules/conductivity_sensors.py	(-59, +22)	| History	| Source	| Diff
· /leahi_dialin/fp/modules/conductivity_sensors.py	(-7, +27)	| History	| Source	| Diff
· /leahi_dialin/ui/fp_messaging.py	(-46, +30)	| History	| Source	| Diff

]]> Mon, 29 Jun 2026 18:26:49 -0700 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4747-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4747-1 Sean Nash left LEAHI-DIALIN-LDT-4747-1 LDT-4747: SW Integration - FP Diagnostics - DialIn ]]> Mon, 29 Jun 2026 18:25:59 -0700 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4787-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4787-1 Sean Nash left LEAHI-DIALIN-LDT-4787-1 LEAHI-DIALIN-LDT-4787_NON-FEATURE: SW Misc & Enhc - SW - 01 - Power Control - Shutdown - R&I ]]> Mon, 29 Jun 2026 14:19:39 -0700 Nicholas Ramirez https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4787-1/#c30202 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4787-1/#c30202 Nicholas Ramirez replied to Zoltan Miskolci in LEAHI-DIALIN-LDT-4787-1

added name to freed up mesg id

updated

address cr commetns

· /leahi_dialin/common/msg_ids.py	(-1, +1)	| History	| Source	| Diff
· /leahi_dialin/ui/td_messaging.py	(-1, +1)	| History	| Source	| Diff

]]> Mon, 29 Jun 2026 09:28:46 -0700 Zoltan Miskolci https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4484-1/#c30193 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4484-1/#c30193 Zoltan Miskolci replied to Behrouz NematiPour in LEAHI-DIALIN-LDT-4484-1

Being generic is the whole point of it.
It was renamed because this is a dialin dedicated to Leahi unit and calling the messages DenaliMessage is misleading.
It was renamed to CanMessage for 2 reason:
1. This is a Leahi only dialin, so there is no need to differentiate between different type of Can Messages as there would be only 1 type
2. Calling it CanMessage will make it more future compatible when the dialin get copied over for a new unit development (unlikely in the foreseeable future but possible), removing the need to rename it again

There is no Leahi or Denali CANChannels.
There are CAN channels and the naming is what that channel is being used for.
The collision occurs in the FW and the FW handles it before sending out a message.
When reading a CAN, there are no collisions, so there are no priorities. So I have no clue what you want here.

done

I have no idea what you are referring to as the link is not working.
The need to define the type and the name of the data being read is necessary, so if it's not here it will be somewhere else, that we can't escape.
Exporting that to different files won't serve a purpose and will only increase complexity as when debugging you will need to reference a separate file.
For the defs it made sense as they are used multiple places, but what a message contains is a single use place, so storing it separately is meaningless as it won't have any use outside of this single function.

I am happy to see that this old code is improving.
I would recommend using the Conversion module instead of strings and DataTypes, as it handles everything automatically.
Examples can be found in the following file in this CR:
https://devapps.diality.us/cru/#LEAHI-DIALIN-LDT-4484-1CFR-84688

Please add a docstring for the function.
including the intention and parameters with their intentions.

Same for CanChannels.
The Channels we are referring to here are Leahi's or Denali's.
Channels mainly have no meaning beyond their priorities when a collision occurs.

I recommend DenaliMessage or LeahiMessage, as CanMessage is generic, whereas Leahi/Denali indicate that the protocol is also implemented in the message we are sending.
I'm not sure why the name was changed, as it is a lot of change.
Also, there is no CAN Message.
There is a CAN Frame and a Leahi/Denali Message.

change to td_powerOff_wARNING

Could you just leave it as or TBD_B7 = 0xB7 ?
So it will be easy to see that the msg id location is free to use

add power off watrning

· /leahi_dialin/ui/td_messaging.py

(-0, +7)

| History

| Source

| Diff

]]> Tue, 23 Jun 2026 15:10:08 -0700 Nicholas Ramirez https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4632-1 https://devapps.diality.us/cru/LEAHI-DIALIN-LDT-4632-1 Nicholas Ramirez Closed LEAHI-DIALIN-LDT-4632-1 ]]>