3.1.0 Crashed shortly after Charge, Win 11.

[oldsparks]

Report.wer.txt
I've been using Artisan for a couple of years. I have two roasters and so I have two config files I load an use on the same laptop. I had just finished a couple of roasts using one roaster which uses a Phidget config and then shifted over to my other roaster. I loaded the config for that roaster and then loaded up a previous .alog file for the bean I was preparing to roast. I was using the laptop off battery with USB MODBUS connection.

Everything looked fine, temps were displaying and all looked normal. I have it set for Autocharge and I had the roaster dropping to charge temp and I charged as normal. After closing the hopper and pushing start on the roaster timer I glanced at the screen and was looking at my charge temp against my background and was satisfied I hit my target OK. I started to watch the drop of the BT curve heading for TP and then Artisan just crashed. I don't even know if it crashed. It just went away. Boom! Suddenly there was no more Artisan window.

I had to scramble for a minute as I was now going to have to adjust to roasting manually. After I got pencil and paper together and got my initial gas setting going I launched Artisan again. It came up without the last loaded profile and for some reason it launched two windows. One was the interactive window and the other was the read only window with the same profile loaded.

At that point I just shut down both windows of Artisan and then reopened it. It came up again with the same profile but only one window this time. I loaded the profile that I had originally had loaded for the roast so I had something to go by but by then I was almost 2 minutes into the roast so I just flew by the seat of my pants and the information I had displayed.

I think this is now the second time this has happened to me. I never posted about the first one and just chalked it up to something odd and I have done several roasts since then without issue. But now I'm rather worried whether I can rely on the software not to just vanish after I've started a roast. I wish I had jotted down more notes about the first crash like this but I didn't. I usually have the laptop plugged in when roasting and I can't say if I did the last time it did this or not.

I do recall the first time it crashed my Internet connection had gone down during the roast (GFCI Outlet on the Internet modem) and I do use and connect to Artisan+. I think I chalked up the first crash to possibly be related even though it didn't make sense to me why it might.

Laptop is a fairly new Lenovo 2 in 1, Intel Ultra 5 processor. Roaster is a Yoshan DY2 (2kg). Yoshan does have some kind of MODBUS gateway. I don't know what else to call it. Basically the TC's are connected to the PID's and the PID's are daisy chained and then output 485 to the gateway. So Artisan is talking to the gateway board rather than to the PID's directly. I know that this board queries the PID's for data and then stores it in its own registers. The registers I query via MODBUS are not the same registers on the PIDs. It's a bit of a "black box" to me. One day I think I might look at circumventing that board with a USB to 485 opto-isolated converter and call it good. Not sure if it's a good idea or not. Anyway, off topic. Not sure why this has happened to me twice now and it's rather scary to think Artisan can just shut down randomly during a roast. Any ideas?

Config file in use during event uploaded as text. Also I think I managed to upload the Windows Error Report as .txt.
DY2-C_Mode_5kPa.txt

[poundy]

the "two instances" behaviour seems likely that you just clicked to start the app twice, could easily happen while you're in a scramble to get things back up and working. If that ever happens again, it is completely safe to simply close down the Artisan Viewer mode app and continue using the "real" app as Artisan has built into it this viewing mode and will only ever run one instance that will attempt to connect to roasters.

The issue of the app crashing, I have not ever observed that myself, nor have there been many reports that I can recall. Can you look at the event log on your PC and see whether Windows recorded any detail about the crash? You might find event entries like event ID 1000 for "Application error" and event ID 1001 for Windows Error Reporting, that might show details that are useful.

It is possible that without the internet, the Artisan+ connection fails - as I'm not a subscriber I can't relay any useful experience, but that does seem to be an area worth exploring if you choose. As we don't see these reports of app crashes often, I would not be broadly concerned about reliability - but again, YMMV. When I was reading through your story, I wondered if you knew whether the first crash you saw (not the one that prompted this post) was before or after you swapped roasters ? I was thinking that one thing you could try, between roaster sessions, is to load your new roaster settings, then quit and reload Artisan and then move onto roasting with your second roaster. It could be a cumulative issue, and the more batches you roasted along with the swap of configurations in the middle may be causing some strange behaviour. I can be pretty sure that there would be very few people actively roasting on two different roasters from the one laptop/pc in a single session, which makes your work practice unique.

[oldsparks]

Appreciate the reply. To add to this; I went back out after posting and just wanted to see if it might happen again with the Laptop on battery. It did. But not in the same way. The roaster was still cooling down but operating, fan and drum turning. I plugged in the laptop, started Artisan and fired up the roaster to warm. I had Artisan in the ON mode and then I left to go use the restroom. When I came back I found that Artisan was again GONE. Not running. Also the roaster had shut off the gas. I'm not sure why it did that but I would think that somehow they are related. The PID has a SV of 240C to shut off the gas but it was just coming up from about 15C and so wasn't even warmed up above 100C yet. I started Artisan again, and then hit the igniter and let it warm up for a while. This time there was no issues. So at this point it's still a rather random event. Not helpful.

So, I don't believe the first time this happened I had been using the other roaster or config, though it's entirely possible I had the other config loaded previously. Because I often sit and analyze previous roasts it's not at all uncommon for me to load one config or another so I can look at the log file with the appropriate configuration loaded. Not only are the axes off but one is in Centigrade and one in Fahrenheit among other things.

To address your comment regarding the two windows. Yes, it's quite possible that I accidently clicked twice on the icon in the task tray. So we can forget about that issue.

I do have a log entry related to both the initial crash and also the later crash when I was in the restroom. Timestamp 1:33:43 PM was the initial crash while roasting.

Log Name: Application
Source: Application Error
Date: 4/11/2025 1:33:43 PM
Event ID: 1000
Task Category: Application Crashing Events
Level: Error
Keywords:
User: LENOVO_7I\NORTH
Computer: Lenovo_7i
Description:
Faulting application name: artisan.exe, version: 3.1.0.0, time stamp: 0x673d982f
Faulting module name: python312.dll, version: 3.12.5150.1013, time stamp: 0x66b28bbb
Exception code: 0xc0000005
Fault offset: 0x00000000000490e6
Faulting process id: 0x4954
Faulting application start time: 0x1DBA963C49B00E0
Faulting application path: C:\Program Files\Artisan\artisan.exe
Faulting module path: C:\Program Files\Artisan_internal\python312.dll
Report Id: 1840241e-64a5-4c99-8020-476679568468
Faulting package full name:
Faulting package-relative application ID:
Event Xml:



1000
0
2
100
0
0x8000000000000000

17206


Application
Lenovo_7i



artisan.exe
3.1.0.0
673d982f
python312.dll
3.12.5150.1013
66b28bbb
c0000005
00000000000490e6
0x4954
0x1dba963c49b00e0
C:\Program Files\Artisan\artisan.exe
C:\Program Files\Artisan_internal\python312.dll
1840241e-64a5-4c99-8020-476679568468

Second crash --

Log Name: Application
Source: Application Error
Date: 4/11/2025 2:44:55 PM
Event ID: 1000
Task Category: Application Crashing Events
Level: Error
Keywords:
User: LENOVO_7I\NORTH
Computer: Lenovo_7i
Description:
Faulting application name: artisan.exe, version: 3.1.0.0, time stamp: 0x673d982f
Faulting module name: python312.dll, version: 3.12.5150.1013, time stamp: 0x66b28bbb
Exception code: 0xc0000005
Fault offset: 0x0000000000042ad5
Faulting process id: 0xC4C
Faulting application start time: 0x1DBAB2CC9E73FE7
Faulting application path: C:\Program Files\Artisan\artisan.exe
Faulting module path: C:\Program Files\Artisan_internal\python312.dll
Report Id: eba28f6e-a544-48a5-a760-dca61fcb7f0c
Faulting package full name:
Faulting package-relative application ID:
Event Xml:



1000
0
2
100
0
0x8000000000000000

17228


Application
Lenovo_7i



artisan.exe
3.1.0.0
673d982f
python312.dll
3.12.5150.1013
66b28bbb
c0000005
0000000000042ad5
0xc4c
0x1dbab2cc9e73fe7
C:\Program Files\Artisan\artisan.exe
C:\Program Files\Artisan_internal\python312.dll
eba28f6e-a544-48a5-a760-dca61fcb7f0c

[MAKOMO]

There are close to zero crash reports on Artisan since years. Non for the current v3.1!

Could you please attach your artisan.log files? Click the plus icon in the upper left corner while holding the ALT key. An email window should open with the log files attached. Either drag them out, rename them to end in .txt and drag-and-drop them here on GitHub on a comment field in this thread or just send the email to the given address.

Artisan is composed up from many other open-source software packages where each could have issues under certain conditions or on certain platforms. You mention a Phidget setup. Even if you are now using MODBUS this driver is loaded. Do you have the latest Phidgets driver installed? Do you have the lastest serial driver for your serial-2-485 interface? I am asking as to my experience of the past 10 years such random crashes usually occur in some communication driver sitting in-between Artisan and the OS, often triggered by some ground loop noise or electromagnetic influence on the weakly shielded communication lines from motors. Lost some weeks investigating one uses crashes which at the end of this week told me that he is roasting under a vent hood and the crash happens always when he starts that vent hood. Well....

[oldsparks]

Logs sent.

I do have the latest Phidgets driver installed. Also apparently the latest for the USB/Serial driver.

The fact that the second time it did this yesterday I found the gas solenoid had also tripped shut I am suspecting an electrical ground loop issue of some sort. Hence why I am thinking of an opto-isolated 485 converter to replace the board in the roaster. I'd love to know the real culprit in the hardware too.

For now I'll plug i the laptop when using Artisan with this roaster. And FWIW, as far as the electrical connections go, the roaster is plugged into a surge suppressor strip on my bench and when I plug in the laptop it is plugged into the same strip, so all off the same circuit. Nothing else using the circuit.

Let me know if there's anything else I can do to help.

[MAKOMO]

Logs sent.

Where did you sent it? Nothing received on [email protected]. Could you please resent to [email protected]?

[oldsparks]

I just resent to logfile and CC'd to info. I show both emails in my SENT folder.

[MAKOMO]

Received your emails now. Second sent 3 min after the first. Thanks!

The moment of the crash should be this one (the last line corresponds to your restart of Artisan):

04-11 13:31:02 MainThread artisanlib.canvas    INFO   : MODE: ON MONITOR (sampling @1.0s)
04-11 13:33:13 MainThread artisanlib.canvas    INFO   : MODE: START RECORDING
04-11 13:33:16 Dummy-24   artisanlib.main      INFO   : Artisan Command <0.0kPa> not recognized
04-11 13:33:39 Thread-23 (start_background_loop) pymodbus.logging     ERROR  : No response received after 0 retries, continue with next request
04-11 13:33:39 Thread-23 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => received exception from device
04-11 13:33:39 Dummy-22   artisanlib.modbusport INFO   : readFloat(1,4,3,False) failed
04-11 13:33:39 Dummy-22   artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 13:33:40 Thread-23 (start_background_loop) pymodbus.logging     ERROR  : No response received after 0 retries, continue with next request
04-11 13:33:40 Thread-23 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => received exception from device
04-11 13:33:40 Dummy-22   artisanlib.modbusport INFO   : readFloat(1,6,3,False) failed
04-11 13:33:40 Dummy-22   artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 13:33:41 Thread-23 (start_background_loop) pymodbus.logging     ERROR  : No response received after 0 retries, continue with next request
04-11 13:33:41 Thread-23 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => received exception from device
04-11 13:33:41 Dummy-22   artisanlib.modbusport INFO   : readFloat(1,4,3,False) failed
04-11 13:33:41 Dummy-22   artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 13:33:42 Thread-23 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => None
04-11 13:33:42 Dummy-22   artisanlib.modbusport INFO   : readFloat(1,6,3,False) failed
04-11 13:33:42 Dummy-22   artisanlib.modbusport INFO   : MODBUS disconnectOnError: 0
04-11 13:33:42 Dummy-22   artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 13:34:04 MainThread artisanlib.main      INFO   : Artisan v3.1.0 (a0c9448, 0)

Artisan should not terminate under such condition and just disconnect and reconnect on next sampling, which seems to have happend, just on this reconnect Artisan crashed (or got terminated by Windows). Thus I can only guess that at least the device driver was in bad conditions at that stage.

Something very bad must have happend here with the connection to your machine. Either the serial driver died, the serial-to-485 converter stopped working or the modbus PID device in your machine stopped responding (or all together).

There are also network connection problems logged here and there, but they seem not to be involved into the crashes. Server communication happen always in parallel and if it fails requests are queued and send later. This should never lead to a crash or any other problems.

Similar communication issues happend a little later, but here things did not crash

04-11 14:55:10 MainThread artisanlib.canvas    INFO   : MODE: ON MONITOR (sampling @1.0s)
04-11 15:00:27 Thread-3 (start_background_loop) pymodbus.logging     ERROR  : No response received after 0 retries, continue with next request
04-11 15:00:27 Thread-3 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => received exception from device
04-11 15:00:27 Dummy-2    artisanlib.modbusport INFO   : readFloat(1,4,3,False) failed
04-11 15:00:27 Dummy-2    artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 15:00:27 Thread-3 (start_background_loop) pymodbus.logging     ERROR  : No response received after 0 retries, continue with next request
04-11 15:00:27 Thread-3 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => received exception from device
04-11 15:00:27 Dummy-2    artisanlib.modbusport INFO   : readFloat(1,6,3,False) failed
04-11 15:00:27 Dummy-2    artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 15:00:29 Thread-3 (start_background_loop) pymodbus.logging     ERROR  : No response received after 0 retries, continue with next request
04-11 15:00:29 Thread-3 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => received exception from device
04-11 15:00:29 Dummy-2    artisanlib.modbusport INFO   : readFloat(1,4,3,False) failed
04-11 15:00:29 Dummy-2    artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 15:00:29 Thread-3 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => None
04-11 15:00:29 Dummy-2    artisanlib.modbusport INFO   : readFloat(1,6,3,False) failed
04-11 15:00:29 Dummy-2    artisanlib.modbusport INFO   : MODBUS disconnectOnError: 0
04-11 15:00:29 Dummy-2    artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 15:18:47 Thread-4 (start_background_loop) asyncio              ERROR  : Task exception was never retrieved
future: <Task finished name='SerialTransport poll' coro=<SerialTransport.polling_task() done, defined at pymodbus\transport\serialtransport.py:155> exception=AttributeError("'NoneType' object has no attribute 'in_waiting'")>
Traceback (most recent call last):
  File "pymodbus\transport\serialtransport.py", line 161, in polling_task
AttributeError: 'NoneType' object has no attribute 'in_waiting'
04-11 15:18:47 Thread-4 (start_background_loop) pymodbus.logging     ERROR  : No response received after 0 retries, continue with next request
04-11 15:18:47 Thread-4 (start_background_loop) artisanlib.modbusport INFO   : invalidResult(2) => received exception from device
04-11 15:18:47 Dummy-2    artisanlib.modbusport INFO   : readFloat(1,4,3,False) failed
04-11 15:18:47 Dummy-2    artisanlib.canvas    ERROR  : Modbus Communication Error
04-11 15:19:02 MainThread artisanlib.canvas    INFO   : MODE: OFF MONITOR

Not much we can do on this on the Artisan side of things. Sorry.

You might try to shield your communication lines better and use shorter high-quality wires (especially USB), best with ferrits on both ends.

I see that you are sampling at a 1sec rate which might be anyhow a bit high for such a slow 9600 baud serial connection. You might be better off reducing the sampling rate to 1.5sec or 2sec.

Further I spotted the following messages (not related to your crashes) which you might want to correct in your configurations. Here you seem to have choosen Artisan Command as action while the documentation part does not contain vaild Artisan Commands, but just pure documentation. Just set the empty action type for those actions.

menu load recent settings: C:/Users/NORTH/OneDrive/Documents/Artisan/DY2-C_Mode_5kPa.aset
03-19 19:09:05 MainThread artisanlib.canvas    INFO   : MODE: ON MONITOR (sampling @1.0s)
03-19 19:22:37 MainThread artisanlib.canvas    INFO   : MODE: START RECORDING
03-19 19:22:43 Dummy-15   artisanlib.main      INFO   : Artisan Command <0.8kPa> not recognized
03-19 19:25:16 Dummy-16   artisanlib.main      INFO   : Artisan Command <2.5kPa> not recognized
03-19 19:26:18 Dummy-17   artisanlib.main      INFO   : Artisan Command <1.5kPa> not recognized
03-19 19:28:36 Dummy-18   artisanlib.main      INFO   : Artisan Command <1.2kPa> not recognized
03-19 19:30:52 Dummy-19   artisanlib.main      INFO   : Artisan Command <0.5kPa> not recognized
03-19 19:35:18 Dummy-20   artisanlib.main      INFO   : Artisan Command <0.4kPa> not recognized
03-19 19:36:37 Dummy-21   artisanlib.main      INFO   : Artisan Command <0.5kPa> not recognized
03-19 19:37:50 Dummy-22   artisanlib.main      INFO   : Artisan Command <0.0kPa> not recognized
03-19 19:39:04 MainThread artisanlib.canvas    INFO   : MODE: OFF MONITOR

menu load recent settings: C:/Users/NORTH/OneDrive/Documents/Artisan/Roasts/Artisan-Phidget-Contest.aset
04-01 12:35:23 MainThread artisanlib.canvas    INFO   : MODE: ON MONITOR (sampling @2.0s)
04-01 12:35:34 Dummy-3    artisanlib.main      INFO   : Artisan Command <Fan 9> not recognized
04-01 12:35:36 Dummy-4    artisanlib.main      INFO   : Artisan Command <Heat 5> not recognized
04-01 12:37:05 MainThread artisanlib.canvas    INFO   : MODE: START RECORDING
04-01 12:38:29 Dummy-5    artisanlib.main      INFO   : Artisan Command <Fan 8> not recognized
04-01 12:39:36 Dummy-6    artisanlib.main      INFO   : Artisan Command <Fan 7> not recognized
04-01 12:40:38 Dummy-7    artisanlib.main      INFO   : Artisan Command <Fan 6> not recognized
04-01 12:42:36 Dummy-8    artisanlib.main      INFO   : Artisan Command <Heat 6> not recognized
04-01 12:43:02 Dummy-9    artisanlib.main      INFO   : Artisan Command <Heat 7> not recognized
04-01 12:44:23 Dummy-10   artisanlib.main      INFO   : Artisan Command <Heat 8> not recognized
04-01 12:44:50 Dummy-11   artisanlib.main      INFO   : Artisan Command <Heat 9> not recognized

