BUG? startFullBlast

[tablatronix]

If I set startFullBlast true, ( I expected startup to be 100% for a bit )

Instead it goes 100% and stays 100%

I can't see whats wrong here

  // override for full blast at start
if ( set.startFullBlast && timeX < CurrentGraph().reflowGraphX[1] )
    duty = 256;`

seems like it should only override the first graph point or reflow level but it keeps going

Anyone have ideas, I am still trying to understand the MatchTemp function and timex graphing loop

[UnexpectedMaker]

Hey mate - it sits at 100% for the entire start ramp, until it gets to the start of the pre-soak (reflowGraphX[1]) - this is really only designed for either high temp pastes to ensure you get to pre-soak as soon as it can, or for ovens that are just not powerful enough to get to any pre-soak in time.

I don't think anyone should be trying to use high temp paste in a toaster oven - bad bad bad!

It's pretty dangerous as it can overshoot the pre-soak start temp by a bit on a bad oven that can change temp fast enough.

Once past (timeX < CurrentGraph().reflowGraphX[1] ) it wont override anymore. Works here.

[tablatronix]

Hey thanks!
Yeah that is what I thought the code would do,

But it seems to do something else straight up

[UnexpectedMaker]

Oh, you are getting past the wanted temp before pre-soak, and starting above start value - interesting. will fix that now in 1.0.4 - thanks for the use case - never encountered it before myself!

// override for full blast at start only if the current Temp is less than the wanted Temp, and it's in the ram before pre-soak starts.
if ( set.startFullBlast && timeX < CurrentGraph().reflowGraphX[1] && currentTemp < wantedTemp )
    duty = 256;

[tablatronix]

I figured it was something like that, I have been working on some enhancements to pr and was always having an issue when I start with oven warmer than the profile start temp, I assume I need to do something to catch up the indexes to each other or something.

timeX seems to lag behind where it should be and is not synched to actual start temp, still reading the reflow code, I have almost all the rest figured out

[UnexpectedMaker]

timeX seems to lag behind where it should be and is not synched to actual start temp, still reading the reflow code, I have almost all the rest figured out

timeX doesn't lag behind, the system is designed to look ahead. it's never changing temp based on what it needs at it's current time... but at a look ahead time, as toaster ovens cant change temp that fast.

[tablatronix]

Is timex an index of time? Of reflow slots 0-x?

[UnexpectedMaker]

timeX is used to index into the curve of the current reflow graph, where CurrentGraph().reflowGraphX is time and CurrentGraph().reflowGraphY is temp. It's also the time count in seconds.

    if ( timeX < CurrentGraph().reflowGraphX[2] )
      wantedTemp = CurrentGraph().wantedCurve[ (int)timeX + set.lookAheadWarm ];
    else
      wantedTemp = CurrentGraph().wantedCurve[ (int)timeX + set.lookAhead ];

CurrentGraph().wantedCurve is an array of temps for every second of the profile, that is pre-processed when the profile is loaded on start or when the profile is changed.

[tablatronix]

new code seems to work, I must misunderstand how it works, thanks

This is what threw me, timex was way greater and it was still doing full duty

[tablatronix]

W00t

[UnexpectedMaker]

Wicked! I have some thoughts on how to improve the visual look of the profile graph - but not had time to implement yet - I hate the smooth tangents on it right now, but messing with the tangent values isn't doing what I expect, so going to write my own curve code ;) one day....

[UnexpectedMaker]

Is that running in your ESP32 port? or on SAMD?

[tablatronix]

esp8266

Those spikes are what happens when you have a thermocouples touching the power cable! lol PWM noise

[UnexpectedMaker]

Wow, that's messy and marginally dangerous! ;)
I just pushed v1.05 - have fun!