DennisFlonasal
FUDless
omg what do I need to sacrifice to get on the list??? these types of units intimidate me but this one does not!!
SixStringToker
Naked member
I received some goodies today...
Uhhhg. I really hate uploading images to this forum; had to edit this photo 5 times to find a size the forum would accept. Mods, please enable Xenforo's automatic image resizing!
Uhhhg. I really hate uploading images to this forum; had to edit this photo 5 times to find a size the forum would accept. Mods, please enable Xenforo's automatic image resizing!
DennisFlonasal
FUDless
put this on my tombstone lmao i struggle with this more than anything on this site, see so many things i want but you can't just buy them
Aero
Raw Addict
There is a lot of ways to get a lot of things...
my sub/supreme is second-hand in a new shape, the glass symphony is buildable. also, there is a cool guy who is making very nice wood handles called iDB I snapped 4 different handles and a full set for my FP sow go ahead and buy some before this cool idea will vanish also.
I tried to get Jcat to answer me on Pm sow I can buy his enail and maybe heat-treated plates for my supreme sow it will give my supreme some color and look less like an improvised explosive device.
I'm currently lurking after a custom berserker but those dudes all the time moving from place to place sow its god damn hard to make an order from them.
I need one of these in my life how do I buy one? Take my money!Here's a picture of the 2nd box; the joinery wasn't perfect on the last one, and this bothered me A LOT. So I built a 2nd copy fixing my mistakes from the 1st (and I bought a better 1/2" router bit for the box joints so that I get a nice clean cut)
If my dust collection for my CNC router comes at some point, and some 1/16" bits for the slot, I'll be all set and will be able to do this much quicker (probably still looking at an hour a box by the time you account for sanding and everything ... + at least another hour for assembly, and similarly the face/back plates will go faster once I have dust control on the CNC ... so I don't have to stand over it vacuum in hand ......)
FYI--it's all black knobs from now on ... just my stock of them is arriving tomorrow (prefer the look of the black over the chrome but chrome was all I had left for the picture...)
To everyone that has requested to get on the "list", I will reach out to you at some point, as I work through requests in order.
This is just a little side project for me, and the little I make per unit only makes it worth my while because I want to get these into the hands of other individuals simply because I love this project so much (however, they are not really profitable per say as I make much more--ie. 2-6x as much per hour--doing pretty much anything else ... ... )
I haven't decided when I will start the next batch, nor how many will be in it, but as soon as I do I will reach out.
Thanks everyone for the encouragement and patience
This is just a little side project for me, and the little I make per unit only makes it worth my while because I want to get these into the hands of other individuals simply because I love this project so much
(however, they are not really profitable per say as I make much more--ie. 2-6x as much per hour--doing pretty much anything else ... ... )I haven't decided when I will start the next batch, nor how many will be in it, but as soon as I do I will reach out.
Thanks everyone for the encouragement and patience
DennisFlonasal
FUDless
completely understandable! my own impatience is no ones issue but my own lmaoTo everyone that has requested to get on the "list", I will reach out to you at some point, as I work through requests in order.
This is just a little side project for me, and the little I make per unit only makes it worth my while because I want to get these into the hands of other individuals simply because I love this project so much
I haven't decided when I will start the next batch, nor how many will be in it, but as soon as I do I will reach out.
Thanks everyone for the encouragement and patience
SixStringToker
Naked member
This baby is going to be a permanent part of my coffee table setup.
No issues or questions so far? Everything running smoothly? Glad to hear you're liking it!
SixStringToker
Naked member
I'm taking notes as I think of things so that I can smack you with everything at once.
It's been running like a champ. Rock-solid stability with my V-Rod and a 25mm coil. There was a bit of instability with the Elev8r, but I only spent a short period of time with that setup.
cosmicrhino
New Member
I'm also very interested in getting on a list!
Beyonder420
Well-Known Member
I'm in Canada, have a really good aluminum case I could use, spare PIDs (so no fear of tinkering), a few coils, and I don't mind soldering, but I haven't got any Pi experience or parts, so I'm wondering how hard this would be to first expand to dual coil control, and then perhaps eventually add DC output as well, all off the Pi?
@Texus you are on the list now
@Beyonder420 ... that's an involved post to answer ...
As far as PIDs go, the only PID supported is the Omron E5CC-QX2ASM-802 with the RS-485 communication. (the RS-485 communication being the key); other PIDs could theoretically be supported by writing an interface assuming the PID had a communication port and API (could be RS-485, could be serial, could be TCP/IP or whatever), as long as it has a robust/responsive one available. Integration to support an alternate PID, as long as it had all the required features available in it's API, would likely be relatively straight forward.
For supporting dual coil, that would be a whole other matter. It would involve separating out the server code to be able to manage 1 to N instances of the PID, and then some method to switch the controls from 1 PID to the next. The server side API apart from the main controller would also have to be extended to support this, as well as the client. I would estimate that this would be a minimum of 100-150 hours of development time but likely more, as the changes would be so drastic as it would likely be easiest to essentially just do a full rewrite, re-using all the code where possible. Although likely 80% of the code would be re-usable, you would have to touch most of it to parameterize appropriately and to handle switching inputs/outputs, and to handle the multiple RS-485 input.
You could approach this in 2 ways ... a) support 1-to-N PIDS. b) create 2 static versions that support either 1 or 2 PIDS.
Option b) would be easier, but more costly to maintain as one would then be maintaining 2 codebases moving forwards. Option a) would be a better implementation, but the dynamic nature of it would be more involved/complex and thus would take longer.
It's unlikely I will get to this, but by all means if you are a proficient developer feel free to dig in! (If I was to do this for a customer, I would bill this work out at $20-$30k )
Edit: @Beyonder420 , the one other way to maybe add dual support with minimal coding changes, would be to simply have a switch where the software would control/read 1 PID or the other; but the key being only 1 at a time. You could then chain together 1-to-N PIDS without issues, and you would just "select" which PID you wanted to control/monitor. You could even easily add a few multi-PID features such as TURN OFF ALL ... and maybe slowly integrate some multi-PID features.
Now that I think about it ... the RS-485 interfaces just daisy chain together, so 2 possibilities on if then slowly adding multi-PID support would work:
1) You quickly call setID([id of Omron RS-485]) for each PID, and then read the required registers (temp, state, etc.). This would need to occur every 1 second at the most. So the question would be if you can switch and read this frequently without causing issues with the interface or the Pi (if the Pi gets overloaded upgrading to a Pi4 vs. the little Pi Zero would solve that ... or even better I might eventually design a board that you can "slot" a Pi compute module 4 into).
2) You only read the 1 PID frequently, and the other doesn't get monitored (this would likely be ok for the most part ... as you likely only want to monitor/control one at a time apart from maybe the basics like auto-shutoff and being able to power-on/off all, but maybe not read the state and temp of each PID every second, maybe read the "state" of the currently controlled PID every 0.5-1s and then read the state of the other PIDs say every 15-30 seconds, to manage things like auto-shutoff.
Some interesting thoughts anyways! If only I could see a real business model for these at a decent scale, I could dedicate more time, but the reality is I just don't see it (I'm already I would guestimate $75-$100k in the hole as far as invested time on this project ...! ... however, have a lot of fun building this vs business software, or industrial monitoring and control systems! ... so as long as I look at it as a hobby I've just spent a lot of time building myself a REALLY fancy tool for vaping my concentrates!)
@Beyonder420 ... that's an involved post to answer ...
As far as PIDs go, the only PID supported is the Omron E5CC-QX2ASM-802 with the RS-485 communication. (the RS-485 communication being the key); other PIDs could theoretically be supported by writing an interface assuming the PID had a communication port and API (could be RS-485, could be serial, could be TCP/IP or whatever), as long as it has a robust/responsive one available. Integration to support an alternate PID, as long as it had all the required features available in it's API, would likely be relatively straight forward.
For supporting dual coil, that would be a whole other matter. It would involve separating out the server code to be able to manage 1 to N instances of the PID, and then some method to switch the controls from 1 PID to the next. The server side API apart from the main controller would also have to be extended to support this, as well as the client. I would estimate that this would be a minimum of 100-150 hours of development time but likely more, as the changes would be so drastic as it would likely be easiest to essentially just do a full rewrite, re-using all the code where possible. Although likely 80% of the code would be re-usable, you would have to touch most of it to parameterize appropriately and to handle switching inputs/outputs, and to handle the multiple RS-485 input.
You could approach this in 2 ways ... a) support 1-to-N PIDS. b) create 2 static versions that support either 1 or 2 PIDS.
Option b) would be easier, but more costly to maintain as one would then be maintaining 2 codebases moving forwards. Option a) would be a better implementation, but the dynamic nature of it would be more involved/complex and thus would take longer.
It's unlikely I will get to this, but by all means if you are a proficient developer feel free to dig in! (If I was to do this for a customer, I would bill this work out at $20-$30k
)Edit: @Beyonder420 , the one other way to maybe add dual support with minimal coding changes, would be to simply have a switch where the software would control/read 1 PID or the other; but the key being only 1 at a time. You could then chain together 1-to-N PIDS without issues, and you would just "select" which PID you wanted to control/monitor. You could even easily add a few multi-PID features such as TURN OFF ALL ... and maybe slowly integrate some multi-PID features.
Now that I think about it ... the RS-485 interfaces just daisy chain together, so 2 possibilities on if then slowly adding multi-PID support would work:
1) You quickly call setID([id of Omron RS-485]) for each PID, and then read the required registers (temp, state, etc.). This would need to occur every 1 second at the most. So the question would be if you can switch and read this frequently without causing issues with the interface or the Pi (if the Pi gets overloaded upgrading to a Pi4 vs. the little Pi Zero would solve that ... or even better I might eventually design a board that you can "slot" a Pi compute module 4 into).
2) You only read the 1 PID frequently, and the other doesn't get monitored (this would likely be ok for the most part ... as you likely only want to monitor/control one at a time apart from maybe the basics like auto-shutoff and being able to power-on/off all, but maybe not read the state and temp of each PID every second, maybe read the "state" of the currently controlled PID every 0.5-1s and then read the state of the other PIDs say every 15-30 seconds, to manage things like auto-shutoff.
Some interesting thoughts anyways! If only I could see a real business model for these at a decent scale, I could dedicate more time, but the reality is I just don't see it (I'm already I would guestimate $75-$100k in the hole as far as invested time on this project ...!
... however, have a lot of fun building this vs business software, or industrial monitoring and control systems! ... so as long as I look at it as a hobby I've just spent a lot of time building myself a REALLY fancy tool for vaping my concentrates!)
Last edited:
Beyonder420
Well-Known Member
With the baller mods causing the flowerpot to become more popular, the demand for an excellent PID is spiking up a bit, and yet still not likely to support the effort involved in marketing this grade of controller. But there are some national legalization efforts that could change things in a hurry?Now that I think about it ... the RS-485 interfaces just daisy chain together, so 2 possibilities on if then slowly adding multi-PID support would work:
1) You quickly call setID([id of Omron RS-485]) for each PID, and then read the required registers (temp, state, etc.). This would need to occur every 1 second at the most. So the question would be if you can switch and read this frequently without causing issues with the interface or the Pi (if the Pi gets overloaded upgrading to a Pi4 vs. the little Pi Zero would solve that ... or even better I might eventually design a board that you can "slot" a Pi compute module 4 into).
Some interesting thoughts anyways! If only I could see a real business model for these at a decent scale, I could dedicate more time, but the reality is I just don't see it (I'm already I would guestimate $75-$100k in the hole as far as invested time on this project ...!
I would say there's hurdles both on the front and the back that would lead me to wanting n support of PIDs with each one simply adding to a list of displays on the main page that scrolls. Clicking a PID in the list brings up more details/controls for that PID and the backend just cycles through the list to fetch updates?
If you haven't picked up the itch for a dual zone heating then you are likely in a better place. Just another monkey on the back?
The only clever thought is that with support for multiple outputs, the cost of the box suddenly starts being very price competitive with multiple separate PIDs.
Beyonder420
Well-Known Member
I am pretty new to the pi/arduino scene but it looks like a fancy little $7 load cell micro-sensor hooked to a $4 HX711 amplifier is all that is needed to put a gram sensitive scale on top of this controller?
The value of a dabbing device that can do a weight read is probably mild, most people would think the proposal is strictly limited to a cleaner footprint/less clutter for your dab station, but I bet JCat can immediately think of ways to exploit it.
I've been polishing up a software project, that I promised Troy from 420 VapeZone I'd skin with a custom theme and publish on his website. The project is nearly code-complete but I have to admit it would actually be greatly enhanced by getting communication from the enail, even without the scale, but more so with it.
We could discuss it a little more in PMs if this is something you would want to explore/would embrace some extra interest? Seems like your have a good queue building so far?
The value of a dabbing device that can do a weight read is probably mild, most people would think the proposal is strictly limited to a cleaner footprint/less clutter for your dab station, but I bet JCat can immediately think of ways to exploit it.
I've been polishing up a software project, that I promised Troy from 420 VapeZone I'd skin with a custom theme and publish on his website. The project is nearly code-complete but I have to admit it would actually be greatly enhanced by getting communication from the enail, even without the scale, but more so with it.
We could discuss it a little more in PMs if this is something you would want to explore/would embrace some extra interest? Seems like your have a good queue building so far?
moechtegern
Well-Known Member
So this is for enails only, or could I control my Vapbong/Herborizer with this?
Beyonder420
Well-Known Member
Right now the software is managing a 120v AC Omron temperature controller but it would not be impossible to make the software more modular so it can manage a mosfet driver module for variable DC output.
In fact this means there's potential to be able to ask a home assistant service to power up your vapbong/set the power levels by voice, or even have a schedule/smart trigger built into a service like IFTTT?