AbeAnd Log: Difference between revisions
AbeAnderson (talk | contribs) No edit summary |
AbeAnderson (talk | contribs) No edit summary |
||
| Line 10: | Line 10: | ||
'''Current Logs''' | '''Current Logs''' | ||
=Tues Feb 26, 2019= | |||
meeting prep. | |||
trying to scribble out soem teeth on the clamp. | |||
=Mon Feb 25, 2019= | =Mon Feb 25, 2019= | ||
Revision as of 19:58, 26 February 2019
Status - Done: PC v18.01 frame To Do: Finalize all PC docs and generate cut files Blocks: Time
Status - Done: more D3D Mini PVC clamp designs To Do: clamp part details & frame assembly Blocks: part details & time
General links Critical Path Roadmap mediawiki formatting help Development Team Log OSE Hangout OSE Jitsi Meet Abe's Links Abe's OSE Google Drive Folder Abe's OSE Google Calendar Abe's YouTube channel
Current Logs
Tues Feb 26, 2019
meeting prep.
trying to scribble out soem teeth on the clamp.
Mon Feb 25, 2019
downloaded & reviewed other golf cart parts to get ideas.
I was trying to simplify the seat further, but thinking the bench module could be changed to weld into the larger frame for support for itself and to reinforce the whole structure. Angles and maybe even some simple curves somewhere could add a lot of strength. Flexibility in a vehicle is nice too as long as it doesn't tend to get bent out of shape. Maybe some angles to the bench seat legs would be good too. I removed the 10 deg angle on the seat back, but if that was supported by a part extending between the bottom adn top that may help keep the module simpler while being stronger altogether once welded to the larger frame. Since it is a vehicle just welding it seems better long term.
Clamp 3d print looks nice, but I was wondering about hole size for tightness. I was about to shorten the bulk part of the clamp, which is what I understood from Marcin's email when I realized that would only make it the wrong length. Essentially to do it that way 2 separate parts are needed if I understood correctly. I think the hole size is the ideal way. I was trying to think how hard it would be to add teeth in the hole. Maybe it would not be the ultimate sketcher challenge, but it would add a lot of complexity. Regardless I'm thinking it would be good because it would decrease plastic in the bulk part and increase flexibility making it clamp better. If the teeth deviate from a perfect circle that would probably make it clamp good.
Sat Feb 23, 2019
Design Sprint Video https://youtu.be/uWLDsJO4KXs
The recorded file from OBS is only 457MB using x265 & Ogg Vorbis I think, which isn't as small as I was getting from vokoscreen, but for 2hrs+ of video is good given resolution; the quality still looks readable and the audio levels were ok. If I'm not careful the gain is enough I get lots of background noise picked up from typing rubbing the mic, some reverb if I use speakers etc. so it is best to mute my headset manually. There may be other settings in OBS to tweak yet. A how-to video for OBS would be useful given it is a little more complex.
started https://gitlab.com/Abe_Anderson/freecad-macros
still thinking of ways to do the symmetric square with round corners macro better, but need to search for any existing similar macros.
Fri Feb 22, 2019
Design Sprint for Golf Cart
edited basic banch seat CAD. Now I'm thinking the bench could be wider and perhaps integrated/welded to the cab frame if that is an option. It may reduce the complexity of the bench module and make more space accessible.
edited the hydraulic PC some. will need to consider further size and shape changes.
I also made attempts to record a macro for a sketch of a square with rounded corners, which I found particularly difficult to constrain. I got a macro that works ok, but it has some mistakes recorded still because FreeCAD sketch selection and the solver was being glitchier than usual.
Recording of Design Sprint video is good, but I had to retry the upload, which should auto publish to YT if it finishes overnight.
Thurs Feb 21, 2019
https://youtu.be/k_jO9vXgOSo got meeting updloaded to youtube and linked it in comment on marcin's version.
thinking about break down for assembly sub-assemblies golf cart to be prepared for design sprint.
Tues Feb 19, 2019
meeting prep.
continuing D3D Mini PVC assembly...
started on golf cart gallery. Open Source Golf Cart
Mon Feb 18, 2019
I'm further exploring the freecad center square python macro and related methods. It is definitely not immediately obvious what and how methods should be used to solve generalizing scripts like center square.
In reviewing the long design process with the D3D clamp I'm trying to think of improvements to my process that could be done differently as well as what freecad changes would be most useful. Much of it is the process being broken into short work segments making confusion and mistakes easier from one session to the next. Much of the time was also likely spent trying to avoid adding complexity when in the end a certain amount was simply required to solve the known issues.
Also the useful code from the GettingStartedFreeCADScripting.pdf to import freecad into python is:
import numpy as np
import sys
# path to FreeCAD; I found it from:
# $ locate FreeCAD.so
FREECADPATH = '/usr/lib/freecad-0.16/lib/'
def import_fcstd(path_freecad):
"""try to import FreeCAD on path_freecad"""
sys.path.append(path_freecad)
try:
import FreeCAD
except:
print "Could not import FreeCAD"
print "Are you using the right path?"
import_fcstd(FREECADPATH)
Sat Feb 16, 2019
I'm cloning the freecad repo so that I can easily access the source code for reference when I need to understand it better. Reading is the main requirement to figuring out program and code strucuture. This https://folk.uio.no/jeanra/Teaching/MEK3230/Documents/GettingStartedFreeCADScripting.pdf
The FreeCAD python console is surprisingly accessible with auto-completion, but it is still not as complete as an IDE so it might be interesting to find a way to set up and access the relevant python libs in the atom IDE so it is easier to access class and method info to write more complex code like full workbenches. For macros, which I think can help speed many things the main issue is making the code generic usually by adding some variables to get and set the current objects to the standard names freecad uses. Such as the example code shared here: https://www.youtube.com/watch?v=DurKHgtR1rw
Tues Feb 12, 2019
meeting prep.
busy then had a back problem so I avoided sitting and desk work, but read about freecad development and watched tutorials.
I double checked the distance on the bolt in the full assembly and found I calculated or measured wrong. The total length through the axis part is more than 18mm so currently the bolt length is closer to 36mm. To reduce it down to 30mm the short nut recess well have to be removed or minimized and the longer recess moved until the distance through the clamp is 0.23" which leaves less than 1/8" for each half. Printable, but possibly weak. Time to test it though.
Reworked the clamp, it measures correct now, but definitely has some thin points. Time to see how it prints.
https://gitlab.com/Abe_Anderson/d3d-mini-pvc
uploaded new files to D3D_Mini_PVC#Part_Library
Fri Feb 8, 2019
freecad a2+ WB demo https://youtu.be/mnkecA9S7kc
looks like some slight adjustments to the clamp might be needed to get the short side hex nut catcher deeper. Otherwise, I think the next steps are adding more printer parts to check assembly alignment and freedom of motion.
Wed Feb 6, 2019
updated clamp with hex holes. https://gitlab.com/Abe_Anderson/d3d-mini-pvc/blob/master/Hardware/PVC_mount_assymetrical_collar_clamp.fcstd
If the hex holes don't print well the sketch shape may need customizing. To get through the axis requires 18mm, so the shape of the clamp needs to be more complex yet to get a 30mm bolt to reach another 12mm through the clamp. Less than 0.5".
reviewing 3d printer manual and BOM's to check bolt sizes and the assembly instructions for any potential difficulties in relation to the clamp and axis'.
Tue Feb 5, 2019
trying to prepare for the meeting and continue work on the new clamp, but my internet seems flaky. fog might be blocking it.
found I failed to add the new clamp file. did so and thankfully the assembly auto updated with it nicely for a change.
https://gitlab.com/Abe_Anderson/d3d-mini-pvc/tree/master/Hardware
Fri Feb 1, 2019
Added new assymetrical clamp design. https://gitlab.com/Abe_Anderson/d3d-mini-pvc
I need tor more thoroughly review the CEB Press Code again, but I'm wondering what the ideal time delays for switching are in the long term when hardware specs degrade or environment causes variation. I'm guessing delays are required because they simply align the software with the actual hardware speed. Switching times are negligible so looking for speedups there will not give great returns. More power and maybe more efficient cylinders at higher costs seem likely to be the only path to more speed.
Delay times in the software do add up so maybe if the entire system was based more on timing such as with the math for compensation of retraction-extension then estimates of when to test switches could be made, but this adds so much complexity that is likely to fail due to variations in power and the ambient environment I can't see such methods working well.
Also given the inevitable degradation of the hardware and switches going out of spec and it not likely being worth adding any further hardware debounce (capacitors) using the existing Arduino libraries (bouncev2) as the default for debouncing all switch like inputs is likely an ideal solution. The complexity is mitigated by being as simple as possible, encapsulated for ease of novice use and well-documented and supported by the community.
Wed Jan 30, 2019
I did a find and replace all on the pressure func in all files because it didn't read sensibly I think I changed the code before or copied it and it read poorly since. Now looking at debounce options. What is done now is similar to bounce lib's BOUNCE_LOCK_OUT method and if it fails to read true the first time it fails. Also if it reads false twice due to noise. Three checks with different logic could be made, but I think something similar to the BOUNCE_WITH_PROMPT_DETECTION method may be a better fit.
I had a quick thought and added a recursion to recheck pressure after 2nd condition fails. I think this is still insufficient to catch all noise cases. It really needs to catch all the noise cases possible to prevent missing steps.
Some confusion it looks like some code updates on CEB Press Control Code v19.01 weren't pushed to the repo and I assumed they were.
https://github.com/OpenSourceEcology/OSE_CEB_Press_v19.01
Tues Jan 29, 2019
assembled D3D PVC mini axis' on frame with enlarged clamp design. the 0.6" thicker clamps are very close, but not exact; There is some negligible space, which should be fine.
https://gitlab.com/Abe_Anderson/d3d-mini-pvc
I'm examining the D3D PVC mini assembly further and thinking about the clamp and bolt length situation. The main reason for the larger clamp is because the clamp was designed to be as small to start and there was insufficient room around the PVC to make it smaller the other way to accommodate spacing for the X-axis length. The other possible positions likely require unequal axis' lengths and/or asymmetrical clamps. The Y's could go on the inside making the X length ~9" with ~6" usable print space. This may be acceptable for a 6" print bed, but less so for 8". There may be some clamp design where the Y's could go between the frame pipes, but that reduces print volume significantly. ~10.5" - (0.5-1" for clamp ~3"+) for axis parts. The Z axis is less of an issue it doesn't need to reach the top of the frame due to the extruder height anyway. The Y axis' are also slightly longer than needed.
Clearances to check are magnetic end stop holders, motors, and extruder parts.
File:PVC mount clamp.fcstd I uploaded the current version of the clamp, but I have some further ideas for reducing volume and maybe a less symmetrical design for reduced bolt length.
The bolt length is a difficult issue because 30mm is about the thickness of the clamshell axis parts, so anything reaching to bolt to the pipe needs to be much longer. Looking back at the original working doc the T style snap clamp almost worked except the 2nd bolt across the pipe was longer. The C snap style clamps are most tempting because of the minimal bolt lengths possible.
Looking at changes to CEB Press Code. If I understand what Marcin said in the meeting the debounce function wasn't always working. Looking at it now it is not surprising. It is too simple and has no state check. Something more like https://www.arduino.cc/en/tutorial/debounce should work much better and still be easy to understand. I think the reset mode option can also easily be made available after the cycle completes. Also see bounce and bouncev2 libraries https://forum.arduino.cc/index.php?topic=266132.60
Sun Jan 27, 2019
I got a return email from Marcin about the Power Cubes, reviewed Power Cube docs further and created Power Cube Modularity.
Sat Jan 26, 2019
I keep having to nearly restart the assembly of the d3d mini pvc axis', so I'm trying to find a more reliable way.
Reviewing some power cube docs per Marcin's email about further modularity by separating the hydraulic system into it's own cube.
Thurs Jan 24, 2019
changed clamp significantly to get closer to ~0.6" along the direction of the bolts to allow the X axis to fit between the Y's. It will probably still need minor adjustments, but I've made changes to the files to make that go faster at least. Still fighting the assembly solver.
https://gitlab.com/Abe_Anderson/d3d-mini-pvc
reading CEB Press Control Code v19.01 I noticed some comments could be clearer.
https://github.com/OpenSourceEcology/OSE_CEB_Press_v19.01
I also keep coming back to evaluating the loop. Particularly the selector switch changing the mode at any point. Currently, that requires the user understanding the position should only be changed at the end of a cycle ideally; Since results may vary when changed during any step. The startup is ok because the recalibration cycle gives the user time to set the switch position and this is a repeated cycle creating a good point to change it if desired while continuing auto operation. The delays and relatively slow speed of operation negate thrashing about of the machine when the switch is turned through multiple positions, but the code in the loop still executes a step once it detects a certain position. Users will need to be instructed to change the selection position at ideal points. Possible workarounds require a state machine mode check changed only at the start of cycle or major changes to the code to reduce branches.
This has given me a possible idea for a simpler program. The main difference in the mode options is the delay(time). Currently, the drawerExt calibration time is being used for the main cylinder as well. I recall the main cyl should be slower, but the times are probably close enough this works ok and the modifier values can be changed. Using drawerExt time for the main cyl might be a little confusing to read though. If a selectionMode() is made that returns the time in delay(time) instead of just a number it would eliminate the need for the current functions. All of them I think. resetSel() would need to return 0. Lots of code gets moved from the loop to a single larger function, but I think with many fewer lines of code. Thinking further...
I explored adding the function to return time without removing the others, which was quicker to see that it doesn't change too much. The uniqueness of possible steps still requires a lot of other code so it may reduce lines of code, but not too much complexity. There are many possibilities that may reduce lines of code, but not necessarily overall complexity.
Wed Jan 23, 2019
Testing https://platformio.org/platformio-ide in Atom for Arduino IoT. At first, there were some differences to work through because of moving to a more standard project file/folder structure, but I got it to compile ok and the serial port works ok after I used Arduino IDE serial twice to apparently reset the currently running sketch. That could be a program bug in the climate monitor. Apparently to access some platformIO features a free account is required. They are pushing services, but it is all open source based on github's electron framework as I understand. Reading further the debugger is not part of the free community version. It isn't the most critical feature currently and the platformIO IDE addition to Atom plenty of features beyond Arduino IDE, but I'll keep looking for alternatives.
I also added an install of Arduino IDE 1.8.8 and tested it ok. It even drops some warnings related to internal arduino libs in verbose output. It also reminded me of the memory usage with its more friendly compiler message output. The global class instances in the Climate Monitor/Controller are probably an issue especially since much more would be added by wireless and any future features. I need to study class scope better to find solutions.
https://gitlab.com/Abe_Anderson/d3d-mini-pvc
Reviewing the d3d pvc mini I see I still have a lot of assemblies to test. I think I was fighting the assembly system just to get measurements before trying to do a full assembly so I didn't end up doing it repeatedly. There must be better ways.
AbeAnd_Logs_2018#Sun_Dec_2.2C_2018
Looks like increasing the clamp half thickness by ~0.16in's would make the rod length work out longer at ~14.45in's, but I recall now it is more complex than it first appears due to multiple clearance points.
Tues Jan 22, 2019
I just found a code issue. Line 128
if (resetSelected() == false) { executes first and then the following operations as well when the selector switch is in position 0. This is because position 0 provides no inputs. I was assuming that when there was no input the code was doing nothing, but detecting reset mode requires a connection. Making it work by exclusion may not be a good design nor do I see that working with the current code layout. Technically there being no inputs detected (position 0) the machine ideally would do nothing. checking emails about code. this will require some thought.
I think Marcin's idea of making reset the exclusion of any inputs works out ok. So I changed the reset function and restored the 1/4 brick option.
https://github.com/OpenSourceEcology/OSE_CEB_Press_v19.01
added more comments.
I think the inputs for the switch need to be set with internal pullups for the easiest wiring method so I added the option to the *.ino file.
Looks like the test files need updating. If I understood git for code better maybe I could merge them.
Rethinking code on line 150 - https://github.com/OpenSourceEcology/OSE_CEB_Press_v19.01/blob/master/CEB%20Press%20Test%20Code%20-%20Selection%20Switching
I don't see how it can be the code. Using && (AND) and not || (OR) is the correct condition for making the reset exclude all other options. It must be a switch wiring issue... No line 79 has clues.
https://www.arduino.cc/en/Tutorial/DigitalPins
Prior to Arduino 1.0.1, it was possible to configure the internal pull-ups in the following manner: pinMode(pin, INPUT); // set pin to input digitalWrite(pin, HIGH); // turn on pullup resistors
I'm also trying to correctly setup arduino to work with Atom for ease of coding and found this to work on tomorrow.
https://www.youtube.com/watch?time_continue=18&v=EIkGTwLOD7o
Sun Jan 20, 2019
BSD licensed lib should be compatible with sunfounder LCD. I can't tell the hardware is open source and the other software libs are not licensed. https://github.com/mathertel/LiquidCrystal_PCF8574
Looks like there are a few wear leveling libs for Arduino, but one looks too simple. How it encodes the number matters more because of wear leveling. Storing a single byte or 255 bricks is obviously not enough. An unsigned long (32 bit) will store 4M brick count, but erases 4 bytes each update. 65K from using 16 bit is reasonable. Users can understand it rolled over. I'm sure there are other complex binary encoding schemes to consider as well. If it writes a brick value based on time (hourly) and is wear leveled in a series of addresses they could all be added, except that it would need to incorporate a way to tell which, addresses to add or not.
https://duckduckgo.com/?q=arduino+EEPROM+wear+leveling&t=h_&ia=web
There are multiple ways to get a brick count without an integrated screen that don't necessarily require using EEPROM.
- Serial I/O to computer/cell phone over USB
- Wireless - wifi/BLE to device(s)
- Use the SD card slot available on a reprap LCD kit. Likely more useful in conjunction with the above output methods.
With likely many oversimplified assumptions:
For simple series wear leveling and 2 byte unsigned longs that halves the 4096 bytes of EEPROM on the Mega2560 to 2048 records. If hourly writes are made on a machine making 7 bricks per min. Thats 420 BpHr. * 2048 hrs = 860160 brick count / 65536 = 13.125 rollovers. 65536/420 = ~156 hrs.
More research on the wear leveling algorithms in the available libraries is needed... https://forum.arduino.cc/index.php?topic=85047.0 https://forum.arduino.cc/index.php?topic=385419.0
"Table 28-12 says that the EEPROM has a 4 byte page size." So it might as well write/erase 32bit values up to 4.294967296e9 each time. That, however, means it is only good for 1024 records. 1024 hrs*420Bphr = 430,080 brick count. I'm not sure how an algorithm could write to each in series every hour then read and add each. Then when all are written add and overwrite to the first, repeat until one hits 4.3M. Hmm 1024*(2^32) = 4.398046511104e12 (2^32)/400(~brick per Hr) = 1.073741824e7 so need to limit writes to conservative 100K writes per page. 400*100000 = 4e7. 40 million counts per page * 1024 pages = 4.096e10 total count, but I'd better look at some algorithms before deciding this makes any sense...
AVR101: High Endurance EEPROM Storage
reviewed CEB Press code, considered possible strucutural code changes and decided against any. I added some more comments to clarify code layout and commented out the 1/4 brick option since the selector switch has no contacts on option 0. I also renamed the file to *.ino so I could check compilation. Maybe a newer version of Arduino IDE would tolerate the file name?
https://github.com/OpenSourceEcology/OSE_CEB_Press_v19.01
Sat Jan 19, 2019
Still looking at menu library options and thinking we could use some more software devs for creating and maintaining the big picture software API's for arduino/RISC V microcontrollers. Even if there are universally used libs for everything if they are designed right code that isn't used won't add any excess to the sketch sizes. Simple C/C++/Python libraries can also be coded so that they are not standardized to a specific platform like Arduino. I'm curious what existing open source code is used in the 3d printer reprap etc. It does not look like the reprap screen is necessarily ideal for the CEB Press, but if it can be adapted that would be great.
I now see there are reprap kits that include the lcd, mega, rambo and they are much cheaper than the plain RepRap LCD's kits. The Marlin code is what needs to be adjusted to exclude almost everything except the HD44780 LCD controller code, the ULCDST7920 LCD code, digipot mcp4451 and maybe the DAC_MCP4728 for i2c? There is a bunch of custom font/language related code and I'm not sure what should be saved or cut. A programmer familiar with marlin should be able to cut out what is unneeded quickly.
Reviewing CEB Press code and LCD options.
Scanner for 16x2 LCD with LCM1602 module http://henrysbench.capnfatz.com/henrys-bench/arduino-displays/ywrobot-lcm1602-iic-v1-lcd-arduino-tutorial/
PDF for chip it uses. http://wiki.sunfounder.cc/images/1/18/PCF8574T_datasheet.pdf
Thurs Jan 17, 2019
Looking at possible menu libs and this one looks simpler than most, but still more complex than I expect. However, it may be more universally useable across devices and that would save time. The licenses look ok. https://github.com/DavidAndrews/Arduino_LCD_Menu
Also, I was just noticing from [Talk:Freezer to Refrigerator Conversion] that the price of the MKR1000 with wifi is much lower than I recall. That could be a more integrated solution for getting wifi. The only added issue I think is level shifting to 3.3V.
Tues Jan 15, 2019
I was late for the group discussion, but it was long and interesting anyway. I've been thinking the Scale Model's Chas brought up would be great sale items as toys if they are functional enough. They could also be model kits for learning by doing the assembly. It creates the possibility of open source hardware maker like projects for younger children. Maybe functionality of something like a scale model CEB Press could be advanced enough such that it could make blocks of playdough to build open building models. Just thoughts.
I've reviewed most of the new work on CEB Press 2019. Changed my mind a couple times after reading further. The analog pot should be easier than I thought to code with delay()'s since it can map() a voltage to some calculated time to move with sufficient accuracy. One thing I'm still unsure of is recovery from an error in an unknown position and calibration from that in position one. Without a manual control mode to set the 2nd cyl if it gets to far off it may be hard to reset. The further hardware simplification concepts and code layout look good overall though. But, I need to review and think more. https://docs.google.com/presentation/d/1YLo7e6RW4SUq7v5NFQ2WoX2ZFHsnoa3wI9m8Oc5-24g/edit?ts=5c3e6821#slide=id.g4d84192e63_0_180
I need to review the logs from the GH monitor, which has now run through a daily loop again on my desk. I think the memory addressing logic can be simplified more, but I'm unsure the ideal way to do so. Also the menu system needs work. I don't think it is immediately relevant to the CEB Press, but putting a good simple menu system in a separate library will be useful. I still need to review more menu libs. Ruslan also mentioned a climate sensing system maybe on his log or OSE Germany wiki I should look at.
Mon Jan 14, 2019
I think I made some more progress on the climate monitor code. FRAM management still needs more thorough testing and ideally some more functions if possible. Not ready for a class. The complexities of menu's and button logic are making me think it needs its own class.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
Sat Jan 12, 2019
I've suspected for some time there could be bugs in the underlying hardware/software setup I'm testing, but I keep finding mistakes in my code changing it and therefore making and finding more. With excess conditional logic checks and serial output added I'm now seeing a change in a FRAM data that I can not explain from my code even though it seems somewhat consistent across resets. I find it hard to believe it is i2c bus issue, but I'm reviewing code deeper for any nearby calls in other libs.
https://stackoverflow.com/questions/37035186/multiple-i2c-cant-work-with-arduino-uno
There may be an issue with the way I've connected the devices or their addressing over i2c.
It looks like adding a Write Protection control line has fixed the FRAM glitch, but it will need more work to refine since I assumed it needs delays for timing. I also fixed some precompiler warnings, but one strange one remains.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
Fri Jan 11, 2019
I think I'm close to finally hacking through the mess made by using FRAM memory usage to store machine state between reboots due to previous coding mistakes. Using the FRAM to store the state technically can throw data averages off because without an RTC the timers are relative, but I think it is an ideal feature so that power loss doesn't cause existing data to be overwritten. Especially since I do not have wireless integrated yet. Looking at the ESP8266 closer it has an Arduino compatible MC in itself and runs at 80Mhz, but I'm not sure it is a good idea to think it should be used by itself. Mainly it lacks I/O pins compared to the Uno or Mega. Most of the instructions show hooking it to an Arduino via the serial RX/TX. I'm also making some progress testing and thinking about the menu's and button states. I'd still like to review more existing menu libs in case something can be more easily used by removing excess functions etc. than trying to write a whole new system myself.
Thurs Jan 10, 2019
Code fixes continue to be messy, but seem effective for fixing the over complex fram memory access without more modular classes/methods. Getting access to the data once it writes it correctly may require even more cludgy code or more vars for memory management. I should have it semi functional soon and will start thinking about a box to put it in for live testing.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
Tues Jan 8, 2019
I tried a quick fix for the FRAM address issues and left the controller running overnight. I doubt that fixed the address math, which really needs it's own library to manage FRAM more dynamically. I still haven't found the cause of the 'E' in the pressure lcd print and the 0 in humy2 because the values serial print fine. I don't think its a conversion or type error at this point, but I'm not sure how it may be related to FRAM address math errors. With a little more time I should be able to get the basic sensor records working good enough and de-prioritize the modular libs for later to focus on CAD again.
meeting prep.
I tried to record our semi-organized discussion and it seemed ok at first, but there must be some internal software issues with vokoscreen or ubuntu because the recording later has severe audio noise similar to what we were hearing from Marcin's videos as well. I think that clarifies that it is a software issue not a hardware mic issue. Possibly an ubuntu or pulse audio issue.
Looking at GH controller code the hard thing to debug is the FRAM addressing even though I've done it before besides needing it's own library part of the lack of modularity or granularity is the custom data strucure I chose to make it easier at first, but really array(s) would make things easier for granular access. One 16bit int type could be used instead of 8bits for all or maybe two types of arrays could be made for each. This unfortunately would require a lot of code rewrite. In the end this seems the most modular route and would carry over to the eventual class libs better as well.
Mon Jan 7, 2019
After starting a new branch for the GH controller with the intent of modularizing the code into multiple useful libraries I'm still thinking basic climate monitoring would be useful. The timer class changes I made while trying to get the LCD menus working better made the existing loop logic different. I was fairly sure last year I had the FRAM access sorted out, but currently, there is some data type confusion or disorder in the logic. Leaving the classes for later may add confusion, but getting something useful now and going back to working on CAD seems a better priority.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station/tree/sensors
Sun Jan 6, 2019
I've been thinking about GH Monitor/Controller because I figure there are better ways to encapsulate code more, but I finally got around to plugging the old hardware back in and as I expected it doesn't quite work how I wrote the code since I don't recall how the LCD write works exactly.
Fixed some obvious mistakes, but still more significant issues. Some likely caused by changes to the main loop using the Timer class. Trying to think of ways to add more of it to functions and classes.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
Tue Jan 1, 2019
Continued some code updates to the greenhouse monitor and control station. Tryin to modularize the code better so it is more useful for other projects as well. I finally got it to compile in the Arduino IDE v1.05 with all the previous libraries. From some prior more recent research, I found there are likely better libs available since most of the design is more than a few years old. I continue to prefer writing my own simpler code in many cases because many of the optional libs with needed functions were also excessively larger and as complexity and options grow it may become too large. There are newer faster hardware options enabling the use of circuit python, which is probably easier to code, but they are more expensive and less efficient. If required I think the C++ code can be easily run on more advanced hardware though. The code may need updates to generalize the types for cross-platform though. I also do not expect the code to work the way I'm assuming currently.
I have yet to reconnect the hardware on breadboards for actual testing and code remains far from complete. I think more restructuring and OOP classes will improve code usability. I'd like to test the basic sensors for greenhouse use this winter-spring, but I don't have a plan for packaging the hardware yet either. I recently added some temporary, but water resistant safe electrical to the greenhouse. I don't think the greenhouse is large enough to warrant complex systems, but so far small changes have helped.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
https://docs.google.com/drawings/d/1gjtrbWVbxtNjfkAmB7RW-BoM72ZRPpgSUTgVxkS9IvY/edit
https://docs.google.com/drawings/d/15V_-4Y2CEDsFE0q8cFWSfc_9qI3jPTPOZ3HXsDCZ9JE/edit
https://docs.google.com/spreadsheets/d/1PM3yYz9tTfzzj9uBumbAGERmuzl01O4XbtE-WeyNf-c/edit#gid=0
Old Logs
2018
2017
- AbeAnd Logs December
- AbeAnd Logs November
- AbeAnd Logs October
- AbeAnd Logs September
- AbeAnd Logs August
- AbeAnd Logs July
- AbeAnd Logs June
- AbeAnd Logs May
- AbeAnd Logs April
- AbeAnd Logs March
- AbeAnd Logs February