Who is here? 2 guest(s)
 Print Thread
SR800/SR540 Fan Current TC4+
dwertz
Nearing completion
dwertz attached the following image:
almost-done.jpg
 
renatoa

Quote

dwertz wrote:
...
Now that it is modified, I am not sure why I did it LOL. Is it so I can use the sliders in Artisan rather than the knob on the roaster? That is clearly not worth it. Originally the goal was to use PID control and have the computer control the heater to follow a predetermined roast profile. But I am finding the temperature display in Artisan to be really lagging behind control inputs, so I am not convinced how well PID control is going to work.


If sliders works, PID should work to, but you are right, not worth it, the current control implementation of Artisan can't cope with the task. You need a proportional on setpoint control, not on error.
Maybe with some Events playback wizardry...
 
Gullygossner

Quote

dwertz wrote:


Now that it is modified, I am not sure why I did it LOL. Is it so I can use the sliders in Artisan rather than the knob on the roaster? That is clearly not worth it. Originally the goal was to use PID control and have the computer control the heater to follow a predetermined roast profile. But I am finding the temperature display in Artisan to be really lagging behind control inputs, so I am not convinced how well PID control is going to work.


I suppose outside of PID control, having event markers for the fan/heater could be beneficial for repeatable results. Also having more granular control of the fan would be a nice thing. The fresh roast can step changes seem to be quite large. I find with large charges it would be nice to have like a half increments which would be achieved via the artisan sliders.
 
dwertz
First roast using external control.

Infinite fan speed control is great. As is not having to mess with the knob trying to select the parameter to change.

As you can see from the wobbly curve, I am not a good PID Shock I just quickly generated the red curve to try and follow. The roaster has a lot of thermal lag from the heater control inputs. I need to modify the target curve to take that into account.

Next up is to actually try and get computer control of the heat setting. I think I will always want to control the fan manually.

This has to be the most expensive SR800 in the history of the world. Let's just say I am not using an Arduino to generate the TRIAC pulses.
dwertz attached the following image:
screenshot-2023-01-01-155904.jpg

Edited by dwertz on 01/01/2023 6:23 PM
 
renatoa
Actually, the machine is faster than us, the lag is from our reactions.
A good non-PID control solution is changing the heat 1% about every 10 seconds, as an average, faster changes in the dry phase, then slowing.
And every change is immediately seen in RoR evolution, next 3 seconds after change.
An example of such roast log attached, bottom red line is the power evolution, generated by an algorithm.
If you examine the graph, you can see that most RoR raises are the result of a step in power increase.
~~~
renatoa attached the following image:
image_2023-01-02_101228230.png

Edited by renatoa on 01/02/2023 2:09 PM
 
dwertz
Interesting. So that is completely open loop? Also, constant fan setting? I feel the need to reduce the fan speed throughout the roast.

Is the heater control proportional to power? Currently my heater control linearly controls TRIAC phase angle. It would be pretty easy to map phase angle to power assuming a constant heater resistance
 
renatoa
Yes, constant fan, barely bubbling at start, kangoo jumping at the end.
Having good RoR computing in real time, I wasn't been able to change fan smooth enough to not induce huge jumps in Ror, so gave up trying to play as a DJ with two hands.

And yes, BT not influencing power evolution at all, is logged and plotted "just for the record"

Power is proportional with HTR%, using ICC, not PAC.
ICC is the TC4 term for what is known in industry as pulse skipping modulation.
So 50 Hz = 100 half sines in a second, 1% = one half sine passed, the other 99 half sines of 100 skipped.
No need for conversion tables from power% to microseconds delay angle as for PAC.
And less EMI generated due to sharp edge of high currents switching in the middle of the sine.
 
dwertz

Quote

renatoa wrote:
Power is proportional with HTR%, using ICC, not PAC.
ICC is the TC4 term for what is known in industry as pulse skipping modulation.
So 50 Hz = 100 half sines in a second, 1% = one half sine passed, the other 99 half sines of 100 skipped.
No need for conversion tables from power% to microseconds delay angle as for PAC.
And less EMI generated due to sharp edge of high currents switching in the middle of the sine.


Thanks! That makes total sense.
 
dwertz
OK got a pretty decent tracking from PID. Completely hands off the heater control. I adjusted the fan down maybe 4 times throughout the roast. Had some hiccups at the beginning but then things settled down. I accidentally started with the fan at lowest power. The sudden slope change is when I kicked it up to a speed to get decent bean movement. I let it roast a little longer than intended because I was so enamored with the heat slider bouncing around.
dwertz attached the following image:
first-good-pid-roast.jpg
 
dwertz
It took three tries. The first one I just had P and I and I had tuned it with no beans. Adding the beans meant that the integral wound up way too fast causing large overshoot. The second is with the I term turned way down, but still had significant ringing. The third try I added derivative feedback.

I am going to try a modification where the derivative effort is subtracted from the integration total rather than just being summed into the control effort. The idea being that the integral should not keep winding up if the error term is getting smaller.
dwertz attached the following image:
evolution.jpg
 
dwertz
Here is the ROR for that last roast. I wonder what causes that ripple with about 1/2 a minute period. I should monitor my line voltage to see if anything crazy is going on. Renatoa, I am noticing that your ROR has a similar look to it. I have observed similar when using Artisan even when I am not touching the heat or fan controls. I wonder if it is related to "kangoo jumping". Perhaps I will really stay on top of the fan speed for the next roast and have the fan just fast enough for good bean rotation, but no jumping.
dwertz attached the following image:
ror.jpg

Edited by dwertz on 01/03/2023 12:44 AM
 
renatoa
What are you using for computing and graph plotting ?

Ror is like a magnifier for data changes, and for total convective machine as FB the turbulence is pushed to extremes.
In the bed of coffee beans happens things like the channeling in an espresso puck, hot air gusts that find an escape way trough the beans without much resistance, thus exhausting still very hot. Such gusts, when hitting the sensor produces what we see on the graph.
That's why I prefer the asymmetric builds for FB, the air escape and beans sensor could be on opposite sides of roast chamber.
Same for power control steps, 1% control resolution is too rough for a FB, where space is too small to have room for melange and averaging as in a large oven.
1% power step led to about 3 C degrees of hot air increase, this can't pass unnoticed by a fast sensor. That's why maybe is preferable a slower sensor, having lag time of about 10 seconds, as is the average 1% power step change period.
 
dwertz
I am using the LabVIEW programming environment. The phase angle control is actually running on an FPGA with a 40MHz loop rate. so, the control resolution is much finer than 1%. The actual PID loop is running on a real time controller and the loop rate is paced by the Thermocouple module. I have been using best 60Hz rejection and the rate is 8.3333333 Hz. I can kick the loop rate up to 50Hz with the module I am using. The NI-9219.

The system is NI Compact RIO

https://www.ni.co...ctrio.html

Just slightly overkill for the taskRoflmao I work for NI and had the stuff laying around. It was WAY faster for me than trying to learn how to do it in Artisan. Once I get all the control stuff to my liking, I will port it over to a $6.00 Arduino nano.

I will look carefully at the bean mass to see if there is an area on the surface that is calm and might be a better location for the thermocouple.
Edited by renatoa on 01/03/2023 4:00 AM
 
renatoa
With PAC the main problem is not about resolution, but precision and time stability.
The effective power delivered into load is hugely affected by the repeatability and precision of zero cross detection (ZCD).
Spread of ZC in a 100 microseconds window means nothing for ICC, under 0.1% of power, because happens at sine start, where power is very small... but a jitter of 100 microseconds, when propagated at sine peak, in the 50% ballpark, means 1% of power !
And ZC with 100 microseconds accuracy is extremely hard to get, trust me, in big industry it's an achievement.
On my residential mains measured up to eight false ZC in 400 microseconds window ...
When using PAC for a fan, I am capable to hear tone variations when spinning freely, no load, due to this ZC detection issue.
I am pretty sure they are due to ZC, because same fan, using an universal motor, when powered from DC, has a very stable tone pitch.

Not sure what averaging are you using for the graph, I suggest try Savitsky Golay filtering, that does both derivative and filtering in same step.
In my setup I am using 9 values (seconds) window size, the linear model, for simpler computations, there is no need to use cubic or quartic for so small variation in such narrow window.
https://en.wikipe...efficients
 
dwertz
OK you piqued my interest. My FPGA is actually timing the rising and falling edges of the zero crossing circuit and using the center as the reference for the PAC. I exported the pulse width for every zero crossing for a 10-minute run. I also exported the zero crossing to zero crossing interval for every zero crossing. included is the raw and smoothed data.

The RobotDyn dimmer actually has an interesting property. The higher the voltage of the mains voltage, the narrower the zero-crossing pulse. In Theory we can use the zero-crossing pulse width to adjust the phase angle to compensate for mains voltage variation. The smoothed pulse width is suspiciously similar looking to the ROR curve and I am wondering if doing the voltage compensation will smooth things out.

The zero-crossing time interval plot is an indication of the frequency stability of the mains. Short term, I am not seeing more than 10 usec variation. And to be fair if one pulse comes in a little early others will come in late. It is not fair to judge power output on one pulse. Really you need to look at the average over the similar interval you would use for your ICC frame.

I was thinking about what you said about the thermocouple and the turbulent air flow allowing blasts of hot air not cooled by the beans. What do you think of using multiple thermocouples and using the minimum temperature from any thermocouple as the process variable? The thought is that the coolest one will have had the least amount of bypass air and will have better contact with the bean mass.
dwertz attached the following image:
screenshot-2023-01-03-225313.jpg

Edited by dwertz on 01/04/2023 1:23 AM
 
dwertz
I tried out the Savitsky Golay filter and strangely I get the exact same results as moving average when the order is set to 1. Higher orders are different, but I am finding for my data set the 1st order smoothed the best.
dwertz attached the following image:
screenshot-2023-01-03-225307.jpg
 
renatoa
Yes, depending on the moving average window, you can obtain similar looking results, but SG is faster and preserve the peak shape property better than any other method.
So I read in manuals Grin but can be seen easily if plotting both on same graph. Or generate numbers series in excel in two columns side by side for all methods.
In real world, the effect is that for a 9 seconds SG window a spike will be noticed 4-5 seconds faster than using the same weight moving average.

To relate these numbers to actual equipment that many people is using, I mean the TC4, when they set 75-80-85 filter ratio(s), the readings are delayed by 4-5-6 seconds respectively versus the acquired values.
And this filtering is applied twice ! for BT displayed values, and then again for computed RoR.
A 9 seconds SG filters better even than 85% rolling avg, and introduces a delay of only 3 seconds, just one, no multiple passes filter.
Edited by renatoa on 01/04/2023 6:27 AM
 
renatoa

Quote

dwertz wrote:

I was thinking about what you said about the thermocouple and the turbulent air flow allowing blasts of hot air not cooled by the beans. What do you think of using multiple thermocouples and using the minimum temperature from any thermocouple as the process variable? The thought is that the coolest one will have had the least amount of bypass air and will have better contact with the bean mass.


I would rather average them, or graph the average vs the coolest, and see which is more reliable.
Averaging has the advantage you don't need more TC and more channels/acquisitions, and software changes for picking the coolest.
You can simply use a longer section of TC wires, about the perimeter of the roast chamber length, and twist them in other 4 places, starting from the tip junction, at distances roughly equivalent to 1/4 of perimeter, thus 90 degrees each.
Will create so another 4 additional junctions, that will generate each their own temperatures/voltages, and the result will be an averaging of them.

Regarding the plotted values... I have first to understand what is there, then digest, so replying later Grin
 
dwertz
I did an experiment today. I set the fan at 50% and the heater at 50% and logged Temperature, ROR and zero crossing pulse width. The experiment was designed to look at any correlation between the pulse width and the temperature / ROR.

The data is plotted with the temperature offset to get it on the same display as the ROR and the pulse width was plotted as deviation from the mean pulse width. Actually, the negative of the deviation since in theory narrower pulses correlate to higher line voltage.

As hoped for there is correlation between the pulse width and the temperature / ROR. So, it should be possible to modulate the TRIAC phase angle as a function of zero crossing pulse width to stabilize both fan speed and heater power.

Is this going to make any sort of difference to the coffee? I am not holding my breath. I have had some pretty nasty looking roast curves that resulted in fine tasting coffee. But it may make for prettier looking roast curves and bragging rightsRoflmao
dwertz attached the following image:
pulse-width-ror-exp.jpg

Edited by dwertz on 01/04/2023 4:31 PM
 
Gullygossner

Quote

dwertz wrote:
The NI-9219.

The system is NI Compact RIO


When I saw your labview screenshots I knew you meant business Grin
 
dwertz

Quote

Gullygossner wrote:
When I saw your labview screenshots I knew you meant business Grin


LOL I Definitely pulled out the big guns! The trick will be porting it to an Arduino and Artisan. Not sure when though. I am actually really digging just controlling the fan and watching the heat control bouncing around like crazy and nice smooth curves appearing.

Our power was out for a week due to some storms, but I did just add line voltage compensation based on the zero-crossing pulse width. Used to be you would hear the fan slow down some when you click the heater on and speed up when turning it off. No more, it is rock solid now. I will work on the PID tuning next. I am still using the gains from day one, but it is working well enough.

Included a picture of the latest roast. I think it is time to start experimenting with roast profiles next, but I have found I am really liking the coffee I am getting from this curve and just adjusting the development time / final temperature.
dwertz attached the following image:
screenshot_2023-01-16_230910.jpg
 
renatoa
You should lower the rate on the final approach, the curve above shows a constant steady rise.
I would try an asymptotic to about 450F.

Also, please, can you add RoR plot to your graphs, some old brains as me are judging more the variations than absolute values.
 
dwertz

Quote

renatoa wrote:

You should lower the rate on the final approach, the curve above shows a constant steady rise.
I would try an asymptotic to about 450F.

Also, please, can you add RoR plot to your graphs, some old brains as me are judging more the variations than absolute values.


I have a ROR plot in post 66. But I will add ROR to the main graph. The existing curve uses a 1/x for ROR.

What is a good ROR target through first crack?
 
dwertz
Along these lines?

I switched to a spline for easy local changes. This isn't really much different since I stopped the roast around minute 11. Are you suggesting I reduce the ROR even faster?
dwertz attached the following image:
newprofile.jpg

Edited by dwertz on 01/17/2023 4:07 PM
 
renatoa
Check here in other thread just posted some thought on my development phase driving strategies:
https://homeroast...post_76300

This RoR looks pretty unreal in my eyes, how smooth it is and no showing any perceivable signs of flip and crash... on my data sets I can put a finger on the FC moment debut with an error of 15 seconds, without hearing any sound.
Not sure if this is a real time plot, or after the roast.
If real time, for me would be a nightmare to follow the roast evolution. After dry ending I use every RoR bump as a sign I need to reduce power, in order to prepare the FC entrance with the right value.

May I suggest you to put your data in a csv file in Artisan format, and do the plots with Artisan, to have an image familiar to most of us ?

Not a critique, but in such cases excessive filtering is not helping at all.
 
Jump to Forum: