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

PlatformIO, Code cleanup, safety, and facilities for inverting the fan/SSR outputs #12

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

fake-name
Copy link

@fake-name fake-name commented Sep 28, 2020

I put together a little hacked up board running this for reflow purposes.

It's quite nice, but there's a fair number of things I didn't like. This is basically my improvements:

  • Build with PlatformIO (because the arduino editor + 2 macro buttons is terrible).
  • Add facilities for inverted fan control/ssr outputs.
  • Expose inverted outputs in settings
  • Fix all warnings on build.
  • General code cleanup and formatting (mostly astyle)
  • Use actual, proper enums for state, so there's not mystery numbers everywhere
  • Reformat reflow profiles so they don't need messy run-time definition (and can be extended a lot easier).
  • Handle open/broken thermocouple. Right now, you can still start the oven with no thermocouple connected, and it'll turn the heaters on full for at least a few seconds before noticing anything is wrong. I'm not sure if there's an error state that can make the returned voltage too low (a short outside the oven?), but that'd be worth checking for as well. Checking that the heater control signal effects the read-back temperature is a known and reliable safety measure in 3D printers, it'd possibly be worth considering here.
  • Reduce oven SSR PWM frequency. If your oven SSR is triac based, a high PWM frequency means you have almost no control of actual power at low duty cycles, as the triac latches for an entire 1/2 the AC waveform. That means that you can never reduce the power lower then ~5/6 of full power, since with a 748 hz PWM frequency, there are ~6.2 PWM pulses per AC half wave.
    Generally, there's no good reason to PWM at more then a few hertz, since the thermal mass of the oven will probably result in response bandwidth on the order of many seconds.
  • Collapse giant if-else statements into case statements (this is why C has case statements!).
  • Typos! (currentDetla? Probably more)
  • Maybe: Most ILI9341 screens have optional touch-screens (including the one I have). Maybe use that?
  • Maybe: Move all the state-machine globals into a single struct/class?
  • Maybe: Add facility for a door opener (often done with a simple R/C servo.
  • Maybe: Right now, when the millis() rolls over, things will probably break in some manner. This can be solved by treating time as a unsigned int and only ever computing relative time deltas, but switching the current system to that will require careful checking.

This is WIP, but I think most of it is valuable. Using PIO for building is particularly useful since it means multi-platform builds (such as #3) would be much easier.

Mostly lots of unsigned/signed comparisons, and removed `char* string2char(String command)` because it was an abomination.
…gic numbers everywhere.

Also, add facilities for managing inverted-output fan/SSR signals.
@UnexpectedMaker
Copy link
Owner

Oh hey, this is awesome! But it seems we've clashed :)

I have a v1.09 that already has a bunch of what you have listed implemented... not all though and no platform.io support.

My v1.09

  • moved all states to enums
  • thermocouple error tracking with on screen feedback and reflow blocking if no TC detected
  • some code cleanup (variable spelling, code formatting etc, better use variable types)

v1.09 is already going to customers on current Reflow Masters I am shipping

I also have a v1.10 in dev that has more changes and new features.

So I'm not going to be able to merge this PR - at least not until after my new changes are here.

Unfortunately I have no ETA on that right now as I am swamped with other work.

@fake-name
Copy link
Author

That makes sense, though I can rebase off of whatever branch is preferred.

Is there a dev branch somewhere?

@UnexpectedMaker
Copy link
Owner

That makes sense, though I can rebase off of whatever branch is preferred.

Is there a dev branch somewhere?

No dev branch on github, sorry. I usually only push to github when I'm happy with the release.

@fake-name
Copy link
Author

That seems like the canonical purpose of having a dev or wip branch.

@UnexpectedMaker
Copy link
Owner

Well, I don't release every code version to the public, so not really.
I had a few people make competing products and ship them with my code, so I'm much more cautious now about if and when I make updates public these days.

@fake-name
Copy link
Author

fake-name commented Sep 29, 2020

That kind of seems like it's not open source at that point.

Anyways, is there any chance you could plonk stuff up somewhere so I don't wind up duplicating work that's already been done? I'm at the point where I'm trying to get my DIY oven going, and have time to spend on helping out/improving the code at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants