Who is here? 1 guest(s)
 Print Thread
Glitch When Using Artisan Alarms
I've been trying to resolve a problem with automated roasting via an Artisan alarm file. As seen in the image of alarms and events, first the roaster preheats, then the heat is shut off, then the fan is shut off. Then the roast chamber is charged with green beans and the mixer on IO3 is started at the same time.

The problem is, that when the fan command is sent again to start roasting the mixer shuts off by itself.

The mixer is IO3 fast PWM
The fan is OT2 slow PWM
The heat is OT1 slow PWM

The glitch only happens when the fan on OT2 restarts... it shuts off IO3 automatically for some reason. To resolve this nuisance, I electronically reset and restart the mixer with new alarms and events after the fan was restarted. It would be nicer to have continuous agitation without those few seconds of the mixer not working.

Does anyone know what could cause this fault or possibly how to fix it?
CK attached the following image:
Actually, this is a TC4 issue, not Artisan. A cross post linking here could be added in the TC4 technical thread.

From the details shared above I guess you are using CONFIG_PWM mode.

In PWM config the scenario is that the fan is a DC type, and controlled via fast PWM by a DC MOSFET driver from IO3 output.
Because DC motors draw a lot of current when there is a change of speed, a slew fan logic has been introduced, that decimate a big speed change/jump, in smaller steps of 5% speed change per second (default value)
The call to this function is here: https://github.co...D.ino#L395
So when you command a fan speed change from say 25 to 75%, using TC4 DCFAN command, the speed change will last 10 seconds, as a 25 30 ... 70 75% sequence of small changes.

As you can see from the code, that call happens if no PAC mode is selected, as is your PWM case.

If we go further and investigate what happens inside that slew fan function, we find that all roads goes to set_fan() function, here: https://github.co...r.cpp#L427
... where IO3 is commanded as the fan output, even if your intended command was for OT2 for fan speed change.

The first solution that comes in my mind fast, without recompiling and reloading sketch, is to use separate commands in Artisan for OT2 and IO3 control, and avoid DCFAN command which is tricky in your context.
Also, DCFAN is the only way to activate the slew fan logic, which is not activated by outOT2, nor outIO3 commands.

An alternative, without change the Artisan setup, is to comment the slew fan call in the code above, and reload sketch.

Digressing, very confused how/what fan can be controlled via slow PWM... but not related to your issue.
Edited by renatoa on 05/05/2022 9:53 AM


renatoa wrote:
From the details shared above I guess you are using CONFIG_PWM mode.

Thank you for the great reply RenatoGrin. You are correct, I'm using CONFIG_PWM. The information you provided will keep me busy for a while trying to figure things out...


renatoa wrote:
Digressing, very confused how/what fan can be controlled via slow PWM... but not related to your issue.

The fan is always used at 100%, so the signal that turns the fan on via Artisan is a 100% PWM signal sent to a DD SSR that acts as a switch for the fan's DC power. In manual mode (stand-alone) I can turn the fan on or off with a toggle switch that bypasses the TC4 and DD SSR setup.
For the newcomers in the electronics of control circuitry, CK is using the SSR in an unusual way, in DC, instead AC, as is their natural intended usage by design.
This is unusual because when used in DC, when a SSR is commanded to switch in an ON state, it never reverts back to OFF, until the power of that circuit is cycled.
When used in AC this happens 100/120 times per seconds, at every zero cross of the voltage, as is the nature of AC.
However, someone could claim that even in DC a SSR could be used to shut off a circuit, in the particular case when the load is a brushed motor. That's why every moment when we see a spark inside a brushed motor this means the circuit was been broken by a short imperfect contact between the brushes and the rotating commutator plates, enough for the SSR to reset its status to OFF.
The next PWM pulse coming from TC4 will turn the SSR back to conduction state.
I'm using 2 of these DD SSRs; https://www.amazo...p&th=1

One DD SSR is triggered by OT2 slow PWM at 100% to activate two Dyson V6 fans (extremely powerful and no carbon brush dust), and the other DD SSR is triggered by io3 fast PWM (via Artisan or manually via potentiometer) to activate my stepper motor setup (frequency generator https://www.amazo...&psc=1, driver https://www.amazo...&psc=1 and stepper motor https://www.amazo...&psc=1). Grin

Everything works fine with the exception of the glitch mentioned in post #1. It's awesome being able to use stepper motors with the TC4 setup... lots of torque (without gears, chains, belts) with very quiet operation.
Learning something new every day...
After a bit more troubleshooting this problem has been resolved.

It turns out that when the powerful brushless fans are activated, they hog a lot of current from the 24v power supply, and this affected the frequency controller and the stepper motor driver that shared the same power supply as the fans... perhaps a power fluctuation outside their operating limits that they couldn't recover from.

After adding a separate power supply for the frequency controller and the stepper motor driver, everything works perfectly without any glitches. This case is now closed. Grin
A slow start would have been useful here ... feasible software.
Jump to Forum: