topbanner.gif
Login
Username

Password




Not a member yet?
Click here to register.

Forgotten your password?
Request a new one here.
Shoutbox
You must login to post a message.

snwcmpr
12/07/2019 9:29 AM
roar

snwcmpr
11/27/2019 11:44 AM
greenman

allenb
11/27/2019 11:04 AM
Nice! I know Netrix is going through things and tweaking as he see's issues

snwcmpr
11/26/2019 1:35 PM
I got an email that I had a PM. So, that is working for me again. greenman

snwcmpr
11/26/2019 1:33 PM
Howdy Howdy!!

Users Online
Guests Online: 3

Members Online: 0

Total Members: 6,285
Newest Member: thirdguess
In Memory Of Ginny
Donations

Latest Donations
Jared Brunette - 5.00
Daniel Boozer - 5.00
renatoa - 2.00
JitterzZ - 2.01
renatoa - 2.00

View Thread

Who is here? 1 guest(s)
 Print Thread
TC4 with aArtisanQ_PID
Wiz Kalita
This is true, and my curves look like your first one. I'll switch to controlling on ET from now on. But what I meant was that OT1 and ET follow each other close enough that I think controlling on OT1 directly without any PID could be a good idea.
 
greencardigan
Hi all,

The was an error in version 6_6 that stopped the sketch from compiling in one of the modes. This release fixes that issue.

Github download link - aArtisanQ_PID version 6_7

I've also updated some guide documents relating to the aArtisanQ_PID sketch which may help new users get going. However, the guides assume you already know how to program an Arduino.
greencardigan attached the following file:
setup_guides.zip [473.3kB / 146 Downloads]
 
renatoa
Two questions for anyone that has a deep understanding of TC source:

- why there is no data stream output, for any protocol, if standalone mode is chosen ?
Somewhat related, why no buttons/profile available if using an external roasting app?
In both cases the reasoning is same as above, maybe I want to roast with internal TC4 profile/PID and send data to Artisan... seems not possible with actual code.

- the second is about power control when using ICC... at some moment in time inside the ISR routine, at line 151, the Bresenham's algorithm decide to raise OT_ICC pin to HIGH. I don't see where in the code/moment in time, where the OT_ICC pin is reset to zero before the start of the next half sine, which is mandatory, imo, else the ZCD will never trigger one more time the ISR. And the heater will remain full power on forever. At least so happens to me...

btw, in my twisted mind, ISS should logically reside in same module as slow PWM control. Using a ZCD doesn't not make this method belonging to the phase angle principle, is still an on-off method, very fast and synced with frequency, but on-off.
Why would be this preferable... because there could be cases of ZCD malfunction, experienced them, where merging ICC with PWM in the same code would allow instant switching from ICC to slow PWM if ZCD fails/timeout. And save the roast... Grin
 
greencardigan
I don't have a full understanding of how the ICC code works but I will have a look at when I get a chance.

I believe that I didn't see any need at the time to include any output stream in standalone mode. It was intended for use when logging software was not being used. Maybe the TC4 profiling and buttons could be activated when in other modes? Actually it appears that the profile code is active in all modes. As you know there were low memory issues at one time and the button checking code was disabled in other modes to try and reduce memory usage. It is quite possible that it could be added back in as there was also some other memory savings.

Regarding the ICC and PWM being separate , this was a result of my merging of Jim's two branches. He had a PWM and phase angle control branches each with their own libraries and I simply merged them and include the appropriate library as required.
 
mg512
I had some free time this weekend and did a little experimenting with PID control, since this has been discussed again a few times recently. I noticed that PID behaves very differently in the sketch I have been using (based on an old aArtisan v3.10) compared to the latest aArtisanQ_PID.

In particular, my PID tuning parameters worked decently well on the old aArtisan sketch. But on aArtisanQ_PID, they gave serious oscillations, and heater output jumped only between 0 and 100%. Interestingly, this depended a lot on the tuning parameters used:

* Without a D-term, there was no appreciable difference.
* With a large D-term, aArtisan was fine, but aArtisanQ_PID oscillates.

After a lot of digging I think I found the issue: In aArtisanQ_PID the PID calculations are only done once per iteration of the main loop. Given the ADC delays, that's about once every 1.25 seconds. In the old aArtisan, the PID was also updated during the delay loop waiting for the ADC. I think this is especially bad for the D-term, since the error can change quite a lot in 1.25 seconds.

In any case, updating the PID during the delay loop seems to fix the issue for me, and PID control is now stable even with a large (32) D-term.

greencardigan, I have sent you a draft pull request on github - perhaps you can have a look. If anyone wants to give it a test in the mean time, the code is available here:

https://github.co...tisanQ_PID
 
https://www.tindie.com/products/15798/
greencardigan
I haven't had a chance to look at your pull request yet, but a few comments.

If I remember correctly, the ADC reads etc should take less than 1 second when using two channels. The loop and PID update should then run every 1000ms. If the loop will take longer tha 1 second then it should run every 2000ms.

The PID library should only compute after the period set by
Download source  Code
void PID::SetSampleTime(int NewSampleTime)


which is 1000 ms and set in user.h. Not sure why trying to compute more often would do anything.
 
renatoa
The 18 bit ADC sample is minimum 270 ms, 300ms for safety, so 540-600ms for two channels minimum loop time.
If someone want faster loop time, maybe an interlacing of ADC readings could help, I mean reading a single ADC every cycle.
Not sure someone would need this, because the actual TC4 resolution (0.3 C degree) is lower than the temperature variation in one second - 0.16 C degree per second, for 10 C RoR.

If we are here, additional to the remark I sent last evening, about power at start, we should also think to a method to sync the ADC reading and loop time, with the Artisan READ commands, to avoid a lot of RoR issues that looks like temperature oscillations, but actually is a beating phenomenon, between the two loop frequencies, Artisan and TC4.

Not the last, why someone would need a D-term in a so slow roasting process?
What are the fast temperature changes that we want to calm down with a D-term ?
If such changes are reported by the measurement chain, then what is measured is too much (turbulent) air, not beans, I would try to address this instead.
 
mg512
I think PID::Compute() should be called as often as possible. It will decide itself when to update and when not to. From the PID library, in pid_v1.cpp:
Download source  Code

/* Compute() **********************************************************************
 *     This, as they say, is where the magic happens.  this function should be called
 *   every time "void loop()" executes.  the function will decide for itself whether a new
 *   pid Output needs to be computed.  returns true when the output is computed,
 *   false when nothing has been done.
 **********************************************************************************/
bool PID::Compute()




If you call it less often, you essentially force the cycle time to be longer. With 4 channels, the ADC will take 1200ms.

But even with 2 seconds and 600ms, the PID cycle time will be 1200ms even if it is set to 1000ms, since PID::Compute() would only be called at 600ms and 1200ms.
edit: Nevermind, this is incorrect. I missed that the main loop waits until 1000ms. This is even worse though. See my next post.

Generally, you should call PID::Compute() much more frequently than the cycle time you want, unless you time it very precisely so that the Compute() calls happen exactly at or just after after the PID cycles. Otherwise, you get a different cycle time than intended, or even worse, irregular PID updates. This could mess up the output, since the PID code assumes regular updates and I- and D-parameters depend on cycle length I think.

On a side note, we could do away with the ADC delay loop altogether, if we do something similar in get_samples() as the PID::Compute() function does: Only execute if enough time has passed, otherwise return immediately. That makes the code a little simpler. I gave this a quick try, and can upload to github if you're interested.

Not the last, why someone would need a D-term in a so slow roasting process?

You could still have fast changes in set point, for instance. And besides, even if it's not needed, the code shouldn't misbehave if it's used. Fair point about measurement noise though, that's also something to keep in mind.
Edited by mg512 on 04/07/2019 10:25 PM
 
https://www.tindie.com/products/15798/
renatoa
Nope, check what the code is actually doing, not what the comments are claiming to do... doesn't work as you think.

The Compute is performed exactly at cycle time multiples, whatever it is, not related to ADC at all.

Download source  Code
   unsigned long timeChange = (now - lastTime);
   if(timeChange>=SampleTime)
...
   }
   else return false;




If cycle time is 1000 ms, and we have two ADC channels active, thus 600 ms will be spent with acquisition, and 400 ms available for other tasks, the PID.Compute is called very one second.

If you change the code to call three times Compute in a second, then two calls will be no effect, just enter and exit function immediately, not performing any computations.

Once again, the weak point of the whole thing in this moment is the resolution, not the sample time.
With the actual resolution of 0.3 C degrees, you can sample the temperature as low as 3 seconds rate, for an average RoR of 10 C degrees per minute.
That's because a good digital image of a process requirement is the samples be taken at least at the 2x the rate the changes happens, is called Nyquist theorem.

Another factor to think about if anyone want to redesign the PID... power must change much slower than the actual PID output drive the heater.
A pro roaster will never change power level so chaotic as we see in the PID output graphs, a good roast can be driven with 4-5 power change for the whole cycle, and nothing else.
For this reason I changed the way how the output is driven in my PID code, switching to an incremental approach, instead output absolute values.
The Compute function decide only the direction to follow, and the change is only 1 unit per cycle, see code below.

Download source  Code
     //*myOutput = output;
     if (*myOutput < outMin)
        *myOutput = outMin;
     else {
        if (*myOutput < output) *myOutput += 1;
        if (*myOutput > output) *myOutput -= 1;
     }




... instead of former direct value output, the first line in code above, which is commented now.
 
renatoa
More clarification how the time is spent into the main loop:

0 ms loop start
... 2-3 ms stuff without much impact

checkSerial(); // Has a command been received?
... the above can take a while... in the tenths of ms ballpark, but less than 100

get_samples(); // Read temperatures
... here we have the main time consumption, + 600 ms

// Read analogue POT values if defined
// Run PID if defined and active

... the above are actual power control... some tenths of ms

// Update LCD if defined
... again some some tenths of ms

// Send data to Roastlogger if defined

In this moment, based on my measurements, we are somewhere at the 800 ms ballparks, the rest to 1000 ms is spent in a look checking for serial input and buttons for command

// wait until looptiom is expired. Check serial and buttons while waiting
while( millis() < next_loop_time ) {
checkSerial(); // Has a command been received?
...
checkButtonPins();
#endif
#endif
}

// Set next loop time and increment counter
next_loop_time = next_loop_time + looptime; // add time until next loop
counter = counter + ( looptime / 1000 ); if( counter > 3599 ) counter = 3599;
}
 
mg512
Ah, right, I missed that the main loop always waits until 1000ms have elapsed. But this is actually even worse. In fact calling PID::Compute() at intervals roughly the same as the configured cycle length is the worst case scenario! Consider what happens if there is even a 1ms variance between loop executions:
* If the main loop takes 1001ms, you have 1001ms between two calls to PID::Compute(). That means PID::Compute() does its calculations.
* If on the other hand you have 999ms between two calls, PID::Compute() does nothing in this iteration. So then you have a roughly 2000ms interval between PID updates. This then messes up the I- and D-terms for that update.

This is what I meant by "irregular updates" in my previous post.

I just tried this to be sure. Add a couple of serial outputs to PID_v1.cpp in PID::Compute(): One every time the function is called, and one only if the update is actually performed. With timing information, e.g. like this:

Download source  Code

   Serial.print("PID::Compute() called at ");
   Serial.print(timeChange); 
   Serial.println(" ms after previous PID update.");
   if(timeChange>=SampleTime)
   {
      Serial.print("PID update cycle time ");
      Serial.println(timeChange); 





And check the serial output after you turn on the PID:

Download source  Code

PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000
PID::Compute() called at 1001 ms after previous PID update.
PID update cycle time 1001
PID::Compute() called at 999 ms after previous PID update.
PID::Compute() called at 2000 ms after previous PID update.
PID update cycle time 2000
PID::Compute() called at 999 ms after previous PID update.
PID::Compute() called at 1999 ms after previous PID update.
PID update cycle time 1999
PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000
PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000
PID::Compute() called at 1001 ms after previous PID update.
PID update cycle time 1001
PID::Compute() called at 999 ms after previous PID update.
PID::Compute() called at 1999 ms after previous PID update.
PID update cycle time 1999
PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000
PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000




Edited by mg512 on 04/07/2019 10:34 PM
 
https://www.tindie.com/products/15798/
renatoa
I can't figure how the 999-1001 situation could happen, when we have about 200 ms to burn doing nothing in a cycle... enough margin to never have the 2000 ms scenario.
Also, the 999 ms scenario is impossible because PID is always called at loop start, you can't have timeChange smaller than SampleTime, unless the clock of your board is ticking in twilight zone... Shock

But... the most important... almost nothing is messed !
Even for the 2000 ms scenario, the I-term will add double error in double time, so what's the drama ?
D-term could be affected indeed, because Brett suppose a constant run interval, because he want to save a division operation in the D-term computation.
Check here his reasoning http://brettbeaur...mple-time/
Can be easily fixed reinstating the right, complete, formula for D-term, but I don't see in real world the need for this. First because on my machine the PID is called quartz stable at 1000 ms, never recorded a glitch, and second... oh, yeah, my D-term is zero always Grin

As I already wrote... the lack of sync with Artisan READ is infinitely bigger issue, Artisan never knows what is the age of the results received as a reply to a READ. Could be 1 ms old, could be 999 ms... unknown, and variable in time, because different loop timings.
Already discussed this issue with Makomo, and he can't do nothing, the ball is in TC field, if the loops have to be synced, then only in TC4 can be done.
Actually, is quite simple... make the get samples call async, triggered from two places, either from the loop if no Artisan usage, either by the READ command, and in this second case in the main loop either use conversion values, either wait for conversion to finish.
 
mg512
Of course you can have timeChange smaller than SampleTime. That's precisely what is supposed to happen if you call PID::Compute() frequently. PID::Compute() then checks if timeChange is at least SampleTime, and only if that's the case it will actually perform the PID calculations. That is the if-statement in the pasted code above by the way, where I added the debug serial output - that's already in the PID::Compute function. See below for the full code, if it doesn't make sense.

To be clear, the serial output I pasted above is directly from aArtisanQ_PID recompiled with the added serial output in the PID library. If you don't believe the 2000ms-interval can happen, please do verify this yourself.

The I-term will add half as much if you skip an update. But the D-term will count twice as much. Hence this adds lots of instability with a large D-term; it will still mess things up with only an I-term though.



Download source  Code

/* Compute() **********************************************************************
 *     This, as they say, is where the magic happens.  this function should be called
 *   every time "void loop()" executes.  the function will decide for itself whether a new
 *   pid Output needs to be computed.  returns true when the output is computed,
 *   false when nothing has been done.
 **********************************************************************************/
bool PID::Compute()
{
   if(!inAuto) return false;
   unsigned long now = millis();
   unsigned long timeChange = (now - lastTime);
   // DEBUG: Write to Serial every time the function is called:
   Serial.print("PID::Compute() called at ");
   Serial.print(timeChange); 
   Serial.println(" ms after previous PID update.");
   if(timeChange>=SampleTime)
   {
      // DEBUG: Write to Serial every time an update is actually performed:
      Serial.print("PID update cycle time ");
      Serial.println(timeChange); 
      /*Compute all the working error variables*/
      double input = *myInput;
      double error = *mySetpoint - input;
      double dInput = (input - lastInput);
      outputSum+= (ki * error);

      /*Add Proportional on Measurement, if P_ON_M is specified*/
      if(!pOnE) outputSum-= kp * dInput;

      if(outputSum > outMax) outputSum= outMax;
      else if(outputSum < outMin) outputSum= outMin;

      /*Add Proportional on Error, if P_ON_E is specified*/
      double output;
      if(pOnE) output = kp * error;
      else output = 0;

      /*Compute Rest of PID Output*/
      output += outputSum - kd * dInput;

       if(output > outMax) output = outMax;
      else if(output < outMin) output = outMin;
       *myOutput = output;

      /*Remember some variables for next time*/
      lastInput = input;
      lastTime = now;
       return true;
   }
   else return false;
}



 
https://www.tindie.com/products/15798/
renatoa
PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000
PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000
PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000
PID::Compute() called at 1000 ms after previous PID update.
PID update cycle time 1000


Sorry, can't debug this... Grin
 
mg512
renatoa wrote:
Sorry, can't debug this...


Huh, that is odd. I just verified again on my end. I assume you left it running for more than those 4 seconds? Are you on the latest aArtisanQ_PID from git, and latest Arduino version? You wrote earlier that the PID gets called at the loop start - that is not the case in the latest git version, there the PID code is in the middle of the loop: line 1526 onwards on https://github.co....ino#L1526

Anyway, we are also getting a bit sidetracked here. There is no harm in calling PID::Compute() more often. And even if calling it only once per main loop wasn't an issue with the default settings, it would still be a problem with cycle times <1000ms or 4 active channels.
 
https://www.tindie.com/products/15798/
renatoa
Yes, same code, was wrong about the loop start, I meant after getsamples, which for me is the logical loop start, where everything begins.

Cycle time should be changed according to DAC usage, this is obvious.
With 4 channels it should be increased to 1500 at least.
Or use my 60 ms improved architecture from TC4ESP fork, can be used for Arduino too. Is what I advise any existing TC4 user.
Sorry if I forgot to mention, the acquisition time is 120 ms in the rock stable loop above ...
 
ROSTARN
Hi guys
My setup is resitive heater on OT1, ac fan on OT2 and DC motor on IO3, using PAC2 mode.

Ive been experimenting with the pwm frequency on IO3 by changing the prescaler on line pwmio3.Setup( IO3_PCORPWM, IO3_PRESCALE_8 )
It works nicely to change it but I get some strange results.

It seems like when I lower the frequency under 500 Hz, the speed of the DC motor maxes out at 30% duty cycle. AC fan is behaving as expected.

When I put on 30kHz The motors speed correlates to the duty cycle but then the AC fan needs a 50% duty cycle to even start moving.

And this happen when AC and DC fan (OT2 and IO3) are running at the same time.

Haven't looked at the heaters behavior yet.

It seems like a prescale at 3.9kHz is the happy medium but I get this high pitch coil whine from the motor that I wish to remove:)

Is this behavior known or can be explained?
 
Jump to Forum:

Similar Threads

Thread Forum Replies Last Post
Loading aArtisanQ_PID in Arduino Dataloggers/Controllers/Rate of Rise Meters 14 05/28/2018 2:32 PM
Help with aArtisanQ_PID Specifying Temps Dataloggers/Controllers/Rate of Rise Meters 7 08/03/2017 1:05 PM
TC4 aArtisanQ_PID or Standard Library Dataloggers/Controllers/Rate of Rise Meters 45 01/24/2016 6:17 AM
aArtisanQ_PID 5,3 with TC4 display problem Dataloggers/Controllers/Rate of Rise Meters 14 01/23/2016 5:15 AM
AartisanQ_PID 5.3 with TC4 and RoastLogger Dataloggers/Controllers/Rate of Rise Meters 6 12/14/2015 4:52 AM
Homeroasters Association Logo, and all Content, Images, and Icons © 2005-2016 Homeroasters Association - Logos are the property of their respective owners.
Powered by PHP-Fusion Copyright © 2019 PHP-Fusion Inc
Released as free software without warranties under GNU Affero GPL v3
Designed with by NetriX