View Thread

HarryDog wrote:

So I have tested this code change and I can set 5 event buttons in one Multiple event sequence with no sleep and all executed, Now I did see one oddity that if you are testing this with say 3 fan changes (35%, 50%, 100%) the first one I cannot detect visually on the slider that it executed but the second and third I can see on the slider.
No one would do this anyway, it was just my first test.

I do think it executed because if I add the sleep I see the change on the slider using 5 event buttons 3 are not fan changes, none are skipped in that test.

I also tested with extra Event Buttons in between fan changes so I have the chance to see the change and that worked as well.

Just in case anyone was wondering about this edit.

renatoa wrote:
That line should be replaced by

renatoa wrote:

For losing commands execution I think the culprit is here:



https://github.co...d.ino#L282

If many commands from Artisan are accumulated in the serial line buffer, the line above reads them all, clearing the buffer, but only the first is executed, the others are lost.

That line should be replaced by



... which reads only the first command, until reaching end of line, without clearing the rest of the commands in buffer, if more...
The command just read is executed, then next loop the second command in the buffer is fetched, and so on.

You have nothing to lose to give it a try...

ctjameson wrote:

Did you ever have any case of runaway heating element in your testing/errors when roasting like I did?

HarryDog wrote:



No Just lost commands and my Alarms stopped working after testing Multiple events that did not all run, but the Arduino would strangely not run the Alarms after that. Not sure this even caused it but it was the only thing I could think that I changed.

Removing the card and detecting on a different port and all worked again. I never ran back to back Multiple events again until I changed this code.

Dan N wrote:

Everything is working well for me so I'm almost done modding. The biggest weakness left for >430g roasts is the cooling system. A big batch with beans that expand a lot almost fills the tray and takes a long time to cool down, still hot to the touch after 3 minutes.

Because air is pulled down the metal grate will get very hot and transfer heat to the bottom layer. Stirring brings cool beans down to be heated by the grate.

I'm going to use my old DIY cooler of a window screen over a box fan. It's big enough that there's only 1 layer of beans and the air blows up so the screen is always cool. It can cool 1lb extremely fast.

The roaster is already designed to work with an external cooler placed below it. With the cooling tray shut all the way the bean dump will come out bottom at each front corner. I've tested it with green beans and a few will bounce out the front which doesn't matter for me since they'll fall onto the big screen. I'll test it on my next roast in a couple days.

Dan N wrote:

The biggest weakness left for >430g roasts is the cooling system. A big batch with beans that expand a lot almost fills the tray and takes a long time to cool down, still hot to the touch after 3 minutes.

Because air is pulled down the metal grate will get very hot and transfer heat to the bottom layer. Stirring brings cool beans down to be heated by the grate.

renatoa wrote:



Seems @darelleman was a visionary on this subject, because I arrived to the same conclusion... roast by roast

First was just experiments, to spy the Skywalker protocol... then realized that... hey, I can used this setup for roast too !
Then, the more I used, the more I found this way suits me better than the actual mode discussed so far in this thread.
There are two main reasons I turned to this alternate way of using the roaster:
- first, we have a protocol that is not 100% well understood, and a machine the is quite sensitive to any hiccup of our attempt to emulate its language. Experienced myself, and others reported... lost commands, locks or unable to connect at all.
Keeping the factory control panel active, either Artisan or connection can crash, but we can conclude the roast without trashing the beans.
- second, is about the control ergonomics. You can call me an old fart, but industry is still on physical knobs, buttons, and other control methods that provide physical/sensorial feedback of using them with closed eyes... unlike mouses and touch screens.
I know that so far the Skywalker control panel gathered only critics, and even a total failure report (at least one), but for me it works and I like using it more than clicking on the Artisan screen.
Plus, the factory controller implements the preheat and cooling modes, that requires special attention to be done in Artisan, especially for newbies.

Lets see how is this different than before.

We start with a USB-A Extension cable, as in the link below, or attached image if the link expires.
https://www.amazo...12O5I?th=1

With a sharp cutter, we make a slot somewhere in the middle, and tap/branch the ground and data wires, using any method that suits your skills. Left the red wire intact, untouched, unused.
The three wires will be connected to any available Arduino board you have around.
Used a Nano, because the form factor allowing be to wrap it together with the cable, like a ferrite bead/choke.
The connection mode is sketched in the attached schematic.

The Arduino runs a sketch derived from original josh SkywalkerSpy code, with some slightly changes, for minimal Artisan commands processing required for data acquisition. It is attached as well.

On Artisan side there is no need for ANY setup... nothing, nada, zip !
You can start directly with factory settings straight after install, followed by the basic TC4 setup...

A typical roast session looks like:
- preheat, using roaster control panel,
- start roast on Artisan, using Start button, let stabilize some seconds to see graphics start plotting
- charge beans, double R press, try doing this as close to the Artisan charge detection, to have the timers synced as close possible
- wait TP happens on Artisan, and start power control maneuvers, using roaster control panel
- as roast progress, mark Dry End and FC start, in Artisan
- finish the roast by opening the exhaust door, then long press R, then DROP on Artisan. The later is not critical to be done as fast as possible, because you can readjust the event in Artisan using the power drop moment recorded in the graphic.
- set the cooling mode on roaster, using control panel.
- save Artisan roast session log file.

That's all folks.

@darelleman, I hope you are still reading here, and this is useful for you

Dan N wrote:

There are lots of variants of Arduino clones and getting the wrong one could cause issues. Some have genuine Atmel 328P cpu, some have a counterfeit 328P with Atmel markings, and some use a clone like LGT8F328P. Some boards run slower than 16MHz or have a different usb chip that causes issues.

You have to read the reviews carefully to be sure you'll actually get a 16MHz Atmel 328P cpu and CH340 usb chip (for Nano).

Dan N wrote:



Good catch! I tested your change by sending a Multiple Event with 4 commands several times and each time all 4 commands were received and executed correctly on the roaster. The serial log shows all 4 commands were sent back-to-back as fast as possible which would have never worked before.

renatoa wrote:

Nope, not working this way.
An executive command, like OT1 (heater value set to...) needs a full loop cycle to be performed.
The handleHeat routine only prepares the buffer contents, it doesn't actually send a message to the roaster..
The message sending is done once per loop, sendMessage(), at line 277, above/before the serial status query.