BT and ET stop plotting on the graph (but are saved)

[bigl00z3]

Expected Behavior

BT & ET curve should be plotted all the time during roast on the graph.

Actual Behavior

At some point during the roasting, THE ET & BT curves are not visible anymore.
The error message is displayed at the top left of the graph:

_

Exception: redraw() x and y must have the same first dimension, but have shapes (1058,) and 1056,)@line 5530

_

another message example:

_

Exception: redraw() x and y must have the same first dimension, but have shapes (1247,) and 1246,)@line 5530

_

When stopping the roast the curves are plotted correctly again.

Steps to Reproduce the Problem

(note: does not happen all the time)

1. Start the roast
2. at some point, from what I've seen after Charge, TP and DE (but it does not mean it won't happen at other times) BT and ET curves are not plotted anymore. This happens until STOP.

Specifications

• Artisan Version: 1.6.0
• Artisan Build (number in brackets shown in the about box): e7ec8d3
• Platform (Mac/Windows/Linux + OS version): Raspbain Stretch
• Connected devices or roasting machine: Phidgets (1048, HUB0000, HUM1000, PRE1000, 1135)

Please attach your current Artisan settings file (as exported via menu Help >> Save Setings as *.aset) file.
Please attach any relevant Artisan *.alog profiles.

artisan-settings Pi A+ 1.6.0.aset.txt

Note that you need either add a .txt extension or zip the files before uploading. Otherwise you will receive a "Not a supported file type" error on uploading.

[MAKOMO]

Nico, could you send me one of those alog file that caused the redraw issue during logging and showed without issues after stopping the roast? Thanks!

[MAKOMO]

Just one comment from inspecting your settings: I see that your FCs button is sending out a serial command that looks like a command to a TC4. However, you seem not to have connected a TC4 in your setup. I would rather remove or deactivate this command by setting the action popup of the FCs button to the empty entry. Most likely totally unrelated to this issue....

[MAKOMO]

Hopefully fixed by commit 8075943. Thanks for reporting!

I'll keep this open until you confirm that the fix works as expected.

[bigl00z3]

Seems to be working fine. I haven’t seen any issues anymore.

[MAKOMO]

Nico, thanks for this verification. Your report was a very important one, although I never thought to find that cause of this as it sounded wired and I could not reproduce it. On just reading code I found than this possibility that a lock of a critical resource could leak under certain conditions (especially on slow computers like the RPi). That leaked lock could lead also to other unexpected (by the programmer) situations up to random crashes. Good that I catched this one triggered by your report even if it could turn out not the original cause. For now I will close this issue, but keep an eye on those locks. Thanks Nico!