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.

01/12/2021 6:15 PM
@Nomad As a general rule Roasting should not exceed 20 min to second crack You are describing is baking

12/31/2020 2:39 PM
I trying another 2 cups at 200 for 45 min

12/31/2020 2:38 PM
I have a questions.. im trying to experiment with riasting.. i roasted 3 cup of nicaraguan at 200 degrees for 1 hr and 30 min.. is that to long?

12/17/2020 11:16 AM
Snow again in NC.

12/13/2020 3:51 PM
I didn't realize snow was forecasted for this neck of the woods

Users Online
Guests Online: 8

Members Online: 0

Total Members: 6,948
Newest Member: alixis
In Memory Of Ginny
Donations

Latest Donations
Anonymous - 5.00
Anonymous - 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
sebiiksbcs
Nice that there's still development on this. I have been looking at the code and saw that there were changes in the way the buttons are checked, too? (buttons.keyPressed / buttons.keyChanged) Is this more efficient now?

Next question, I see that there are the two arrays profile_name[40] and profile_description[80], however it looks like only the first 20 bytes of the name and 40 bytes of the description are ever accessed (to be displayed on the LCD) or am I missing something here? Anyway in my custom branch I have reduced the name array to 20 and done away entirely with the description as I don't use it, instead I am displaying the first 5 times and temps of the profile.

TL;DR I believe many bytes of RAM can be saved by reducing array sizes.

Actually while I am here, I was wondering how many of you still use the firmware for standalone as I've implemented profile editing commands via serial monitor. If there is interest I could "revert" my code to be compatible with the original branch and share it ...
renatoa
A lot of memory can be saved in the TC code area, there is no need to let the J and T type termocouples code alive and eat space, when only K is used.

Me too added a PROF(ile) command, for fully profile management via serial, but is there just for the record, because switched to other profiling paradigm, based on DE and FC moments only as targets.

Not sure what you mean "as standalone", my goal in TC4ESP was been to use it as standalone as possible, getting rid of any computer tethering, and I think I succeeded... but with other memory resources, not available for Uno boards.
So yes, I am roasting with the board only, all time. However, every roast data points are stored in the board memory, and I can dump later via serial directly in Artisan .csv format, for desktop graph, analyse, archiving, etc.
greencardigan

Quote

sebiiksbcs wrote:
Nice that there's still development on this. I have been looking at the code and saw that there were changes in the way the buttons are checked, too? (buttons.keyPressed / buttons.keyChanged) Is this more efficient now?


First change in a few years woohoo.
I was working on another project (hot air reflow controller) and wanted this mode for it.

The buttons.keyPressed / buttons.keyChanged have been in there for a long time. They are used if you have the LCDapter code active. If using the other I2C LCD option it use the code in checkButtonPins().

Quote


Next question, I see that there are the two arrays profile_name[40] and profile_description[80], however it looks like only the first 20 bytes of the name and 40 bytes of the description are ever accessed (to be displayed on the LCD) or am I missing something here? Anyway in my custom branch I have reduced the name array to 20 and done away entirely with the description as I don't use it, instead I am displaying the first 5 times and temps of the profile.

TL;DR I believe many bytes of RAM can be saved by reducing array sizes.


I haven’t looked at it too closely but I think your right, it looks like only half of memory allocated gets used. Also the profile_name and profile_description don’t get used at all unless it is running in standalone mode which is currently the only time buttons are checked and the LCD can display alternative views.

Quote


Actually while I am here, I was wondering how many of you still use the firmware for standalone as I've implemented profile editing commands via serial monitor. If there is interest I could "revert" my code to be compatible with the original branch and share it ...

I’m not aware of many using the standalone mode. I added it for myself many moons ago but found the uploading of profiles too cumbersome. I’m assuming that most users are connecting to Artisan roasting software.

I’d be still interested in seeing it. If I get around to it I could try to tidy up the code to save memory (will look at the thermocouple code as suggested by renatoa ThumbsUp)
greencardigan

Quote

renatoa wrote:

A lot of memory can be saved in the TC code area, there is no need to let the J and T type termocouples code alive and eat space, when only K is used.

Me too added a PROF(ile) command, for fully profile management via serial, but is there just for the record, because switched to other profiling paradigm, based on DE and FC moments only as targets.

Not sure what you mean "as standalone", my goal in TC4ESP was been to use it as standalone as possible, getting rid of any computer tethering, and I think I succeeded... but with other memory resources, not available for Uno boards.
So yes, I am roasting with the board only, all time. However, every roast data points are stored in the board memory, and I can dump later via serial directly in Artisan .csv format, for desktop graph, analyse, archiving, etc.

Yes, this is what standalone mode is referring to in the code. No connection to any other device while roasting. Using profiles stored on the TC4 eeprom.
sebiiksbcs

Quote

I’d be still interested in seeing it. If I get around to it I could try to tidy up the code to save memory (will look at the thermocouple code as suggested by renatoa :ThumbsUp:)


Edit: wow, directly pasting the code seemed to break the layout. I've attached the cmndreader.cpp and cmndreader.h files.



This is only the respective "doCommand" function in cmndreader.cpp, of course you'd have to add all the class, prototype, initialization etc. stuff. Also I have made quite some modifications on your code just so I could better read and understand it, and to save some bytes of memory here and there so the firmware could run standalone and talk to artisan at the same time without crashing.

Hope this makes sense, not sure what other mods I made that might prevent the code from running, but since you wrote the firmware I guess you'll figure it out! Let me know if anything's missing.
sebiiksbcs attached the following file:
cmndreader.zip [6.77kB / 3 Downloads]
renatoa

Quote

greencardigan wrote:
...I could try to tidy up the code to save memory (will look at the thermocouple code as suggested by renatoa ThumbsUp)


Check the modified thermocouple code in the TC4ESP custom libraries folder:

https://github.com/renatoa/TC4-shield...ermocouple

The new usingK(T/J) defines are the flags that invalidates big chunks of code, for each unused TC code.
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 8:32 PM
Help with aArtisanQ_PID Specifying Temps Dataloggers/Controllers/Rate of Rise Meters 7 08/03/2017 7:05 PM
TC4 aArtisanQ_PID or Standard Library Dataloggers/Controllers/Rate of Rise Meters 45 01/24/2016 12:17 PM
aArtisanQ_PID 5,3 with TC4 display problem Dataloggers/Controllers/Rate of Rise Meters 14 01/23/2016 11:15 AM
AartisanQ_PID 5.3 with TC4 and RoastLogger Dataloggers/Controllers/Rate of Rise Meters 6 12/14/2015 10: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 © 2002 - 2021 by Nick Jones.
Released as free software without warranties under GNU Affero GPL v3.
Designed with by NetriX