Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blinka support #112

Closed
jbruce12000 opened this issue Oct 28, 2022 · 71 comments
Closed

blinka support #112

jbruce12000 opened this issue Oct 28, 2022 · 71 comments
Labels
feature help wanted Extra attention is needed in-progress

Comments

@jbruce12000
Copy link
Owner

jbruce12000 commented Oct 28, 2022

Switch from current GPIO libraries to blinka.

That's the underlying issue for #111 and others.

References:

@rondoc
Copy link

rondoc commented Oct 28, 2022 via email

@jbruce12000
Copy link
Owner Author

jbruce12000 commented Oct 30, 2022

@rondoc Do I need to keep doing updates?

nope. if the kiln-controller.py is working for you at a specific version, you can pin to that version and never update. Every commit has it's own unique signature and you can checkout code using that signature. This means that you can effectively never update. if you have bugs or problems with a specific version, you'd have to tell me when you file the issue. check out the output of git log in the kiln-controller directory if you want to see the commit history. See those long hex strings that look like this?

commit 3d8333a16bf553bde9acf537b8e564524f857db6

with any one of those, you can do a git checkout like:

git checkout 3d8333a16bf553bde9acf537b8e564524f857db6

then you are pinned to that version.

Does internet connectivity make any difference to this question?

hmm. if you want to update directly from the git repo to your raspberry pi, you must be connected to the internet. After you pin to a specific version, you don't need to be connected to the internet.

@jbruce12000
Copy link
Owner Author

Adding blinka could mean a flood of questions about specific hardware I cannot answer because I have no experience with them. Looks like fifty boards are supported https://circuitpython.org/blinka

@jbruce12000
Copy link
Owner Author

wow, it's actually 72 boards that have SPI support. I'm gonna need some help testing the adafruit-31856. Any volunteers? I'll help as much as I can, but I don't have one of these.

@jbruce12000 jbruce12000 added the help wanted Extra attention is needed label Oct 31, 2022
@afreeth
Copy link

afreeth commented Nov 1, 2022 via email

@jbruce12000
Copy link
Owner Author

Thanks @afreeth. I appreciate the offer. I think it would be cheaper for me to get one straight from adafruit.

@jbruce12000
Copy link
Owner Author

ok, I have everything working but thermocouple exceptions. These will take a little time because the underlying adafruit libraries are inconsistent.

@jbruce12000
Copy link
Owner Author

I have documentation changes to make, but I'm gonna need help testing this. Does not matter if you're using an adafruit-31855 or adafruit-31856. Does not matter what rapsberry pi version you're using.

@phdbrewer
Copy link

phdbrewer commented Nov 2, 2022 via email

@jbruce12000
Copy link
Owner Author

@phdbrewer cool. post here when your hardware is ready. I should have all the docs completed by then.

@jbruce12000
Copy link
Owner Author

documentation is complete except for the replacement schematic. I'll get that done soon. Tons of changes. Lots of new docs. Modified the kiln-tuner. Added some docs about scheduling kiln runs which I think will benefit lots of folks:

https://github.com/jbruce12000/kiln-controller/blob/blinka/docs/schedule.md

Something everyone needs to understand that is when I commit this change to master, it will be a breaking change. Everyone will likely need to move around a couple of wires to connect to raspberry-pi SPI pins. So, you can pin at an old version and do nothing, or use the new version, change some wiring, and test.

None of the PID code is changing, No functionality is going away... but the underlying 31855 and 31856 libraries are going away and being replaced by blinka - which adafruit owns and maintains.

@jbruce12000
Copy link
Owner Author

Testing this branch is blocked on me. I have to rebuild the high voltage/high current wiring in my personal controller.

@jbruce12000
Copy link
Owner Author

Finished rebuilding my controller and started testing yesterday. Tested autotuner. Completed a test profile on my kiln.

@jbruce12000
Copy link
Owner Author

I've done lots of testing on this branch. The autotuner works well and it required only slight adjustment for my preferences on my kiln [about half as much integral]. Temp control and error handling seem bug-free. New settings work well. test-output, test-thermocouple, and gpioreadall all worked well during initial setup. docs changes look ok.

I'll test with a long bisque fire this week.

@jbruce12000
Copy link
Owner Author

more testing today. ran into a bug last night with config variable naming. ran my profile 90% and then died. bummer.... but fixed the bug.

@chipgarner
Copy link
Contributor

@jbruce12000 Can you explain the naming bug? I would like to see if I can create a test that will catch this and other similar bugs.

@jbruce12000
Copy link
Owner Author

setting in the code was changed from

config.ignore_too_many_tc_errors

to

config.ignore_tc_too_many_errors

see for yourself with...

git diff 90d10eb abaf155

Around 1600F my thermocouple started getting lots of errors [which is normal] and since the variable was named incorrectly, my setting in config.py was ignored and the code ended my schedule because it though there was an emergency. These errors are caused by plasma in the kiln making it my tc appear to have a short circuit.

@chipgarner
Copy link
Contributor

I use Pycharm and it flags errors like this, making them much easier to find! There is a free version. There are other python code checkers. I will go through the blinka branch and check for "cannot find reference" issues.

I need to learn about plasma. So far I have left it to the fusion physicists.

@jbruce12000
Copy link
Owner Author

I think doing lint checking is great. I think we should strive to:

  1. have automated tests that
  2. can be executed via github actions

I'm no testing expert, but there are lots of testing libraries out there for python. Let me ask one of my developers at work and we can get started on that after the holiday season.

@chipgarner
Copy link
Contributor

I checked all the .py files in blinka and did not find any issues.

I use pytest, it is pretty great and is widely used. I wrote a couple of unit tests for the additions I made for the seek function.

@chipgarner
Copy link
Contributor

@jbruce12000 Have you tested the MAX31856 yet? I may have found an issue.

I don't have a kiln controls connected but I do have a Pi and both a MAX31855 and MAX31856 with thermocouples, so I can do some testing with this.

@jbruce12000
Copy link
Owner Author

@chipgarner I don't own a MAX31856. testing blinka with that would be great. I might switch to the 31856 soon.

@chipgarner
Copy link
Contributor

@jbruce12000 Found some issues with the '56 code. I made some minor changes and have it running. I will clean it up and do a pull request in a day or two.

@jbruce12000
Copy link
Owner Author

@chipgarner sounds good

@rondoc
Copy link

rondoc commented Jan 3, 2023 via email

@jbruce12000
Copy link
Owner Author

It's temperature related, 1600F and above only. The thermocouple leads are isolated and cannot physically contact each other.

@jbruce12000
Copy link
Owner Author

Well, plasma doesn't exist at temps this low... so it's something else. Maybe thermal expansion is causing contact near the tip of the TC.

@jbruce12000
Copy link
Owner Author

Cool. I'd much rather make iterative change than radical.

@chipgarner
Copy link
Contributor

My MAX31856 quit at at little over 1200f. The call to wait_for_one_shot got stuck and the temperature went to zero. It works fine after the kiln cooled down. I plugged the thermocouple directly into a Fluke thermocouple module and it worked fine through the rest of the firing, no errors and good temperatures. I tried it with two different programs on the Pi, so I think the problem is the MAX31856 itself or the Blinka software. This could be only my system but is a bit worrisome if I am the only one who has tested the MAX318356 with the Blinka library at high temperatures.

@jbruce12000
Copy link
Owner Author

hmm... seems bad. I'll put off merging until we can definitively call that addressed. I'm sure if we find a bug, the blinka team would be happy to get a PR.

there is no one else that has tested the MAX-31856 on the blinka branch that I know of.

@chipgarner
Copy link
Contributor

The MAX-31856 does hang up in "one-shot" in the Adafruit library. I am trying to test a mod to the library to exit after a while, but of course can't get it to stick now. I have no idea what causes it to hang up but am hoping it will throw and error when it skips out of the while loop. I'll post when I learn something.

