Dear Artisan user group;
I have received an error I have not seen before using a Mac with the latest solfware : Sierra with a 64 bit system.
We have installed the CP210 driver with our data logger using Omron controls.
Here is a screen shot:
Modbus Error: Read float() hex() argument can't be converted to hex@line 30521
Could it be we have the wrong driver installed?
We use to use the FT232 driver but data driver was upgraded to a new model that has worked with the CP210 driver on most models (this data logger is setup for future use with Bluetooth capabilities)
On the device page https://artisan-scope.org/devices/meters/
I read that the optically isolated Victor 86B is compatible with Scope,
while others say Scope do not work with USB HID devices, such as the Victor
My Victor 86B shows up in the device manager under USB HID devices in win 7.
In Artisan 2.0.0 Scope config devices is set to Meter/Victor 86B after
which a port config window appears to select a com port.
I have installed the CP210X driver, and would expect a virtual comport to
show up, when the Victor 86B is connected, but that does not seem to happen.
Any suggestions to cure the problem, please let me know.
Alternatively, for two K-type sensors, which optically isolated solution is
the choice for Artisan Scope 2.0.0, please.
Thanks in advance,
Recently the batch numbers reset to 0 and started counting up again. I try
to change it back, but it won't stick. How can I set the Batch counter
back to the correct number? Config...Batch... is not working.
you forgot the CC to the list. I added that back.
> On 29. Apr 2020, at 17:12, Dave Ewald <dave(a)deftcoffee.com> wrote:
> Hi Marko,
> Sorry that I was not being clear enough.
> inline below hopefully fills in the details:
> And a clarification on what I am seeing. The numbers as absolutes may be correct, but the math is not showing ±, which was throwing me off before. My fault for not being more accurate in how I reported that.
You have a symbolic formula "x-4" on BT (and also ET) that adds an offset. The reference to data in symbolic formulas to other channels accesses the data of those BEFORE the application of the symbolic formula is of it is evaluated. This is to avoid cyclic definitions and is maybe not well documented (as some finer other aspects of the symbolic formula evaluation mechanism). This throws your comparison off. You need to add the very same offset where you refer to Y2.
> Also for comparing ∆BT. What I’m looking for is to pull that same data from the profile and display that, but not sure how to reference that, so all I am showing is the simple difference between the current data and data from 15 seconds ago for both the current roast in progress and the profile.
Let me start with a side note: the index -15 you are using here is just an index and not the time in seconds. In your case this is about the same as your sampling frequency is 1sec.
> What I probably should have asked was how is ∆BT calculated (what is the formula) so that I can apply that to the background profile, and then compare those two sets of data as the roast progresses
The pure RoR signals are in any case too noisy to bring success here. The basic calculation of the RoR is standard and eg. documented here
The tricky part is the smoothing to get readable values out of this raw signal. Those computations are way to complex to be processed or even expressed as an Artisan symbolic formula.
Note that the RoR signal is also bound to a symbolic formula (after CHARGE):
R1 : ET rate of rise
R2 : BT rate of rise
see the same document linked above.
The background RoR is not yet linked in the current v2.1.2, but will be linked in v2.4 to
RB1 : background ET rate of rise
RB2 : background BT rate of rise
(just added this)
> Dave Ewald
> Deft Coffee Roasters | 503.702.1932 | a small part of something more
> On Apr 28, 2020, 11:44 PM -0700, Marko Luther <marko.luther(a)gmx.net>, wrote:
>> - What is your Artisan setup (export via menu Help >> Save Settings)?
>> - What is your exact extra device setup you added to show this variance that is not reading the same!?
Hard to read at that low resolution. Sorry.
>> - What are the two profiles you are comparing (please attach your .alog files)?
> attached is one roast from last night where you can see that the drying time is a bit slow compared to the profile, putting the current roast curve under the profile curve. but the data for 3:56 (∆F | BT - pBT, where BT is the current roast & pBT is the profile data) is 5.6. That may be about accurate, but it should be negative.
As the background profile was not in the package I could not reproduce this one in detail. I guess adding that Y2 offset to your formula as discussed above should resolve this one.
>> - Attach pictures such that we can see what you mean by "watching the events ... are not reading the same”.
> So here the roast was early before the machine warmed up enough, and the early part of the roast was a tad slow, so I would expect to see the difference between BT & pBT at the end of drying to be negative. but it was 5.6. It may be -5.6, but it’s not showing it as that, and I don’t have the formula set up to return an absolute number, so why is BT-pBT giving me 5.6? For reference, in extra device terms, BT=Y2, and pBT=B2)
Hope this helps,