Dynamic Views Logic Issue #2

[AuRoN89]

There is another issue in how Dyanmic Views Logic works.

Here how to replicate it:

Setup three views
View 1 (When button X is not pressed, set as Default and set priority to 3
View 2 (when a button X is pressed) and set priority to 1
View 3 (When a button Y is pressed) and set priority to 0

Expected Result
Nothing is pressed = View 1
Pressed button X = View 2
Pressed button Y = View 3

What happens instead:
Nothing is pressed = view 1
Press button X = Dash Switch to View 2
Press button Y = Dash rapidily Switch between View 1 and View 3

The thing is, when you press button Y, BOTH conditions 3 and 1 are true, BUT, condition 1 has priority 3 while condition 3 has priority 0 (highest) so, View 3 should win and be the only one visible.

[craigkai]

I see we actually skip checking the current dynamic config, but we should actually still confirm if it should be active:

diff --git a/main.py b/main.py
index a8c87c96..b38a6fa1 100644
--- a/main.py
+++ b/main.py
@@ -309,19 +309,22 @@ class GUI(App):
                 dynamic_change = False
                 # Check dynamic gauges before any alerts in case we make a change
                 for dynamic in self.dynamic_callbacks:
-                    if str(self.current) == str(dynamic.viewId):
-                        pass
-                    else:
-                        my_callback = self.check_callback(dynamic, data)
-                        Logger.debug(
-                            "Checking dynamic callback for PID: %s, OP: %s Value: %s for view %s",
-                            dynamic.pid.value,
-                            dynamic.op,
-                            dynamic.value,
-                            dynamic.viewId,
-                        )
+                    my_callback = self.check_callback(dynamic, data)
+                    Logger.debug(
+                        "Checking dynamic callback for PID: %s, OP: %s Value: %s for view %s",
+                        dynamic.pid.value,
+                        dynamic.op,
+                        dynamic.value,
+                        dynamic.viewId,
+                    )

                     if my_callback:
+                        if str(self.current) == str(dynamic.viewId):
+                            Logger.debug(
+                                "GUI: Dynamic callback already active for view %s",
+                                dynamic.viewId,
+                            )
+                            break
                         self.count = 0
                         self.change(self, my_callback)
                         dynamic_change = True

I gotta go check if the callbacks are sorted on priority already or not.

[craigkai]

@AuRoN89 would you want to confirm #17 fixes this issue?

[AuRoN89]

@craigkai Just tried your change, but there no difference. You can see the video below ( i just modiefied the main.py file without doing anything else)

The simulator app part of the video looks too bright so it might not be clear, but what i'm doing is just simulating CC ON button to switch from view 1 to view 2 (and it works fine, just like current version) and then use CC OFF button to switch to view 3, but it start rapidly switch between view 1 and 3

config.json

test.mp4

[AuRoN89]

This morning i tested it on car too, and i confirm that it doesn't fix the issue. For some reasons the behavior is different compared to the bench test, probably due to the amount of messages but i'm not 100% sure.

What happen here is that if I set up a third view, whatever the dynamic condition is, as soon as i trigger the view 2 , the view remain stuck to 2, doesn't matter if button remain pressed or not, it remain stuck on that view, and view 3 it's never triggered, whatever i press the button (starting from view 1 or 2 doesn't matter)

[craigkai]

Chatting with Matt on this, and there is a chance we have seen something like this before around the firmware where using a different compiler somehow resulted in dynamic changes only changing once. Likely a memory leak of some sorts.

You have compiled the firmware again right?

[AuRoN89]

Yes i recompiled the firmware few weeks ago after i added some new buttons mapping, but on bench i'm using the same unit, so i cannot understand why it should behave differently. I'm using STM32 1.8.0 (the same used by Matt)

[MattKai45]

What happens if you set the gauges to display the CC OFF and CC ON? Can we verify that there is no loss of real-time data? i.e. those CC ON and CC OFF flags should toggle even if we have an issue with dynamic gauges not switching. This can help determine if it's firmware or software.

[AuRoN89]

I just did that thing (on bench), and this is super weird.

So, if i display the parameters that are also used to change the dynamic views, it works fine! As soon as i remove them, it start flicker beetwen views (as previously reported)

So, to do a shortest as possible recap:

Working Situation:
View 1 = Oil Temp, Boost, ECT. Visible when DIST+ button IS NOT pressed (priority = 1 + Default View)
View 2 = Cat Temp, , IAT, CAT. Visible when DIST+ button IS pressed (priority = 2)
View 3 = AFR, Brake Pedal, SET-. Visible when SET- button IS pressed (priority = 0)

Non Working Situation:
View 1 = Oil Temp, Boost, ECT. Visible when DIST+ button IS NOT pressed (priority = 1 + Default View)
View 2 = Cat Temp, , IAT, CAT. Visible when DIST+ button IS pressed (priority = 2)
View 3 = AFR, Brake Pedal, Timing Advance. Visible when SET- button IS pressed (priority = 0)

As you can see everything is set the same, except that in View 3, instead of the SET- button, which is also the button that control the view, i set any other parameter. I did several test with other buttons, and it behave the same. As long as the button that I display in the view 3 is the same button that also control the view 3, the view 3 is correctly visible, otherwise, it rapidily flicker with view 1.

[AuRoN89]

Here two videos that show both situations.

Working Situation:

VID-20240719-WA0000.mp4

Non Working Situation:

VID-20240719-WA0001.mp4