[oldsparks]

Discussing the driver, when I first got this roaster I was using another laptop and I had initially installed the CP210x driver from SILabs. On my current laptop it just seemed to work with the installed windows driver. I'm curious if you would recommend manually installing the SILab driver?

I do have the option of using Bluetooth with this roaster but I have not tried it. Being an old school datacom guy I'm usually more inclined to utilize a cabled connection over wireless when available. In this case I think I'll give the over the air option a chance.

I did clean up the Artisan Commands in the config. I admit I was lazy and it didn't seem to cause harm but it's easy enough to tidy up.

I have decreased the sample rate to 2.0s. The PIDs will go much faster but the 485 converter is a black box to me and so I can't change it's configuration. I don't even know what the sample rate is from that board to the PIDs. But it seems to take the data from the PIDs and then put it in its own memory and changes the ID's and registers. So it's acting as a Modbus master on one side and a slave on the other as well as providing buffering. The power to the board is of course via the USB from the PC. So in other words, the slave that Artisan is querying is always ready to respond with what ever data it has in its registers, or null or zero if there's no data. I can plug in the laptop and turn on Artisan without powering up the roaster or the PIDs and I can monitor the serial data. Perhaps the sample rate was just too fast for the baud rate. I have no idea if the board in the roaster provides isolation.

A better cable with ferrites is an inexpensive item to try. I might even have some old cables squirreled away in a bin in the basement somewhere.

Thanks again Marko. If you could reply on the driver question and then feel free to close this as resolved.

[MAKOMO]

Discussing the driver, when I first got this roaster I was using another laptop and I had initially installed the CP210x driver from SILabs. On my current laptop it just seemed to work with the installed windows driver. I'm curious if you would recommend manually installing the SILab driver?

I am puzzled a bit here. Above you showed screenshots of the Chinese CH340 driver, and now you are talking about the SILab driver. Two different things. The driver to use depends on your USB2485 converter. In modern Windows both drivers seem to be preinstalled. Manually installing/updating those drivers might be even counterproductive.

I do have the option of using Bluetooth with this roaster but I have not tried it. Being an old school datacom guy I'm usually more inclined to utilize a cabled connection over wireless when available. In this case I think I'll give the over the air option a chance.

While a wireless connection has the advantage that potential ground loops between your laptop and the machine are avoided, but I would always argue against wireless connections due to the EMI of the machines motors which can easily disturb wireless communication.

A better cable

and shorter!

with ferrites is an inexpensive item to try. I might even have some old cables squirreled away in a bin in the basement somewhere.

[oldsparks]

The SILab driver was the suggested driver for Yoshan machines on the Artisan Documentation, MODBUS Serial driver cheat sheet. So I had installed that on my previous laptop and I thought I had on the new one, but I'm not sure. I might have just plugged the roaster in with the new laptop and it worked, so I left it. I guess that's why I'm asking.

I suppose I can open up the roaster again and see if I can determine the chipset in use on that converter.

[MAKOMO]

Those vendors build-in hardware that they have at hand. So the converter module can be different on each unit. You should see the chipset of the converter within the Windows device panel (sorry I cannot point you to the exact one as I never used Windows myself).

[oldsparks]

I may be an old guy but I will admit that AI has its benefits. I used to spend countless hours searching or communicating on bulletin board systems back when Linux was pre version 1.0. to research up information about hardware when trying to compile the latest kernel and SCSI support for what ever board I was working with. Now I just ask an AI client how do I find the hardware ID for a UART in Windows and then ask what additional information it has on the resulting hardware ID string. You hardly have to think anymore but what a time saver! ;)

Anyway, it is indeed a WCH chip so I'll just leave the driver alone. Thanks for the help and input. I'll have to see if I can narrow down at least the set of circumstances that triggers this so I can either further isolate it or at least avoid it. I only have about 80 roasts on this machine so far but only 3 crashes of Artisan which really leads me to believe it's electrical noise interference. Honestly I think the best thing for this machine is to use an isolated converter.