FuckCombustion Community Enail Project (Name TBD)

[JCat]

@jojo monkey Now I feel stupid; I'll pick some up. Regarding the SSR, for now I'm trying to get as close as possible to the HexNail design for the sake of people who currently own the device. Making a better design is further down the road for me, but anyone else is welcome to pick it up. In regard to PCB mounts, pins are easy to add and dupont connectors are great. Right now I'm running almost everything through a breadboard; minimal wires. But yea, I agree that something with more integrity should be used once we're situated.

@JCat Did you try the official libraries from your controller manufacturer? One of the reasons I chose to get the Adafruit implementation of the 31856 is because they have a full and well-documented library for it. In regard to the in-between feature, that's exactly what hexnaild does. Additional factors are used to change interaction with the hardware. If that weren't the case, there would be no reason to have the SBC in the first place other than for graphical display and remote control. Not that that's a bad thing though; your suggestion to use a reputable controller such as from Omron and control it separately is definitely something to consider.

I'm very interested in what you have so far if you were willing to share with us. What were the shortcomings you noticed with the libraries you've used? Which have you used? Only official? Only community-lead? Considering how far SBCs have come as a separate platform from Arduino, I find it hard to believe that there still isn't a suitable solution. I will say that my HN-02 does a fantastic job of regulating temperature and doing programmed up/downtemps, regardless of the accuracy of the reported temperature.

I'm not sure if you have access to a HexNail image or not, but many python parts in /opt/enail/ are not compiled. The only reason I haven't uploaded them anywhere yet is because it is not licensed.

It's not a matter of the libraries ... all the sensors work perfectly. It's a matter of implementing the PID algorithm correctly.

The basic PID algorithm (from a calculus textbook) is essentially what the ArduPID library is (I've ported it to typescript as I don't want to work in python or C++! lol). I've also gone through C++ PID implementations, and read some textbooks; to implement basic PID is simple, to implement high quality PID where you minimize overshoot and undershoot (especially if using something like a D-Nail Halo setup w/ low thermal mass) is not simple at all. The Omron E5CC algorithm's are where that magic lies. I don't think it's a matter of the hardware being unable to keep up (although it might be in which case you would want to interface with an Arduino board of some sort to do the real time PID and communicate to it using the Pi), I think it's the software/algorithm implementation.

If someone that has extensive experience implementing PID algorithms could lend a hand, then we might be able to get this library to a state where it is close to as good as the Omron ... however, my initial trials I didn't even get it quite as good as the cheap Chinese PIDs

This is inline with what other have said in the HexNail thread though ... it was never superb at PID control, just feature rich; so depending on the nail you are using, it could actually be really bad at PID control ...

There are other considerations as well ...

- if we use the Pi to do the PID, and anything goes wrong (ie. something freezes/crashes in the software), the relay could be left "stuck" in an "on" state which would lead to the temp climbing to unsafe levels and the heater never turning off (running your nail, possibly a fire hazard).
- the 1st backup to this is to have a 2nd service running on the Pi to manage this, so if the main service crashes, the 2nd is monitoring the temp and shuts off the heater coil
- that being said, even with this backup, if the whole OS crashes at the wrong time, this danger is still there (and significant)
- in other words, with just the Pi to control it, it is DEFINITELY not safe for unattended operation.
- having the actual hardware PID there in between the 2 solves this danger

So ... from a safety perspective, as well as from a quality/performance perspective, that's why I abandoned this and have instead gone down the other path (ie. enhanced Omron E5CC ... my first version is just an "in-between" box for proof of concept more than anything else .. however, my next version will be with the Omron E5CC w/ RS-485)

I don't mind releasing the code for this like I said, it's actually on GitHub, but is a mess now as I abandoned it half-way into the Bluetooth implementation for the actual enail controller. For the enail magic I actually implemented the mobile app w/ Bluetooth connectivity ... although you can just run/monitor the profiles so far from the app ... you can't create/edit them)

I'm not sure the exact direction I am heading with the overall project ... I know I can't use my enail without enail Magic any longer now that I have it to run "scripts" for up-temps etc ... I may make a full enail controller for resale, or I may just make kits with open source (for non-commercial) licensing.

Once I get to the point of having a working prototype that I've been using for a while of the whole product, then I might make some others available for testing depending on interest and where other similar products are at ....

