Who is here? 1 guest(s)
 Print Thread
TC4 with aArtisanQ_PID
Thank you so much, you are such a great help & respectful person. I wish I can return back the favor. Have you tried green coffee beans soaked in aged rum? I can share with you my receipies if you are interested.

Thanks once more!

I've released version 5_0 of aArtisanQ_PID. There's not many changes. Most were keeping it up to date with my TC4 Android App.

This version currently supports most features in Artisan, Roastlogger, and my Android App.

Download from the TC4 Repository here.
Thank you!
I am not really sure if I load a roasting profile in the background, shouldn't the fan and heater start or I have to start it manual using the sliders or the preset buttons to have the fan at 100% & the heater at 50% or 70%? shouldn't the profile take care of this?! And if I change the heater to 75%, wouldn't that change the roasting profile? Or I am doing something wrong?

The automatic following of roast profiles loaded into the background of Artisan is not currently supported in my code (yet). So at this stage Artisan will not be able to automatically change your heater. You have to do it manually with the slider.

I hope to add support for Artisan automatically controlling the heater soon.
So from my understanding that means, I am using only the Artisan software to control the heater and the fan without even being able to use the roasting profiles that I save? Is that right? Or I have a misunderstanding? Thanks.
I believe that is correct. Although I do notice there is a PID section in the Arduino Control section of Artisan. Maybe Marko or Jim could comment?

I am currently testing an update to aArtisanQ_PID that supports the 'Set Value' feature in Artisan. I can maybe upload it tomorrow for you to try if you wanted to test it.
Attached is a version with the SV function for testing.

I noticed that the option in Artisan to 'Start PID on CHARGE' only seems to work the first time charge is clicked. The PID won't auto start on subsequent roasts, not sure why. But it can be manually started in the Arduino control window.
greencardigan attached the following file:
aartisanq_pid_5_1_for_testing.zip [25.29kB / 719 Downloads]
I am wondering is there a way that I can modify the circuit to work with the aArtisan.ino the original file, so I can have fully function ability?

I have made further updates to aArtisanQ_PID. It now should have the same functionality as aArtisan when used with Artisan.

It should support automated heater control using ramp/soak profiles or background profiles from Artisan.

It also retains support for my Android app as well as Roastlogger.

greencardigan attached the following file:
aartisanq_pid_5_2.zip [90.06kB / 749 Downloads]
Brad, now that your code supports all three platforms fully. Shouldn't this flow back to Jim and serve as the one-for-all TC4 firmware trunk for further development. I guess a lot of confusion between the aArtisan, RoastLogger and Android app firmwares could be avoided.

I'll try to ensure that in the next Artisan version one will be able to access channels 5678 without having to configure 34. I think there was some historic reason things ended up like this.
Let me add a thank you to all the work you people do for all this software/hardware.

ThumbsUp ThumbsUp ThumbsUp ThumbsUp ThumbsUp

Ken in NC
Backwoods Roaster
"I wish I could taste as well as I wish I could roast."

As Abraham Lincoln said "Do not trust everything you read on the internet".
Hi Marko, yes I think it would be ideal to combine my phase control/zero-cross version with the base aArtisan version. However It might be beyond my coding skills. Also I need to focus on improving my android app.
Thanks to everyone who contributed their time & effort!
Latest version 5_3 attached
greencardigan attached the following file:
aartisanq_pid_5_3.zip [27.58kB / 759 Downloads]
Thank you for great software!

Just to check, when using aArtisanQ_PID it is not possible to use DC motor along with SSR controlled heater (using ICC)?

If I wanted to use it on OT2, would changing in function output_level_pac when pac_output is set to call analog_write( OT_PAC, 2.55 * pac_output) and commenting out digitalWrites to OT_PAC be enough?

Controlling a DC fan is not possible with aArtisanQ_PID with modification.

I'm not real sure which bits of the code you would need to change. You could have a look at the standard aArtisan code to see how it does PWM output on IO3.


If you work it out post back here, as we do want to combine the features of aArtisan and aArtisanQ_PID sometime.
Ok. When all the parts arrive, I will try to make it work if it does will post it here.
I have a question on controlling the DC Fan that is said not possible to control?

Why can't you just use something like the Crydom D1D relay and control the DC motor with the PWM output from the control board straight to the relay control side for the speed control?

I don't have a need or the relay to try it with or I would, but I'm not seeing why it wouldn't work. PWM is used all the time for DC motor speed control. Not sure but might have to do some kind of filtering so prevent reverse EMF from causing a problem during cycles but seems to me it would work.
After reading source code and following document http://www.crydom...0types.pdf I would say main reason is because after powering relay timer is set to TRIAC_PULSE_WIDTH to ensure relay starts and then closes so it doesn't activate next cycle (after zero cross since relay will automatically stop on zero cross), this is best illustrated on image on following page: http://playground...aseControl. Because of that DC relay would in most cases (whenever reminder of phase delay is greater than triac pulse width) stop before it is needed.

If I'm not mistaken in order to use DC SSR it would be required not to set timer after output is enabled (lines 144-151 of phase_ctrl.cpp), and just wait for for next ZCD interrupt to automatically stop it.

However with that modification it would work with MOSFET as well (which is many times cheaper than DC SSR).

I'm not sure whether in that case there is point in using custom interrupt routine (ISR(TIMER1_COMPA_vect)) and timer to achieve it. Since it could be also achieved just by using analogWrite and that solution would not require ZCD (although anyone using ICC to control heater would already have ZCD). On the other hand it could be more precise since it wouldn't be interfered by millis() and delay() functions (as mentioned here https://www.ardui...nalogWrite) but without further research I'm not completely sure.

Probably the easiest solution (when already using ZCD for heater) would be to add #define DC_MOTOR that would remove code that would cause problems (I will probably try this one). The solution that would work even without ZCD would be to use analogWrite outside of functions that require ZCD (ie. output_level_pac). And probably the best solution if this branch is planed to be joined with original would be to combine them and have the both solutions each for given case depending on #defines.
Ok, short answer is, it's a lot easier said than done. Answered my question anyway.

Maybe I can send him one these 250 amp mosfet controllers I have for a forklift drive motor and can adapt that to work

Im starting to use my new TC4 + arduino with the aArtisanQ_PID sketch but Im getting erratic random temperature readings (serial monitor) everytime I plug the TC4 to the computer with the USB.

All temperature readings in standalone mode are good and stable.

Arstisan don't recognize the TC4.

Troubleshooting performed:

- Loaded different version of the skecth.
- Different baud rates.
- 2 different USB cables.

Any clue?

Additional Troubleshooting:

1) If un unplug all thermocouples from the TC4 all the readings are good and stables (close to the ambient board temperature).

2) If I power the TC4 using the 9 V adaptor the temperature reading are OK.
I found the cause of the erratic readings: My laptop. Rgds.

If I run my laptop on batteries. All the temps are stable.

How can I mitigate this effect?
If you are using metal sheathed probes and they are in contact with the roaster frame, you can get ground loops and noise. The TC4 inputs are very sensitive to this. The fact that it goes away with a laptop on battery confirms it.

You can add a ground wire from one of the the TC4's ground terminals to a good ground source (ground connection to an AC receptacle).

Another way is to try and electrically isolate the probe cases from the roaster chassis.

KKTO Roaster.
Jump to Forum: