Issues with symbolic variable RB1 and RB2

[bigl00z3]

Describe the bug
I am having issues with formulas using RB1 or RB2 symbolic variable
When working with R1 and R2 is normal.

To document the error correctly, I did an Artisan factory reset and then added a single device (Phidget 1045 IR). Settings and used alog are in attachement

If Trying to plot RB1 and RB2 (with " *k+0 " factors in order to plot on the C/min axis) both curves should be matching the background curves (note in the below settings I also plot R1 and R2 with a delay of -3 to test):

But they are not:

The pink curve which is a plot of RB2 (=Background BT RoR) does not have the same slope as the background RoR (light blue curve).

If in addition I apply any time factor to RB1 or RB2 using the " [-10] " format, I get the " u.u" value:

in order to better understand the issue I tried to remove the " *k+0". This gives the same lack of data "u.u"

Expected behavior
RB1 and RB2 plotted curves should match ET and BT background RoR
RB1[-n] and RB2[-n] should display a shifted value by "n" itteration instead of gicving an error.

Setup (please complete the following information):

• Artisan Version [e.g. v2.4.4]: 2.8.0
• Artisan Build (number in brackets shown in the about box) [e.g. 97e6dec]: 682bdaf
• Version [e.g. 22]:
• Platform (Mac/Windows/Linux + OS version) [e.g. macOS 10.15.3]: Windows
• Connected devices or roasting machine [e.g. Probatone 5]: Phidget 1045 IR

Please attach your current Artisan settings file (as exported via menu Help >> Save Settings as *.aset) file.

Files aset and alog.zip

[bigl00z3]

You can close this issue.
But for the history in case someone is searching on this topic I will document a few points below.

In the mean time, a big thank you to the Artisan team for the continuous amazing work and quality that they deliver all the time!!!

Nico

---

After some offline discussions including explain better the reason of my original question (which was for a 30s lookahead of the background RoR value):

• The index access for RBn is currently not implemented and would not be that straight forward to put in place (index is not time and you need to convert it). They are other implementation with higher priorities with the limited available resources (all good with that).

• The reason why on the above graph the RoR curve and the Background RoR curve (RB2) do not have the same slope was in fact my mistake and it was due to different sampling rate (Background at 1 second and the foreground at 2 seconds).

I anyway learned a few things related to the above topics. Which I thought I could take the opportunity to share here:

• When working with 2 files of different sampling rate if it causes any issue, a quick fix can be to "convert" the file at the different sampling rate by playing it in the Simulator and saving the file under a new name.

• If absolutely requiring to display a lookahead of a background value where the index access is not implemented there would still be an indirect way (in the end I will not need this but I just tried it for the sake of the exercise 😉 ):

1. Open the .alog file to be used as a background
2. Export the file to csv format (File/Export/Artisan CSV…)
3. Open the csv file in Excel (Text to Column to reformat)
4. Add one column with the calculated value (for example, in my case I copied and pasted my RoR values shifted verticaly by 30 seconds. But you could do all sorts of calculations in between the values)
5. Export the Excel file to .txt format (Note: not to csv but txt)
6. Before importing back into artisan, you will probably need to cleanup the extra "tab spacing" at the end of each line. You can do this easily by opening the file in your favorite text editor (most editors will allow you to copy the extra tab characters and by using the "search and replace all" option change it everywhere in one go). Save the file.
7. In Artisan, Import the reworked file using File/Import/Artisan CSV…

[MAKOMO]

Index access for RB1/RB2 fixed and interpretation of index access for symbolic variables RB1, RB2, B1, B2,.. interpreted now w.r.t. foreground time respecting background alignment (Commit cfbcb50)