Modbus ET/BT Measurement issues with Artisan 2.6.0

[PDWest]

Describe the bug
I've been exclusively using Modbus TCP for my data acquisition for several years, but have issues with Artisan 2.6.0. I'm running Artisan on a Macbook Air. Here's the setup info for this post:
Setup:

• Artisan Version 2.4.6 and 2.6.0
• Artisan Build f1b8e57 and 7088095
• Platform macOS 11.6.1

Here is an Artisan 2.6.0 screenshot with ET on the upper trace, and BT (with the probe removed from the roast chamber) on the lower trace. The system sample rate is 1 second.

As can be seen, things start out OK, but at about 4 mins there is a 'probe swap' which corrects itself after 20 seconds or so. This happens again at about 5 mins, then again for a longer period at 9 mins. Then, at about 14 mins things go very bad and the BT and ET actually swap values on every read.
The expected behavior is shown in this Artisan 2.4.6 example

In this example, the sample rate is 1 second and we see only 1 glitch at about 56 minutes: I zoomed in and it appears to be a bad read on the ET, but not a 'swap' as we saw in the Artisan 2.6.0 example.

Thinking that the problem could be purely sample rate related, I relaxed that to 3 second and repeated for Artisan 2.6.0 to get this:

Clearly, the problem is not as bad here, but we do see 'swapping' at 6, 12, 22, 46 mins, and a possible glitch at 52 mins.

Running this case in Artisan 2.4.6 gives:

with no errors.

All of these tests (plus several not cited here) were performed without any resets, restarts, or changes on the roaster side. I simply opened/closed Artisan versions on the Mac to do the tests.
artisan-settings_for_tests.aset.txt

[MAKOMO]

Could you please tell which machine is connected here?
Is this connection via wired network or Wifi?

You have "optimize" in the MODBUS tab turned on. Which is in general good as it fetches full blocks of registers in one request instead of several individual requests which saves bandwith. It turns out that Artisan receives in some cases less data then requested. As Artisan maps the received data to the individual registers based on their index in the result, this can result in wrong mappings if intermediate data is missing in the result. It is unclear where the missing data is lost. Maybe incomplete answers get send, or data is lost on the network or in the MODBUS lib used by Artisan.

In the current development version v2.6.1 incomplete data is rejected by Artisan and re-requested. Could you test if Artisan v2.6.1 performance any better for you?

https://github.com/artisan-roaster-scope/artisan/releases/tag/continuous

Also deactivating "optimize" could resolve the issue for you.

Please report!

[PDWest]

Makomo asks:
Could you please tell which machine is connected here?
Is this connection via wired network or Wifi?

The Modbus server is a headless Raspberry Pi Zero W, running uModbus (https://umodbus.readthedocs.io/en/latest/). The connection is via WiFi.

I first tried unchecking the Optimize box and repeating the test w/Artisan 2.6.0 at a 1 second sampling rate, but saw several swaps in the first 10 minutes.

I then downloaded Artisan 2.6.1, build 4a0ebe7, set it to 1 second sampling, checked the Optimize box, and ran it for a full hour WITH NO ISSUES! I believe this version resolves my problem.

While doing the 2.6.0 test, I noticed that a "Modbus Communications Error" message occasionally appeared (flashed by) and was immediately replaced with "Modbus Communications Resumed" (this message was persistent) just above the main graph in the upper left corner. I did not observe either of these messages in my 2.6.1 test.

[MAKOMO]

Wifi is never a good connection option next to a roasting machines with a motor disturbing the wireless signal. Transmission issues are to be expected.

Strange that you encounter swaps with "optimize" turned off. Maybe the swap happens already "before" Artisan.

Thanks for confirming that the v2.6.1 resolves this issue.

[MAKOMO]

Relates to Issue #883