If the MaxVapor enail has similar features, might not be worth the time I would invest ...



Edit: One other comment as well ... there are lots of PID libraries to implement brewing systems, where it has to keep a tank of liquid at a stable temp ... this is MUCH different then controlling the temp on an e-nail ... this has a large thermal mass and response time is slow ... much different than an enail ...

 

[JigMelon]

@Elemen0py Believe me, there are various parts of this that I have minimal to zero understanding of, which is why I started the thread in hopes of having other contributors. If you can't tell from my postings thus far, circuitry is fairly new to me haha I'm probably just as "nooby" as you through some eyes. The cool part of having this be a community effort is that it's unlikely there's anyone who has vast experience in all involved fields; it's a great learning experience for everyone. Also, I'm just now realizing your name is LMNOP.

@JCat Thank you for the detailed explanation, and I completely agree with the safety concerns. I know this isn't the same as the failures you described, but I figured it's worth mentioning that HexNail has the heater ON by default in the configs on the device; I've changed mine to Off. When I first got my unit the first thing I did was set it up to be on 24/7 with the heater off so I could turn it on remotely from work. After a week I came home to a nail that had been hot all day....

I still plan on making a tutorial and SD image based on the original hardware, for now, but I'm very much interested in pursuing a configuration similar to what you described afterwards. You're reasoning is hard to disagree with!

In regard to time/money investment towards a commercial product/service, I won't comment on whether or not it's worthwhile, but I will say that my intentions (for now) is to make something that is easy to assemble by yourself, with off the shelf parts. Similar to the popular enail tutorials people have with standalone PID controllers. Even with the money I've spent on my hexnail and on parts and supplies for research with this project, I'm 100% buying a MaxVapor. I don't see any reason not to work toward a better product; it's just not something I have the time, money, or experience to do. Not to mention that this is still a relatively niche market, even with concentrates blowing up. Portable vaporizing tools are getting better every month, and there are some that give a better experience than our enails from only a few years ago. The market is growing, but not with connoisseurs. As long as the majority of the market is general consumers, it will always be flooded with products from companies with significant capital. I can't imagine MaxVapor business model being too lucrative either. Sustainable, sure.

Considering that you're a "free agent" and have first hand experience programming for PID control with this specific use case, you might even want to consider reaching out to MaxVapor with a resume! That being said, I'd much rather have you helping us here

@jojo monkey Question about thermocouple wire. I could probably just google this but meh. How do you get away with connecting the wire to the pots/post/terminal on the XLR connector? On my official unit, the terminals on the xlr port are not screws, and I doubt they're solely fastened with shrink tubing.

 

[JCat]

@JigMelon …. in regards to the default setting of off, that doesn't really solve the issue (although it's better )

To that end, I would also recommend a relay that is NO (normally open) as opposed to NC (normally closed).

Still doesn't solve the safety concern at all though. All it takes is a bug in the code, or a poorly timed failure on the part of OS, drivers, etc., etc., etc. and the relay could end up "stuck" in the closed position with the coil on and the entire system frozen and unresponsive (the steps I mention about having the secondary service, and the fact that it is a Linux box, a lot of this can be mitigated, but there will still be enough risk no matter what IMHO)

To continue that thought though, in order to best mitigate it, I would recommend a separate service that constantly monitors the thermocouple temp, say 5-10 second poling would be lots, and if the temp exceeds a max, the power to the relay (ie. the coil) is shut-off and the enail service is terminated forcefully. Similarly, if one fails to be able to read the thermocouple for a period of time, say 20-30 seconds, the same actions should be taken. Being that Linux is pretty damn stable, this would cover your bases the best you can in this situation …

When I considered actually building something, that I might send out to other people, I settled on the fact that I would almost certainly use a 3rd party PID controller in tandem … just not comfortable with the safety otherwise … could alternately build a separate dedicated PID controller that is guaranteed to be robust, and would consider that if I can get say an Omron PID chip that I can interface with or something of the like, but as I think about it, and the cost of an E5CC w/ RS-485, it just seems like the most cost effective solution will be integration with a known quality PID … to save $30-$40 max it just doesn't seem like something worth pursuing; anyways … I digress!

Anyways …. just thinking out loud on a lot of this stuff … I was building a PID controller on a Raspberry Pi a long time before Hexnail went belly up and I even knew they were using a Pi … I was actually assuming they were using something more robust after my experiences!!!! (or suspected that perhaps they were not and thus their issues with good PID control with many setups … PID control would be decent for instance on a VROD but would suck on a D-Nail Halo I imagine …. they might have done some fancy footwork in the code to "fake-out" the PID essentially … I had some success with this, but felt it was just so damn inelegant I didn't like it and felt if I really wanted to do it right I was going to need to read a couple entire textbooks on PID design, and spend at least a couple hundred hours doing prototyping and really truly understanding the engineering and calculus behind this …)

ie. it just seems like way less work to spend the $75 on the right PID to go with the project!

 

[Hippie Dickie]

i have some PID experience, but wildly different hw & sw …

It's a matter of implementing the PID algorithm correctly.

i had a breakthrough one day: when i was learning about PID, the way i read it, the error adjustment assumed two things - the heater response is symmetrical, and the error corrections were around duty cycle = zero. What i came to realize (a friend brought by some very nice herb) is that it is actually a non-zero value. What i mean to say, is that in a comic book world, there is a single duty cycle value (i call it the DCBIAS) that will maintain the temperature at the SETPOINT. And then, real world factors (dankness of load, speed of inhale, etc.) cause the error from SETPOINT. So the DCBIAS value is increased or decreased to compensate. it looked to me, from the PID algorithm, like the duty cycle value was calculating each cycle from DCBIAS = zero.

For the asymmetrical factor … the heater surface temp increases at 35F per second (full ON) and cools at 2F per second (full OFF). So my algorithm has two tables of coefficients - one for over temp and one for under temp … i am using tables so i don't have to do any fixed point math (the PIC12F683 doesn't even have a carry - just simple 8bit add/sub).

You probably already know all this - but in the hope of being helpful, there it is.

Question about thermocouple wire. I could probably just google this but meh. How do you get away with connecting the wire to the pots/post/terminal on the XLR connector? On my official unit, the terminals on the xlr port are not screws, and I doubt they're solely fastened with shrink tubing.

what i do is physically attach the thermocouple wire to a length of copper wire - twisted tightly and soldered. Then the other end of the copper wire is soldered to the pcb. Maybe you can get a terminal with screws - must be physically connected - solder won't stick to it. The nichrome ribbon is the same thing - that is, it needs a gas tight physical connection to a copper tail to attach to the pcb.

it just seems like way less work to spend the $75 on the right PID to go with the project!

my pcb parts are about $20 - for $17 more i can get it stuffed and soldered by machine - this is for 100 quantity. i can read the thermocouple 3 times per second. i have the main sw loop running @ 10 Hz - looking for button press and checking for errors, and every 300 msec it recalcs the duty cycle.

 

[brucee10]

- if we use the Pi to do the PID, and anything goes wrong (ie. something freezes/crashes in the software), the relay could be left "stuck" in an "on" state which would lead to the temp climbing to unsafe levels and the heater never turning off (running your nail, possibly a fire hazard).

My Hex-Nail does this. I've resorted to turning it off whenever I'm going to be away from it.

 

[PoopMachine]

Side tangent.. does anyone remember this website that sold this clunky blue metal enclosure enail that had all kinds of advanced features? It may have been what the MaxVapor morphed into but I remember the guy selling what looked like some custom hardware to interface with a Pi.

There is a link to it somewhere on this site but I cant seem to find it.

 

[jojo monkey]

@JCat Thanks for sharing all the roads you've taken and your ideas to make a better PID.

I'm interested in what you have going on during a session- second by second. Do you push a button and then you interrupt the power to the heater with the scripts? Have you ever compared your scripts to a measurement of the surface? There's got to be a bit of lag. Plus the temp probe takes 1-2 seconds to even register 80% of any change.

I'm am still going forward with trying a few python libraries. I like the idea of using python because there are many libraries and it is very readable.

The basic PID algorithm (from a calculus textbook) is essentially what the ArduPID library is

This guy updated it in 2011. Did you use that version? I have read the previous version was useless.
http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/
This seems like the right way to control the pid the way we want.
http://brettbeauregard.com/blog/2011/04/improving-the-beginner’s-pid-onoff/

my pcb parts are about $20 - for $17