The '56 uses a blocking call when it gets temperatures and it takes about 165 ms to return the temp, assuming averaging 1 is selected. (It takes around 670 ms if averaging is set to 16.) This will effect the temperature averaging. I don't think it will really matter to the outcome but the averaging over 40 measurements will be over about 6.6 seconds instead of the expected 2 seconds.

@jbruce12000
Copy link
Owner Author

ugh. At 165ms, it seems like the default should be 10 instead of 40. 2000ms/165ms = 12.12

@jbruce12000
Copy link
Owner Author

I really wonder what is happening during that 165ms blocking call.

@chipgarner
Copy link
Contributor

That's how long it takes to query the '56, have it read the voltage and convert A/D. I am pretty sure the '55 takes about the same amount of time. It just does a non blocking call to get the latest temperature.

On the '55, it keeps reporting the same temperature over and over if you query it in a fast loop. (It will return the temps every 1 to 2 ms.) I tried this at very high ramp rates and it seems to take around 160 to 170 ms to report a change in the temperature. The 14 bit A/D results in 0.25C resolution, so you need a heating or cooling rate of several degrees per second to measure this.

Again, I don't think this makes much difference functionally as even a small oven changes temperatures over at least several seconds. It may mean there is opportunity to simplify the code, but it works!

@jbruce12000
Copy link
Owner Author

At the very least, it means that the config default of 40 reads over 2s is too high and that it should be changed to 10 reads over 2s.

@jbruce12000
Copy link
Owner Author

ok, committed that sane default of 5 samples per second... which is 10 over 2s by default.

@chipgarner
Copy link
Contributor

I have done more testing thanks to a thermocouple emulator from @rondoc. This is a variable power supply that mimics the voltage from a thermocouple, simulating about 460 to 2500f. I have not been able to reproduce the error I had during firing, when the temperature stopped updating because the thread hung waiting forever for the one shot temperature to be computed.

I have been able to reproduce the error, very unreliably, by introducing a thread collision that does not happen in the kiln-controller code. I have not seen any errors at all when testing the latest Blinka branch with the tc emulator. I have run it for several hours and gone through the temperature range multiple times.

I think the error I saw was a one off, and may have something to do with my setup during the firing that is not happening with my testing. @jbruce12000 I don't think you should hold up the release any longer on account of this.

If the error ever does occur, the only symptom is that the temperature stops changing on the UI page. If anyone sees this I recommend shutting off power to the board for about one minute before turning it back on.

Again, this happened once during a firing as the kiln went past about 1200f. I tried restarting the Pi. I may have been hasty or there may have been something in my setup that was still a problem. The next day, after cooling off, it worked fine.

I am leaving for three months in Taiwan and won't be able to test this in a real kiln until my return in May. I will be able to code and test with the emulator.

@jbruce12000
Copy link
Owner Author

understood. thx for your testing effort. enjoy Taiwan.

If anyone else out there has a max-31856 and is interested in testing, lmk. if not, I'll purchase one and test it myself.

@rondoc
Copy link

rondoc commented Jan 22, 2023 via email

@phdbrewer
Copy link

phdbrewer commented Jan 22, 2023 via email

@rondoc
Copy link

rondoc commented Jan 23, 2023 via email

@jbruce12000
Copy link
Owner Author

Ah lost wax process. cool. happy to have you help. let me know if you need anything from me.

If you don't know how to check out a specific branch [in this case blinka], lmk.

@captaincaden
Copy link

@jbruce12000 I've been using 31856 on raspberry pi zero 2W since I started this project. Was looking at updating to this branch, mostly because I want the feature that we discussed a month ago that was merged into the blinka branch. I'm unsure what all will need to change though with switching to this branch, as I see you mentioned something about needing to change the high voltage wiring. I'd be happy to do some testing with 31856, if I knew what exactly I'd need to do to update to this branch.

@jbruce12000
Copy link
Owner Author

@captaincaden no high voltage wiring changes are needed. The only thing that needs to change are the GPIO connections from the PI to the max-31856:

spi_sclk  = board.D11 #spi clock
spi_mosi  = board.D10 #spi Microcomputer Out Serial In (not connected) 
spi_miso  = board.D9  #spi Microcomputer In Serial Out
spi_cs    = board.D5  #spi Chip Select

@jbruce12000
Copy link
Owner Author

jbruce12000 commented Feb 3, 2023

Also, see the Testing section in that branch. It has a few scripts for testing connections once you make the wiring changes:

test-thermocouple.py
test-output.py
gpioreadall.py

@jbruce12000
Copy link
Owner Author

@captaincaden also, I love that you're using a Zero. I always wondered how well it would run. Now I know... just fine. Did you get the one with headers? or install your own? or solder directly to the board?

@captaincaden
Copy link

@jbruce12000 You're saying that I'd need to change the physical wiring from the pi to 31856 or just the code? Currently I have it wired with GND to GND, Pin11(GPIO17) to SDO, Pin13 (GPIO27) to CS, Pin15 (GPIO 22) to SCK, Pin19(GPIO10) to SDI.

The only issues I've had with the Zero 2W is that it runs extremely slow when trying to use remote desktop, and asking it to load chromium for anything onboard takes at minimum an hour to load a webpage. But it does great with this program. It was the only Pi that was available to purchase when I first started this project a year ago, but it has worked very well so far for me. I soldered directly to the board, on both the Max 31856, and the Zero, then built the transistor circuit for switching the relay on a small piece of perf board.

Because I soldered directly, swapping those connections from the 31856 assuming you did mean they physically have to be changed may take some time to get around to.

@chipgarner
Copy link
Contributor

@jbruce12000 It looks like CircuitPython is capable of using any GPIO pins for the thermocouples via software SPI. It is a little more low level than using the MAX31855 and '56 libraries but does not look difficult. See:
https://learn.adafruit.com/circuitpython-basics-i2c-and-spi/spi-devices
Scroll down to Software SPI & I2C.

This is could be extremely useful for lot of people who don't want to switch pins but want the new features.

It is slower than using hardware SPI. This will work fine for the thermocouples but it seems like good practice to use hardware SPI when the pins are connected for it.

I have both thermocouple boards and the emulator, so I am well equipped to work on this.

@jbruce12000
Copy link
Owner Author

@chipgarner I love the fact that folks wont need to change hardware. I wonder what the max read rate will be? With HW SPI, the current read rate peaks at about 5/s. I'll need to test this and suggest a sane default for config.temperature_average_samples.

@chipgarner
Copy link
Contributor

I have it working for the '55 but not the '56. The '55 is easy, use adafruit_bitbangio instead of busio to set up the SPI.

I don't think this will be slow, the "slow' baud rate is 100000 and we are only talking about a few bytes at a time.

@chipgarner
Copy link
Contributor

It looks like this is why the '56 doesn't work: adafruit/Adafruit_CircuitPython_BitbangIO#20

From what I can tell by searching the MAX31856 works with software SPI on Arduinos. It would be possible to make a C module and call it from Python. It would need to be compiled for various boards.

@jbruce12000 What do you think of a fallback that uses the old library for the MAX31856 using software pins? It wouldn't work for all the boards, but this is mainly for people who already have something working and soldered up. New boards can use the hardware pins.

@rondoc
Copy link

rondoc commented Feb 14, 2023 via email

@chipgarner
Copy link
Contributor

@rondoc Some people want to use platinum thermocouples. The workaround is for people who already have a 56 connected and using software pins, and want to upgrade kiln-controller. (And don't have a solder sucker.)

@captaincaden
Copy link

@chipgarner @rondoc for me, it was because the 31856 was the only one I could get ahold of when I started this project.

For the work around, I have a solder sucker, it would just take some time to disconnect everything to bring it back into my workspace to resolder. Not a super big deal, just can't get around to it in any quick fashion.

@rondoc
Copy link

rondoc commented Feb 15, 2023 via email

@jbruce12000
Copy link
Owner Author

blinka is now the main branch... which is set as the default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature help wanted Extra attention is needed in-progress
Projects
None yet
Development

No branches or pull requests

6 participants