Your kung fu is so strong. You really got that down!

I'm still in line for your vape.

 

[lazylathe]

Side tangent.. does anyone remember this website that sold this clunky blue metal enclosure enail that had all kinds of advanced features? It may have been what the MaxVapor morphed into but I remember the guy selling what looked like some custom hardware to interface with a Pi.

There is a link to it somewhere on this site but I cant seem to find it.

This one? Seems to be going nowhere fast....

http://fuckcombustion.com/threads/aertouch-tc-custom-pid-controller.24066/

 

[JCat]

@JCat Thanks for sharing all the roads you've taken and your ideas to make a better PID.

I'm interested in what you have going on during a session- second by second. Do you push a button and then you interrupt the power to the heater with the scripts? Have you ever compared your scripts to a measurement of the surface? There's got to be a bit of lag. Plus the temp probe takes 1-2 seconds to even register 80% of any change.

I'm am still going forward with trying a few python libraries. I like the idea of using python because there are many libraries and it is very readable.


This guy updated it in 2011. Did you use that version? I have read the previous version was useless.
http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/
This seems like the right way to control the pid the way we want.
http://brettbeauregard.com/blog/2011/04/improving-the-beginner’s-pid-onoff/


Your kung fu is so strong. You really got that down!

I'm still in line for your vape.

I'm not comparing to the surface temp (at least not more than I have out of curiosity to know the difference between the SiC dish temp and coil temp).

The readings in the enail magic device are consistent with what is displayed on the PID as they are both reading from the coil's thermocouple (using their own thermocouple amplifiers). I was initially concerned the TC wouldn't generate enough signal to be amplified to supply both or that interference would be an issue, but in actual usage I've found that it works perfectly fine and there are no issues with the dual readings.

I push a button, then it waits until the thermocouple reads a set temperature (or a set amount of time elapses, then it flips the switch). What I am doing is emulating what I was doing manually turning on/off the coil many times in a session (very, very awkward) to achieve exactly what I wanted. I'll try to do make a video later today ... I've had it running pretty much 24/7 for weeks on-end ... don't think I could do without it anymore!

I did look at all of those PID libraries ... I got "satisfactory" response from my PID implementation, but not great ... I may eventually revisit this, or if someone else lends a hand and does the PID implementation, then even better Just ordered myself an Omron E5CC-QX2ASM-802 though w/ the RS-485 that way I can read the temp, set-point, set the set-points, run the auto-tune, set the PID values, etc from the app and let the Omron do the heavy lifting in terms of PID control.

Cost for me was $100CAD (ie. <$80), and this was for a single unit. In volume I'm sure you could get this to <$50 (so again ... at this price difference I don't really see huge value in implementing ourselves ... would be nice if we could get the same PID with no buttons or screen, however, I haven't been able to find that yet

 

[jojo monkey]

@JCat

Thanks for writing all that up. I'm all for having a solution that currently exists... sounds like you created it! Super-fine control and predictable curves ramping up in temp. Nice. You also didn't have to tame pid settings to get the curves between temps that you want.

We should be able to do the same thing as your second box in code. Mr. B. Beauregard did the heavy lifting with the PID library.

That automatic/manual PID code will even do more than the two boxes. Instead of cutting off from one box to the other, the code blends two outputs to have a nice curve back to the set temp.

I think 3 parameters for a boost button can do it: A delay in seconds, % power, and duration in seconds. The delay would just run the automatic settings.

In my mind, it works something like...Find a base temp. Hit the boost button and the pid kicks into manual. Then it runs your settings and blends back to the base temp. Since the session is initiated by a button we can track things to help find a sweet spot. I think displaying the max temp during the manual session would be helpful. Maybe even the number of seconds until the peak temp from the button push.

I'm just tossing out ideas at this point.

 

[JCat]

@JCat

Thanks for writing all that up. I'm all for having a solution that currently exists... sounds like you created it! Super-fine control and predictable curves ramping up in temp. Nice. You also didn't have to tame pid settings to get the curves between temps that you want.

We should be able to do the same thing as your second box in code. Mr. B. Beauregard did the heavy lifting with the PID library.

That automatic/manual PID code will even do more than the two boxes. Instead of cutting off from one box to the other, the code blends two outputs to have a nice curve back to the set temp.

I think 3 parameters for a boost button can do it: A delay in seconds, % power, and duration in seconds. The delay would just run the automatic settings.

In my mind, it works something like...Find a base temp. Hit the boost button and the pid kicks into manual. Then it runs your settings and blends back to the base temp. Since the session is initiated by a button we can track things to help find a sweet spot. I think displaying the max temp during the manual session would be helpful. Maybe even the number of seconds until the peak temp from the button push.

I'm just tossing out ideas at this point.

Yeah ... I already spent a bunch of time with that library specifically (I converted it to typescript, but that's the one I used). Works wonderfully for something like a brewing system, not so good for a d-nail halo ... (not bad, just not great ... and the Omron is "great" ...)

The plan isn't to have 2 boxes, the plan is to have 1 box but use the E5CC-QX2ASM-802 in conjunction with a Pi Zero W to make a complete system. That's another factor ... if one needs to go from a Pi Zero W to a Pi 3B+ to handle the extra processing load, then that also jumps the cost by ~$30 as the Pi Zero W is super cheap ... like $10 without the pre-soldered header.

Edit: I'm not saying that this is the best or only way to go, just the path I am going down right now, as after my time spent on PID + the nagging thoughts concerning safety that are alleviated largely by going this route ... + the minimal cost difference ... these are all reasons weighing in to my decision.

If someone else wants to work on the PID control separately, and gets something that performs even close to as good as the Omron, I'd be seriously interested (this would be on either an Arduino, a Raspberry Pi, whatever ... whether the code is in python, c#, typescript, c++, ultimately it's the algorithm that we need. (I can read it in whatever language it is written in, or for that matter the algorithm is simply written out in pseudeo code type form--or as a process flow--with all the math as well, then that would work too)

The issue I have, is that I've tried both versions of the Beauregard code, plus variations on it, plus completely other implementations, and none of them have satisfactory performance IMHO. (that being said, it is possible there was a mistake in my code somewhere ... @Hippie Dickie 's comments would be worth considering and taking a closer look at the DCBIAS and how it comes in to play ... it's also worth noting though that I don't think a table type approach works here as it doesn't account for an infinite number of variations of heaters and mass that can be connected ... the curves and response times of different enails, bangers, etc are significantly different, and thus it's important to be able to have profiles with different PID settings, and also optimal if one can "auto-tune" these settings.

On another note, I did also implement a few variations of auto-tune libraries, with some success, but ultimately not even close to as good as what the Omron does

I'm thinking it would be nice to be able to call on the Omron auto-tune when one connects a new device, then once it's done, save that device "profile" so next time you connect it you just load the PID settings as opposed to having to enter or re-auto-tune.

Ultimately, the only real downside to using the Omron is that it has a UI that I don't really want (as I need my own screen anyway for additional functionality, so this means it's just extra hardware that takes up space and isn't really necessary). ie. the whole device could be a little smaller if we didn't have the buttons and screen on the E5CC.

Anyways ... rambling as usual!

 

[JigMelon]

I'm going to step away from that conversation; looks like @JCat and @jojo monkey know what they're talking about. Thank you for sharing your research and insight with us; it's very valuable to the success of this project.

Regarding my silly wiring issue, i got some 14 gauge wire to replace the flimsy wire I was using, heat-shrink tubing, and 10 yards of k-type wire! I'm going to rewire everything tonight and/or tomorrow and I'll let you know the results.

As soon as I have a full DIY setup working, I'm going to get started on controlling hexnaild without their AWS server. I completely agree that this project should use a more-reputable PID controller and control that with the SBC, rather than controlling PID with the SBC, but I'm still committed to coming up with a solution for current HN-02 owners, as it is immediately useful to myself. Also, I have a USB-TTY dongle now for when we get to the discreet PID stage. I won't be very helpful in programming in the event that we don't find a suitable implementation (whether it uses python or not doesn't matter ultimately; we should keep researching pre-existing solutions before we start working from scratch, unless someone with the know-how is volunteering to do so), but I will be able to provide logs/feedback if anyone works on that.

Sorry for the radio silence; it's been a busy work week and I stepped away from personal projects.

 

[Hogni]

Easy, pal! You've all the time you need - and more!

Thanks so much for your efforts

 

[JigMelon]

Easy, pal! You've all the time you need - and more!

Thanks so much for your efforts

Thank you, but I would say that @JCat and @jojo monkey and @Hippie Dickie have arguably contributed more effort than myself, even if it wasn't initially intended for this specific project. Like I've said in the past, Linux is my specialty and much of this project will require assistance from others in the community. I'm really glad to see that others with professional experience have taken an interest in this!

 

[Hogni]

For sure they are very important for this project but you are the founder of this project and are making an - unnecessary, IMO - excuse

 

[JCat]

I'm going to step away from that conversation; looks like @JCat and @jojo monkey know what they're talking about. Thank you for sharing your research and insight with us; it's very valuable to the success of this project.

Regarding my silly wiring issue, i got some 14 gauge wire to replace the flimsy wire I was using, heat-shrink tubing, and 10 yards of k-type wire! I'm going to rewire everything tonight and/or tomorrow and I'll let you know the results.

As soon as I have a full DIY setup working, I'm going to get started on controlling hexnaild without their AWS server. I completely agree that this project should use a more-reputable PID controller and control that with the SBC, rather than controlling PID with the SBC, but I'm still committed to coming up with a solution for current HN-02 owners, as it is immediately useful to myself. Also, I have a USB-TTY dongle now for when we get to the discreet PID stage. I won't be very helpful in programming in the event that we don't find a suitable implementation (whether it uses python or not doesn't matter ultimately; we should keep researching pre-existing solutions before we start working from scratch, unless someone with the know-how is volunteering to do so), but I will be able to provide logs/feedback if anyone works on that.

Sorry for the radio silence; it's been a busy work week and I stepped away from personal projects.

I can help w/ giving you a working UI likely (can be run from SSH console) to get the basic PID functionality. I had something basically working in this regard for my initial prototyping ... if I can find the time in the next month or two I'll stub out the UI w/ a PID interface and a PID library or 2 that can be interchanged for use with the UI/application.

This way, one would have a working piece of software that could read the thermocouple and control the heater duty cycles and plug in different PID libraries that are implemented according to a specific interface ... ie. implement a single typescript class that inherits from the base PID class and you can then just change a line in the config file to use the new library. This would allow others with experience w/ PID algorithms, and knowledge of typescript to implement their own PID libraries ... perhaps someone will implement a real winner!

Edit: I've been playing around with some different development paradigms, applying non-standard patterns to server/device type code like this, with great results as it very specifically addresses the concerns that are present in regards to concurrency in these types of systems. ie. I'd rather re-write the server/console UI piece of the code, without the socket.IO and bluetooth initially, using this paradigm as it will give a stable base to start building from.

Anyways .... really got to get back to work ... but nice morning diversion ... ...

 

[Hippie Dickie]

it's also worth noting though that I don't think a table type approach works here as it doesn't account for an infinite number of variations of heaters and mass that can be connected ... the curves and response times of different enails, bangers, etc are significantly different, and thus it's important to be able to have profiles with different PID settings, and also optimal if one can "auto-tune" these settings

absolutely agree. my PID is tuned for my geometry. one problem i had initially was using large values for the adjustment coefficients - fairly small values are adequate in my case. my PID was tuned for a 0.5 ohm wire coil and the ribbon coil is 0.35 ohm - much hotter/faster, but even without adjusting the values i see +/- 0.5F stability. blows me away.

it should be easy to read the response of the coil and adjust the parameters automatically - maybe sprinkle in a little AI.

i have one self-adjustment that runs during a session: every 5 seconds i check to see if the last 15 temp measurements had a positive or negative error and bump the DCBIAS down or up by one.

 

[GOD710]

Nice one dude!

 

[JCat]

absolutely agree. my PID is tuned for my geometry. one problem i had initially was using large values for the adjustment coefficients - fairly small values are adequate in my case. my PID was tuned for a 0.5 ohm wire coil and the ribbon coil is 0.35 ohm - much hotter/faster, but even without adjusting the values i see +/- 0.5F stability. blows me away.

it should be easy to read the response of the coil and adjust the parameters automatically - maybe sprinkle in a little AI.

i have one self-adjustment that runs during a session: every 5 seconds i check to see if the last 15 temp measurements had a positive or negative error and bump the DCBIAS down or up by one.

Maybe once I have the time to put together the shell of the software, you can share your algorithm with me and I can post it to a typescript implementation for use in this e-Nail

 

[jojo monkey]

The issue I have, is that I've tried both versions of the Beauregard code

I dunno. A bit over a year ago I explored making a PID for custom flower rig. I used a teensy and the arduino library and it worked. The rig used a pt100 probe inside a 4mm ID tube near the heater. Not much mass at all and I used the fastest pt100 probe on mouser.

If I am reading right, your argument is that the pid library cannot maintain the temp of a small device. I will be sure to explore this with a coil. I'm used to heating glass and that is sloooow to warm up. It is easy to overshoot with slow things too.

If the PID tuning can't do it alone, I think some overshoot logic like a couple PID's for coils use or just run the heater at a % power and let it go stable. Either way, the manual boost button would be the predictable way to climb in temp since it bypasses the PID. It should be easier to mess with a boost button settings than PID settings to get nice curves.

The omron you listed measures 20 times a second, but by default displays 4 times a second (but is still measuring fast). The omron also has a rolling average turned on by default. So there is some smoothing going on if you were just looking at the display with the defaults. (Do we want smoothing?)

 

[JigMelon]

Haven't read anything since I last posted pretty much so I don't have comments on anything (yet). Can someone take a look at this and tell me where the hell I'm going wrong?

https://image.ibb.co/mP9JeU/WP_20181007_10_05_32_Pro.jpg
https://image.ibb.co/d19jKU/WP_20181007_10_05_11_Pro.jpg
https://image.ibb.co/hy6Ltp/WP_20181007_10_04_32_Pro.jpg
https://image.ibb.co/f74JeU/WP_20181007_10_04_12_Pro.jpg

I rewired everything, used thick copper wire, all terminals are separated by some form of insulation, thermocouple wiring from the TC chip's screw terminals to a physical solderless bond to the copper wires connected to the XLR cups. I'm still getting a red coil. I'm sure this is just the result of ignorance but I'm stumped. Also, no glue

 

[sarkunit]

Hey everyone, I just noticed this thread and would like to offer my help with anything I can help with. I have a degree in controls, and am very familiar with programming discrete closed loop controllers for industrial applications. I can do raw z transforms, modeling, and many other heavy math and physics related work. I wish I was better with circuit design, but I am no help there

 

[Hippie Dickie]

I'm still getting a red coil.

what is the thermocouple reading?

 

[JCat]

I dunno. A bit over a year ago I explored making a PID for custom flower rig. I used a teensy and the arduino library and it worked. The rig used a pt100 probe inside a 4mm ID tube near the heater. Not much mass at all and I used the fastest pt100 probe on mouser.

If I am reading right, your argument is that the pid library cannot maintain the temp of a small device. I will be sure to explore this with a coil. I'm used to heating glass and that is sloooow to warm up. It is easy to overshoot with slow things too.

If the PID tuning can't do it alone, I think some overshoot logic like a couple PID's for coils use or just run the heater at a % power and let it go stable. Either way, the manual boost button would be the predictable way to climb in temp since it bypasses the PID. It should be easier to mess with a boost button settings than PID settings to get nice curves.

The omron you listed measures 20 times a second, but by default displays 4 times a second (but is still measuring fast). The omron also has a rolling average turned on by default. So there is some smoothing going on if you were just looking at the display with the defaults. (Do we want smoothing?)

I’m not saying it can’t be done, I’ve argued that as one of the concerns why I stopped going down that route and have instead opted to go down the route of controlling the omron (safety being one of the largest factors ... that and not wanting to reinvent the wheel ...). I’m not arguing that it can’t be done ...

I’ve also indicated I’ll assist in writing the code to help get everyone up and running, and do so in a fashion as to make the PID implementation be “pluggable” so we can try different implementations.

I can also assist in translating any algorithm that someone with the engineering but not software expertise wants to try.

I just likely don’t have time to commit to this for a month or two though ...

Ideally if we could get an implementation that works as well as the Omron, than we could shift our focus on adding the required circuit/software to make it 100% safe.

 

[JigMelon]

what is the thermocouple reading?

In the hexnail app it isn't reading. How do I go about checking? I've been pulling my hair out trying to get max31856 examples compiled/running on the device but pretty much everything I've found is made for Arduino or RasPi. I'm wondering if I should abandon the OPi and pick up a RasPi3B...