# Specific 3D Printers, Scanners, & Hardware > Peachy Printer Forum >  Drip Governor - A most valuble first hack

## rylangrayston

Having used the peachy printer alot, I think one of the most  valuable hacks That almost everyone will want is some way to  automatically speed up and slow down the drip feed in the peachy  printer. Id love to include such a feature in every kit 

but as of now it looks like it will have to be an add on. 



An auto governed dripper would improve 4 situations that really slow down the printing process.


1.  If you have a 1000 layer print and 999 of your layers take 1 second to complete 

but  one of the layers takes 1 minute, then optimal your print could take  1059 seconds, however with out changing your drip speed dynamically  during the print 

you will have to wait one min in between  all the 1 second layers just so you will have time to print the 1 min  layer when you get to it. This makes printing without dynamic drip speed  take 999 * 60 + 60 = 60000 seconds. This is bad because in this example  you wait 16 hours for a print that could have taken 17 minutes with a  dynamic drip rate ( of course this is and extreme situation but you get  the point  :Smile:  


2.  Setting the drip speed really slow  and just leaving the printer over night can simply result in the drip  feed randomly stopping all together. 


3 Changing the drip rate by hand works great, until you bump the printer because 

its hard to stay focused on such a simple task for hours of time, time which is better spent ells ware 


4. The size of a drip gets bigger when dripping very fast compared to very slow 

we  can account for this by measuring the time between drips but It would be  better if we could avoid the slow dripping range entirely. 




There  are lots and lots of ways you could govern drips but since the printer  costs so little iv been trying to find an ultra inexpensive drip  governor.  Ive been thinking about it for about 9 months now and Im  finally starting to like one of my ideas on this topic.. so tonight  while waiting for prints to finish i wiped up this little animation:







Important points

- The tapered points glued to ether end of the magnet would have just the right density to float the magnet in salt water


- The entire moving part would be dipped in enamel to prevent corrosion.


- The hope is that you could charge a capacitor and give each coil a pulse causing the printer to drip rapidly or not at all. 


- The pules to the coils could be followed by some small holding current 



- the wedge shape on the open end is important to help the moving part stick in place

- The flow of the water is typically very very slow not enough to push the moving part around 


-  If a magnet as apposed to a soft iron core is used its  possible to  pulse both coils at the same time (one pushing and the other pulling)


- The peachy software and hardware will be developed specifically to make it easy to add such modifications. 


- When held vertical the floating magnet would sink indicating that your printer needs more salt. 


- it seems quite likely that this could be further modified to be a pump.


I may work on this soon as it would really help the peachy team print faster. 


Ill probably just drive mine with an Arduino sending codes over the serial port to open the drip governor 

when ever the print is less that 5 drips ahead of the current layer. 


Im also very interested in a pump that can do really repeatable pulses of water. 


This is a great project for those of you that are dieing to work on the peachy printer before you get it!


Some points of importance in making a great drip detector are

- low cost 

-  the hole assembly must be air tight from top to bottom as to maximize  siphon and stop bumbles from pushing into the bottom resivior 

- drips must make clean and reliable contact between microphone input wires.



Well if i do get time to work on this ill be sure to post my results here

hope you will do the same  :Smile: 


Rylan Grayston

----------


## mike_biddell

Rylan............. love the idea........... the drip from your valve could be software demanded, without the use of arduino. You simply have a light dependent resistor or photocell at a know location on the side of the tank and above the resin. This location would be known and calibrated. Every time the software wants a drip, it would switch the laser off, move the galvos, so the laser pointed at the LDR/photocell and then switch the laser on. This pulse of light could be used to switch a transistor on to deliver the current to your valve. You could demand a number of drips, one after the other by pulsing the laser on and off if required, or demanding a single drip...... it's totally flexible. This solution requires no digital components, just a single transistor and LDR and a reserved switching location in 3d space. The software would have a demand drip function, which would handle firing at the ldr on the side of the tank. The only parameter you would pass is number of drips required (demand-drip(n)).

----------


## mike_biddell

Forgot to say, if the valve works reliably, there would be no need for the microphone input. The software would simply count the demands it has made. The demand-drip circuit could replace the mic input conditioning circuit.

----------


## Pete

Been thinking about this too Rylan and as you know with my solution I pretty much get extra free control and feedback mechanisms, although there might be a simple hack for the basic printer in here somewhere.

So most pumps seem pretty useless for salt water and on Friday I had an idea and went for it.
IMG_20140308_174318.jpg
This is basically a, badly built, piston pump using a reciprocating servo and a syringe. Generally pumps would have two one way valves so that you get a metered dose each stroke. I actually wanted to have two controllable valves so that i could add extra to the print side and then take it out again to get over this surface tension/flowing issue . I might finish this off, surprisingly controlling it over 20 cycles I got within a few % of my expected volume (although this was a fag of set position move pipe set position move pipe between reservoirs since I don't have any valves yet [Could have 3d printed a couple!]) 
I'm thinking on the fly here but for the basic you could implement this with two 555 timers and an opto feedback which would replace the drip feedback to the sound card (just happens each drip is a pretty mega one!). 
I can't find any reasonable price looking commercial pumps like this....suggestions anyone?

Another Idea that I had last night is to use a peristaltic pump. These are often used to dose fish tanks but essentially mean that the fluid your pumping only ever is contained in a silicone pipe. I've ordered one of these. Again I would like to be able to pump both ways and I was thinking opto or reed switch to sense the rotor arm, like the above this gives much larger 'drips' but I imagine you could sacrifice some of your Z resolution? This could also be added to the basic, I imagine that this could be hooked directly to the USB (you could even control on and off with a similar laser control circuit) and again feedback to the mic port, although the flow rate on some of these pumps might be good enough just to add a timer in software (this seems to be how they're used in fish tanks).

----------


## Slatye

Pete - I think that what you require is a diaphragm pump (this is pretty much what you've built, except that the pump would include two one-way valves). They're very good at handling relatively nasty liquids (like salt water) and each cycle should give a constant amount of water (depending largely on how consistent the one-way valves are).

eBay has such things very cheaply. The challenge with these ones is that there's no feedback of any sort - you don't know how many cycles it's done. If there's just a cam on the end of the motor shaft then it should be simple to replace that with a servo (as per your design) which gives perfect feedback. There might be a nice analogue way to integrate this, but (as always) I'd just stick an STM32F0 in there and call it finished. In this system I'd also need two pumps, since they're not reversible - one to transfer water from the source container to the printing container, and one to handle surface tension issues.



With that said, I can see the attraction of Rylan's design. A pump would give you direct control over the water level but often that's not actually the best approach. The direct electromagnetic valve approach seems fairly simple and is definitely mostly analogue, which would make integration easier.

----------


## Feign

Another possibility is to have the flow rate set manually very high, and have a solenoid valve before that that listens to the printing output for the 'laser on' signal and shuts off the flow when the laser is on for more than a few hundredths of a second (to keep it from fluttering while the laser is rapidly turning on and off to make a multi-line image.)

Making sure to have a simple "laser is on" signal output from the Peachy would make this (and other hacks/accessories) even easier, since other devices wouldn't have to listen to the signal from the computer that way.

----------


## nka

Electronic valve seems the best way to go for it. But I would keep the mic input to monitor if everything goes as it should.

----------


## Feign

I agree on keeping the mic monitor, since the computer needs some kind of feedback on the z-position.

Having an additional on/off valve would benefit from the valve itself listening to the drip sensor as well as the "laser on" signal, so it can simply cut the water off if the laser is "on" for more drips than it would take for one layer (or one sublayer) until the laser is "off" again for long enough to indicate that the sublayer is done.  Just having "Laser On" equal "Valve Off" is a pretty simple way of doing things on the hardware side, but it would slow down prints during simple layers, though .

----------


## harpo99999

back during the ks for the peachy, I had an idea somewhat similar to rylan's, BUT using the mass/weight of the magnet/seal to close and a electromagnet to open the valve by drawing the magnet (in the top part of the valve) toward OR away from vertical thereby opening the valve

----------


## rylangrayston

Hey everyone, Im a bit pressed for time today.. so sorry in advance for the short reply's. 

here we go 
@Mike_biddell 
Great Ideas .. quite possibly part of what could make it low cost enough  to be a part of the peachy basic, be sure to post your hack if you  build it! You will likely pave the way for many others!
The drip governor is my aim at doing it super low cost, pumps will most  likely be the answer for the pro.

@pete
Nice work! take a look at the valve i made below .. i think it would act  as a nice Super low pressure one way valve simply using gravity  instead of a spring.
I like the idea that the pump could be help the surface tension issue...  we plan to do this in the pro! Thanks for the link to the pump they look  great so im purchasing a few now  :Smile: 

@Slatye 
Those pumps look great also .. again possibly exactly what we need for  the pro, we could simply put a photo interrupt on the back end of the  motor and use and interrupt pin on a micro to count how many cam pulses  the pump has done.

@Feign 
Right not only is the circuit easy to listen in on its also easy to  control, we are breaking out important wires like that into terminal  headers and solder pads. 
We are doing this specifically to encourage hacks, the peachy printer  isnt just open its actually designed to be hacked.  and on that note .. I  did get a few hours to work on my version of the drip governor hack...  so here are some pics!

20140308_200509.jpg
20140308_200550.jpg
20140310_134749.jpg


also here is a python script: 



```
import serial

import time
connected = False
ser = serial.Serial("COM4", 9600)



while not connected:
    serin = ser.read()
    connected = True


for i in range(0,300):
    print (ser.outWaiting())
    print (ser.inWaiting())
    try:
        ser.write("1")
    except ser.SerialTimeoutException:
        print('gerr')

    print('wrote1',i)
    time.sleep(1.5)
    try:
        ser.write("0")
    except ser.SerialTimeoutException:
        print('gerr2')

    time.sleep(1.5)
    #ser.flushInput()








#while ser.read() == '1':

#    ser.read()



ser.close()
```

and an arduino script that the python script talks to over serial


```
// Open a serial connection and flash LED when input is received
int led = 13;
int on = 2;
int off = 3;
int onTime = 400;
int pulseValve = 10;
char code = '0';
int powerTime = 500;


void setup(){
  // Open serial connection.
  Serial.begin(9600);
  pinMode(13, OUTPUT);
  Serial.write('1'); 
  pinMode(led, OUTPUT);    
  pinMode(on, OUTPUT);
  pinMode(off, OUTPUT);
  pinMode(pulseValve, INPUT);
  
}


void testValve(){
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  digitalWrite(on, LOW);
  digitalWrite(off, HIGH);
  delay(powerTime);
  digitalWrite(off, LOW);
  


  delay(2000);
  
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  digitalWrite(off, LOW);
  digitalWrite(on, HIGH);
  delay(powerTime);
  digitalWrite(on, LOW);


  delay(2000);
  }
  








void loop(){ 
  //Serial.write(2);
  
  if (digitalRead(pulseValve) == HIGH){
  testValve();
  }
  
  
  if(Serial.available() > 0){      // if data present, blink
  code = Serial.read();
  
  if (code == '1'){
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  digitalWrite(off, LOW);
  digitalWrite(on, HIGH);
  delay(powerTime);
  digitalWrite(on, LOW);
  //Serial.write(1);
  }
  
  if (code == '0'){
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  digitalWrite(on, LOW);
  digitalWrite(off, HIGH);
  delay(powerTime);
  digitalWrite(off, LOW);
  //Serial.write(0);
  //delay(onTime);               // wait for a second
  }
  }
}
```


ok that code is rather ruff, its just an excerpt from my playground branch.. Townly is making it into a proper class right now. 
Soon you will just be able to script the printer like this
dripGovernor.stopDripping()
dripGovernor.startDripping()


Ill be making some major improvements to this .. 
- change to a single coil driven by an h bridge reversing the power to  the coil turn the valve on and off.( use a stopper to keep the magnet  alwase off center of the coil so the coil alwase pushes it in one  direction. 
- make the hole thing smaller
- machine the moving pin with a lathe then use the machined pice to  and make a mould to cast the magnet into the pin 
- reduce the hose length between the driper and the governor valve to increase the responsiveness of the system. 
- use clear plastic for all outer components ( easier to see what happens when it stops working) 
- change from 34 gage wire to 36 or 38 gage wire, ( reducing the current required to do the same work with everyting on a smaller scale ) 
- adjust the size density of the moving part so its the same density as saturated salt water

looking forward to seeing all the different ways there are to govern dripping!
Im sure some of the best ways to do it will be a combination of all the posts here.

----------


## Anuvin

I think this hack is fun because there are lots of ways to pull it off, I suspect. I started work on one too, here are some pics.
CAM00083.jpg
My casting setup, with megablocks, clay, and a magnet. This cast failed, it needed to be larger. Setup is the same though.

CAM00086.jpg
Successful casts with flash still on.

CAM00087.jpg
Trimmed, and you can see the magnet through the plastic a little. I will be coating it in silicone sealant, so it's cool.

I'll get some pics of the housing when its done, hopefully tomorrow.

----------


## Pete

> Pete - I think that what you require is a diaphragm pump


Sold!




> The challenge with these ones is that there's no feedback of any sort - you don't know how many cycles it's done.


I assume these are going quite fast, I'll find out soon enough, couldn't we just use the mic input as a mic, quick FFT and then you have pump frequency....?




> With that said, I can see the attraction of Rylan's design. A pump would give you direct control over the water level but often that's not actually the best approach. The direct electromagnetic valve approach seems fairly simple and is definitely mostly analogue, which would make integration easier.


I'm open to this but I'm still not convinced...I was playing with water in a tube the other day to sense drips (turns out saltwater gives nicer pulses than tap water but surprisingly not because it's more conductive [I'll post some captures later in the week]). I'm concerned having done this that pressure may have more to do with flow rate in a drip system than a valve, if you take the original concept of reservoir on top of reservoir then the head changes constantly throughout the print and could be siginificantly different at start and end. I don't know if this is solved if the head is >>higher than the print but then I imagine this would be more of a flow valve than drip governor?

----------


## mike_biddell

Light Dependent Resistor   Electric Circuit.png
Here's the circuit for a light activated switch, just substitute Rylan's valve in place of the LED and 500R. With this solution, the Peachy Basic can be part of the variable z resolution revolution. All you have to do is fire the peachy laser at the LDR and the transistor turns on and operates the valve. This could be an optional extra for the basic. It could plug into a socket on the peachy to supply 5v for the rail (therefore no additional power required, it wud only take a few milliamps from the rail) and Rylan's valve and could be sold as a 'variable z add on'

----------


## rylangrayston

Wow

great work everyone! 

ok so in testing the design i had posted last we have found some major problems.
It did work great for a short time here are a list of problems we had:

- it got gummed up by resin and or salt
- it required about 400 mA to work reliably ( way to much power)
- its rather large 
- the relays in the circuit combined with the coils were creating a very strong radio wave ( from the spark gap ) and 
caused the serial port to time out! (ugg this took a while to figure out!!)

We are just attempting to do some larger prints and so this drip governor could be really valuable to that end.
So me and Erik took some time the other night working on new hardware for this hack

Erik has one that's almost done hopefully he will post some pics of it here tonight. 

I went into my head for a few hours and came up with a design with the following features in mind

- much lower power required  ( more efficient use of the magnetism )
- super easy to take apart and clean 
- easy to make with a stack of rings cut out by the laser cutter
- moving part needs to be guided very well
- very small and inexpensive in volume 
- use power mosfet instead of relays ( works great!)
- move to an H bridge, revesing polarity on the coil. 

here are my blend files and i wipped up another animation  ... 
https://github.com/Rylangrayston/Ran...drip%20govener






My next step is to make this same design in open s cad, with the intention of cutting it out of a stack of disks and rings on the laser cutter. 
if that docent work well I may just make it on my metal lathe for now. 

Speaking of which dose anyone here use open s cad ?
We could alwase use help coding highly parametric designs ! 
esp for hacks like this. 

@Pete 
I thought the salt water was better because it was more conductive .. tell me more! What is it about salt that makes the pulses better!
although i must say this topic may need its own thread. Also yes your on to something ... we have noticed that the size of a drip grows by 30 percent 
as the drip frequency goes from 1 drip per second to about 5 drips per second. We doubt that this is linear and it needs much more testing before
we can do a good job of accounting for it. luckily we know the drip frequency, and if the frequency stays the same then the drip size is very stable. 
so it looks like a very solvable problem. 


@Anuvin 
great stuff, if i make one on the lathe ill def use your lego casting idea to make a few more!! very cool, plus its something i can do with my son
Any thing to do with lego and he is in! I think if we made a Lego spoon he would eat broccoli with it lol. 

@Mike_Biddell 
So simple, just love it, how about using a power mosfet to replace the transistor you used and then also adding a capacitor to its gate so when the switch gets a short pulse of light 
it charges the cap quickly which holds the mosfet on for a few seconds. That way the peachy can ask for say 10 drips at a time, and spend very little time on the LDR.

----------


## mike_biddell

Rylan, power mosfet is good. The switch could be an adjustable 3 stage mono-stable as you suggest. Coarse, medium and fine.  Just set the monostable to the required setting before you start the print. The time constant for the capacitor would be set by switching between 3 resistors. The laser wud then just fire at the LDR and move on. The monostable wud hold on the FET for the required time (drips). Or a 555 timer could be used.

----------


## nka

Could also be turned on by laser and off by the drip sensor. So, when the laser target the LDR it's turn on, then we wait for "X" drips to turn it off again.

If we use an ajustable valve, we could also use the laser to ajust speed... everytime the laser hit the LDR, the valve open a little more. Every drip, she's closing a little, so if you want to have it stable, you hit the LDR one time each drip, if you want +1, you need to hit the LDR 2 time on a drip. Dont know if this could be viable, since I didnt saw how fast the drip goes and how fast the LDR react.

----------


## mike_biddell

Sebastian, you are correct, there are many possibilities with a light operated switch. LDRs are so cheap, you could have more than one

----------


## rylangrayston

hmm ya I think nka is on to something too 

how about 2 LDRs ,  shinning on LDR1 turns the dripping on, Shinning on LDR 2 turns the  dripping off... with a setup like that the printer can chose exactly how  many drips it wants with two quick flicks of the laser beam

Mike do you know how to make a switch like that? 
If you post a circuit diagram and ill try it out,  all tho it might take me a week as Im away from the shop right now.

----------


## rylangrayston

ok so progress is coming along nicely on the openscad version 
of that last animation i posted.. 
Screenshot.jpg
I did the hole thing in modules of rings and discs that can be cut with the laser cutter 
and the hole thing is almost completely parametric, with parameters for 
everything at the top.


All that's left to do is a bit of clean up as well as finish the laserCutterLayout() module 
so that all the pieces can be exported to dxf for laser cutting.

Open s cad is a way to program or code objects instead of draw or model them 
like you would in a conventional program like blender or cad. 
You can grab it here:
http://www.openscad.org/

Note, I did implement an animation in open s cad , just click view --> animate 
to play with it. 
here is the open S Cad code!
Copy paste it into openscad and enjoy  :Smile: 



```
 // ID and OD stand for inside and ouside diameter
 

 explodeDistance = 1;// 1+5*$t;
 split = 3;//1+1*$t;
 

 IDClearTubing = 4;
 wallThickness = 1+1*$t;
 tubingConnectorLength = 9;
 

 magnetThickness = 3;
 magnetOD = 6;
 

 coilWidth = 3;
 coilID = 4;
 coilOD = 8;
 

 pinOD = 1;
 pinLength = 10;
 pinThickness = .5;
 

 flowHoleID = 1;
 flowHoleOffset = 2;
 

 valveORingID = 3;
 valveORingOD = 4;
 valveORingThickness = (valveORingOD-valveORingID)/2;
 

 housingORingID = magnetOD+1+.5;
 housingORingOD = housingORingID +1;
 housingORingThickness = (housingORingOD-housingORingID)/2 ;
 

 outerORingGap = .5;
 

 

 

 

 module tubingConnector()
 {
     difference()
     {
         cylinder(tubingConnectorLength,IDClearTubing,IDClearTubing,center= true);
         cylinder(tubingConnectorLength+1,IDClearTubing-wallThickness+1,IDClearTubing-wallThickness+1,center = true);
     }
 }
 

 module magnet()
 {
     color("green",.9)
         cylinder(magnetThickness,magnetOD,magnetOD, center = true);
 }
 

 module pin()
 {
     color("purple",.9)
         union()
         {
         cylinder(pinThickness,magnetOD,magnetOD, center = true);
         translate([0,0,pinLength/2])
         cylinder(pinLength,pinOD,pinOD,center = true);
         }
 }
 

 module pinAndFlowHole()
 {
     cylinder(10,pinOD,pinOD,center = true);
     translate([flowHoleOffset,0,0])
         cylinder(10,flowHoleID,flowHoleID,center = true);
 }
 module coilSpoolWall()
 {
     difference()
     {
         color([0,1,0,0.5])cylinder(wallThickness,coilOD,coilOD, center = true);
         pinAndFlowHole();
     }
 }
 

 module coilSpool()
 {
     union()
     {
         coilSpoolWall();
         translate([0,0,wallThickness/2+coilWidth/2])
         {
             difference()
             {
                 color([0,0,1,0.8]) cylinder(coilWidth,coilID,coilID, center = true);
                 pinAndFlowHole();
             }
             translate([0,0,coilWidth/2+wallThickness/2])
                 coilSpoolWall();
             
         }        
     }
 }
 

 

 module valveORing()
 {
     difference()
     {
         cylinder(valveORingThickness+wallThickness,valveORingOD,valveORingOD, center= true);
         //cylinder(100,valveORingID,valveORingID,center= true);
     }
 }
 

 

 module inerFacePlate()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness,magnetOD+1+wallThickness,center= true);
         pinAndFlowHole();
         valveORing();
     }
 }
 

 module outerFacePlate()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness+wallThickness, magnetOD+1+wallThickness+wallThickness, center =true );
         pinAndFlowHole();
         
     }
 }
 

 

 module housingORing()
 {
     difference()
     {
         cylinder(housingORingThickness+wallThickness,housingORingOD+wallThickness,housingORingOD+wallThickness, center= true);
         cylinder(8,housingORingID,housingORingID,center= true);
     }
 }
 

 

 

 module housingORingSeat()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness,magnetOD+1+wallThickness,center= true);
         cylinder(wallThickness+1,magnetOD+1,magnetOD+1,center= true);
         //pinAndFlowHole();
         housingORing();
     }
 }
 

 module inerHousing()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness,magnetOD+1+wallThickness,center= true);
         cylinder(wallThickness+1,magnetOD+1,magnetOD+1,center= true);
         
         
     }    
 }
 

 module outerHousing()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness+wallThickness, magnetOD+1+wallThickness+wallThickness, center =true );
         cylinder(wallThickness +1, magnetOD+1+wallThickness+outerORingGap, magnetOD+1+wallThickness+outerORingGap, center= true);
     }
 }
 

 module assemble()
 {
     tubingConnector();
     translate([0,0,tubingConnectorLength/2+wallThickness/2*explodeDistance])
     
     coilSpool();
     translate([0,0,tubingConnectorLength/2+wallThickness*2+wallThickness/2+coilWidth*explodeDistance])
     {
        inerFacePlate();
         translate([0,0,wallThickness*explodeDistance])
         color("red",.5)housingORingSeat();
         translate([0,0,wallThickness*2*explodeDistance])
         inerHousing();
 

         translate([0,0,wallThickness*3*explodeDistance])
         {
             inerHousing();
         }
         translate([0,0,wallThickness*3*explodeDistance+split/2])
         {
             magnet();
             translate([0,0,magnetThickness/2+pinThickness/2])
             pin();
 

             rotate([0,180,0])translate([0,0,magnetThickness/2+pinThickness/2])
             pin();
         }
 

 

         translate([0,0,split])
         {
             translate([0,0,wallThickness*4*explodeDistance])
                 outerHousing();
             translate([0,0,wallThickness*5*explodeDistance])
                 outerHousing();
             translate([0,0,wallThickness*6*explodeDistance])
                 outerFacePlate();
             translate([0,0,wallThickness*7*explodeDistance])
                 coilSpool();
             translate([0,0,(wallThickness*8+wallThickness/2+coilWidth+tubingConnectorLength/2)*explodeDistance])
                 tubingConnector();
         }
 

         //translate([0,0,housingORingThickness+10])
             //housingORing();
         //translate([0,0,housingORingThickness+6])
             //    magnet();
     
     }
 }
 

 

 module laserCutterLayout()
 {
     translate([20,0,0])
     tubingConnector();
     translate([20,0,0])
     magnet();
 }
 

 laserCutterLayout();
 assemble();
```

----------


## mike_biddell

Rylan, it occurs to me that we could simply use one LDR as a toggle switch. So fire laser and valve is on, fire laser at same ldr and valve is off. I can think of two solutions, one using a 555 timer and the other using a picaxe 08m.  The 08m is cheap, about £2 sterling, but an advantage of using it as a toggle switch, is that it could also provide the scanner drive for the Peachy basic, with few additional components (maybe none). Plus you can change the behaviour of the circuit just by re-programming it (it is therefore more flexible). But I'll try to find time today, to put the circuits into my simulator and get them both working that way. If they work in the sim, they work in real life.

----------


## mike_biddell

peachy2.jpg
Have completed the PICAXE version of the light switch. All of it is completely alterable by changing the software. Runs great in the simulator................ it's a dynamic simulator and altering the LDR above and below a threshold switches the relay on and off alternately. Pushing the mode select push button turns the relay OFF and generates a nice little square wave which would drive the mirrors for scanning. Pushing the button again, puts it back into drip-valve mode. The PAUSE statements in the software will need altering to suit the real setup. The chip is programmed using a serial link. The transistor and relay can be replaced with a FET switch circuit of your choice. The software follows:-

low 0                'initialise outputs to OFF
low 4
main:
readadc 1, b1                'read value on pin 1 into variable b1
if b1 > 100 then         'if laser pointing at LDR
pause 1000 
goto onoff            'turn the drip valve ON
endif                        
if pin3 = 1 then         ' if button pressed scan-mode required
goto scanmode
endif         
goto main                

onoff:                
high 2                'turn transistor ON
readadc 1, b1             'check if laser is demanding OFF
if b1 > 100 then          'only exit this loop if laser fires again
pause 1000
low 2                'turn transistor OFF
goto main
endif   
goto onoff            ' back around if no OFF signal from laser

scanmode:
pause 2000             'wait to prevent bounce
low 2                ' make sure drip valve is OFF
high 4                ' set mirror squarewave drive on pin 0
pause 100            ' alter this to suit the mirror slew rate
low 4                ' mirror square wave 0
if pin3 = 1 then 
pause 1000
goto main    'exit scanmode if mode pushbutton pressed
endif
goto scanmode

----------


## mike_biddell

peachy555-1.jpghere's the 555 light toggle switch. Just substitute a FET of your choice and the valve as load on pin 3 in place of the 2n2222. This circuit also works well in the simulator. Unfortunately the allowed file sizes are rather small. so it's only just legible. Compared with the first circuit, it's completely analogue.

----------


## rylangrayston

Perfect!
Thanks Mike!!

I plan to give them a try soon!

----------


## rylangrayston

Ok 
I got the open scad of the o-ring valve done ( or close enough to try it)

here are some pics

Screenshot-1.jpgScreenshot-2.jpg


a few notes 
- By placing a soft iron washer on the inside of each coil wire the moving magnet should stick to ether the closed position or the open position with no current.
In other words only a pulse of current is needed to switch the valve, after which no holding current is needed. 
- The hole valve can be cut out of disks of plastic on a laser cutter or cnc router, each disk being stacked and glued to the next, making this a very hackable valve.
- I attempted to make everything driven by the variables at the beginning of the file, you can change things like magnetOD, wallThickness, TubingID etc.
alto i can see a few places that need improvement here. 
- The hole thing can be cut out of clear acrylic allowing you to see the valve operate.
- the valve splits in 2 at the centre for easy cleaning.
- the valve coils should be wound or wired in oposite directions and wired together in series.
When driven with and h bridge they should push and pull on the magnet alternately.
So forward current looks like this    SN  >-ns->  NS
and revers current looks line this    NS  <-ns-<  SN
Where the capitals are the coils and lower case is the magnet.

Here is the new code!!




```

 // ID and OD stand for inside and ouside diameter*** Ops all D should be R for  radius!! my bad.
 

 explodeDistance = 1;// 1+5*$t;
 split = 3;//1+1*$t;
 laserCutterBuffer = 1;
 

 IDClearTubing = 4;
 wallThickness = 3;//+1*$t;
 tubingConnectorLength = 9;
 

 magnetThickness = 3;
 magnetOD = 6;
 

 coilWidth = 3;
 coilID = 4;
 coilOD = 8;
 

 pinOD = 1;
 pinLength = 10;
 pinThickness = .5;
 

 flowHoleID = 1;
 flowHoleOffset = 2;
 

 valveORingID = 3;
 valveORingOD = 4;
 valveORingThickness = (valveORingOD-valveORingID)/2;
 

 housingORingID = magnetOD+1+.5;
 housingORingOD = housingORingID +1;
 housingORingThickness = (housingORingOD-housingORingID)/2 ;
 

 outerORingGap = .5;
 

 

 

 lt3 = 0;
 lt4 = 0;
 

 

 

 

 module tubingConnector()
 {
     difference()
     {
         cylinder(tubingConnectorLength,IDClearTubing,IDClearTubing,center= true);
         cylinder(tubingConnectorLength+1,IDClearTubing-wallThickness+1,IDClearTubing-wallThickness+1,center = true);
     }
 }
 

 module magnet()
 {
     color("green",.9)
         cylinder(magnetThickness,magnetOD,magnetOD, center = true);
 }
 

 module pin()
 {
     color("purple",.9)
         union()
         {
         cylinder(pinThickness,magnetOD,magnetOD, center = true);
         translate([0,0,pinLength/2])
         cylinder(pinLength,pinOD,pinOD,center = true);
         }
 }
 

 module pinAndFlowHole()
 {
     cylinder(10,pinOD,pinOD,center = true);
     translate([flowHoleOffset,0,0])
         cylinder(10,flowHoleID,flowHoleID,center = true);
 }
 module coilSpoolWall()
 {
     difference()
     {
         color([0,1,0,0.5])cylinder(wallThickness,coilOD,coilOD, center = true);
         pinAndFlowHole();
     }
 }
 

 

 module inerCoilShaft()
 {
     difference()
     {
         color([0,0,1,0.8]) cylinder(coilWidth,coilID,coilID, center = true);
         pinAndFlowHole();
     }
 

 }
 

 module coilSpool()
 {
     union()
     {
         coilSpoolWall();
         translate([0,0,wallThickness/2+coilWidth/2])
         {
         inerCoilShaft();
             
             translate([0,0,coilWidth/2+wallThickness/2])
                 coilSpoolWall();
             
         }        
     }
 }
 

 

 module valveORing()
 {
     difference()
     {
         cylinder(valveORingThickness+wallThickness,valveORingOD,valveORingOD, center= true);
         //cylinder(100,valveORingID,valveORingID,center= true);
     }
 }
 

 

 module inerFacePlate()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness,magnetOD+1+wallThickness,center= true);
         pinAndFlowHole();
         valveORing();
     }
 }
 

 module outerFacePlate()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness+wallThickness, magnetOD+1+wallThickness+wallThickness, center =true );
         pinAndFlowHole();
         
     }
 }
 

 

 module housingORing()
 {
     difference()
     {
         cylinder(housingORingThickness+wallThickness,housingORingOD+wallThickness,housingORingOD+wallThickness, center= true);
         cylinder(8,housingORingID,housingORingID,center= true);
     }
 }
 

 

 

 module housingORingSeat()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness,magnetOD+1+wallThickness,center= true);
         cylinder(wallThickness+1,magnetOD+1,magnetOD+1,center= true);
         //pinAndFlowHole();
         housingORing();
     }
 }
 

 module inerHousing()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness,magnetOD+1+wallThickness,center= true);
         cylinder(wallThickness+1,magnetOD+1,magnetOD+1,center= true);
         
         
     }    
 }
 

 module outerHousing()
 {
     difference()
     {
         cylinder(wallThickness,magnetOD+1+wallThickness+wallThickness, magnetOD+1+wallThickness+wallThickness, center =true );
         cylinder(wallThickness +1, magnetOD+1+wallThickness+outerORingGap, magnetOD+1+wallThickness+outerORingGap, center= true);
     }
 }
 

 module assemble()
 {
     tubingConnector();
     translate([0,0,tubingConnectorLength/2+wallThickness/2*explodeDistance])
     
     coilSpool();
     translate([0,0,tubingConnectorLength/2+wallThickness*2+wallThickness/2+coilWidth*explodeDistance])
     {
        inerFacePlate();
         translate([0,0,wallThickness*explodeDistance])
         color("red",.5)housingORingSeat();
         translate([0,0,wallThickness*2*explodeDistance])
         inerHousing();
 

         translate([0,0,wallThickness*3*explodeDistance])
         {
             inerHousing();
         }
         translate([0,0,wallThickness*3*explodeDistance+split/2])
         {
             magnet();
             translate([0,0,magnetThickness/2+pinThickness/2])
             pin();
 

             rotate([0,180,0])translate([0,0,magnetThickness/2+pinThickness/2])
             pin();
         }
 

 

         translate([0,0,split])
         {
             translate([0,0,wallThickness*4*explodeDistance])
                 outerHousing();
             translate([0,0,wallThickness*5*explodeDistance])
                 outerHousing();
             translate([0,0,wallThickness*6*explodeDistance])
                 outerFacePlate();
             translate([0,0,wallThickness*7*explodeDistance])
                 coilSpool();
             translate([0,0,(wallThickness*8+wallThickness/2+coilWidth+tubingConnectorLength/2)*explodeDistance])
                 tubingConnector();
         }
 

         //translate([0,0,housingORingThickness+10])
             //housingORing();
         //translate([0,0,housingORingThickness+6])
             //    magnet();
     
     }
 }
 

 

 

 

 

 module layoutSpoolAndConnector()
 {
     for (i = [0:1:2])
     {
         translate([-i*(IDClearTubing*2)-i*laserCutterBuffer,0,0])
         tubingConnector();
     }
 

     
     translate([0,IDClearTubing+coilOD+laserCutterBuffer,0])
         coilSpoolWall();
     translate([-(coilOD*2+laserCutterBuffer),IDClearTubing+coilOD+laserCutterBuffer,0])
         coilSpoolWall();
     translate([0,IDClearTubing+coilOD*2+coilID+laserCutterBuffer*2,0])
         inerCoilShaft();
 }
 

 

 

 

 module laserCutterLayout()
 {
 //projection(cut = false)
 //    {
         translate([40,0,0])
         {
         
 

             layoutSpoolAndConnector();
             translate([0,40,0])
                 layoutSpoolAndConnector();
             translate([25,0,0])
             {
                inerFacePlate();
                 translate([0,(magnetOD+1+wallThickness)*2,0])
                     color("red",.5)
                         housingORingSeat();
                 translate([0,(magnetOD+1+wallThickness)*4,0])
                     inerHousing();
 

                 translate([0,(magnetOD+1+wallThickness)*6+laserCutterBuffer,0])
                 {
                     inerHousing();
                 }
 

 

 

                 translate([25,0,0])
             {
                 outerHousing();
                 translate([0,(magnetOD+1+wallThickness+wallThickness)*2+laserCutterBuffer,0])
                     outerHousing();
                 translate([0,(magnetOD+1+wallThickness+wallThickness)*4+laserCutterBuffer*2,0])
                     outerFacePlate();
             
             }
         }
 

 

     }
 //    }
 

 }
 

 laserCutterLayout();
 assemble();
```

----------


## erikk

Here's the design I made and tested yesterday. (It does something but not as well as I had hoped)

This picture is only missing the coil (the coil really blocks the view):
DSCF2849.jpg

The magnets push an aluminum tube that slides into a tight fitting larger aluminum tube. When they are overlapped enough there is a hole in the outer tube that gets blocked, closing the valve.

Closed:
DSCF2850.jpg
Open:
DSCF2851.jpg

The tubes fit surprisingly well but do not give you a full seal when closed. I was expecting that with a difference in restriction between open/closed, I could tune down the flow with a second valve until closed means almost no drip, and open is a decent speed drip. 

As it turned out, when I turn the other valve down to the point where the closed position stops dripping, it doesn't get much more drips on the open position. I had to leave the other valve completely open and adjust the height of the reservoir until I found a spot where open means a fast drip and closed means a steady drip, barely on the slow side. It might be useful for some prints, or maybe there is a way to tune it better. But for now I'm looking at other designs and I'll keep you guys updated.

----------


## mike_biddell

Rylan , forgot to say, for the double coil design, you need to use a relay for output, with one coil across the N/O contacts and the other across the N/C contacts.

----------


## mike_biddell

It occurs to me that if we had a spring loaded valve (a cone shape with a soft iron pole piece and behind  it a single coil, so that the coil pulls the soft iron against the spring and the cone away from the seal) so that 0 current is zero flow, we could have a variable flow rate in addition to ON/OFF. The first picaxe circuit I posted could accomplish variable flow using the PWM output to drive the coil. A small voltage just cracks the valve open, and full voltage opens it fully. The flow rate could be set by the laser pulsing on and off with say 0.5 second pulses. The picaxe would count the pulses so that 1 pulse just cracks the valve and 10 pulses opens it fully. Hold the laser on for greater than 1 second would close the valve and reset the valve count. In this way, we could demand ON and OFF and the flow rate. This could all be accomplished with the first circuit I posted with a software change and a couple of tweaks.

----------


## erikk

A couple more designs, one worked for a while until the coil broke unexpectedly

#1
DSCF2859.jpg
The water comes in from the back, just off the centre (the aligning pin that attaches to the magnet needs to be centre). 

The orientation of the valve lets gravity hold the magnet off of the o ring while its  flowing, until you pulse the coil to get the magnet to stick to  the o ring. The flow direction sucks the magnet to the o ring, so it stays until you pulse the coil in the opposite direction to open it again.
DSCF2860.jpg
The parts: (they're not exactly right but close):
DSCF2863.jpg
The coil/magnet wasn't being used as efficiently as it could, so it will  hopefully use less power. (this one took 15V and 0.5A) Although this  was only a pulse to get it to go from open to closed and vise versa. But  the next one I tried pushing the limits of low power.

#2
DSCF2866.jpg
This one uses a piece of sheet plastic that bends onto an o ring to seal. The coil makes the magnets push onto the sheet to break the seal. This one didn't seem to have enough pressure from the flow to hold it shut consistently, but when I helped it seal, the coil pushed it open with 5V 0.17A.

I'm hoping a larger o ring will get more force to hold it shut, or maybe I just need to get the sheet positioned better.

----------


## cephdon

Wow, I like the ideas presented in this thread.  One thing I can't help but consider is that the peristaltic pump could be modified to use a stepper motor and we could eliminate the need for drips and mic inputs. A 32x or 128x microstepping driver with a sufficiently small step size motor would provide more than enough resolution.  You could then just drive the pump to increase the water height as much as you like.  It should be pretty precise since you can control the exact number of steps and therefore the exact volume of water that is pumped from the reservoir to the 3d printing tank. 

It just seems to me that having a pump controlled by stepper eliminates much of the uncertainty of drip speed, timing, etc.

----------


## mike_biddell

> Wow, I like the ideas presented in this thread.  One thing I can't help but consider is that the peristaltic pump could be modified to use a stepper motor and we could eliminate the need for drips and mic inputs. A 32x or 128x microstepping driver with a sufficiently small step size motor would provide more than enough resolution.  You could then just drive the pump to increase the water height as much as you like.  It should be pretty precise since you can control the exact number of steps and therefore the exact volume of water that is pumped from the reservoir to the 3d printing tank. 
> 
> It just seems to me that having a pump controlled by stepper eliminates much of the uncertainty of drip speed, timing, etc.



Great idea, I do believe I could do micro-stepping from my light switch picaxe circuit, without to many additional components

----------


## rylangrayston

@cephdon and @mike_biddell    I Think that a stepper / encoded motor and a pump is almost certainly a better way to do it, however at peachy we must also focus on a method that is inexpesive enught to have a chance at making it into the basic 100 dollar kit, thus the focus on a simple valve system. 

Well hopefully "pictures are more than words" works for this post. 
I spent quite a bit of time at the lathe today, here are some pics, ill explain more after i have tested these new parts.

The openscad code comes to fruition( it worked! but needs modification to work under syphen presure)
20140315_175758.jpg 20140316_014036.jpg 20140315_012144.jpg 20140315_012248.jpg

----------


## rylangrayston

And a new small one done in aluminum:

20140315_202600.jpg 20140315_203902.jpg 20140316_020726.jpg 20140316_020928.jpg


Great Work Everyone!!

----------


## mike_biddell

It is easy to get carried away and forget this has to sell at $100. If we set the valve to have a relatively high flow rate, retain the drop count system, and use the laser to turn the valve ON and OFF (555 timer circuit), we would have a very effective and cheap system. With the high flow rate, each drop will be a consistent size and hence Z wud have good accuracy. So do not allow the orifice to be altered at all and just switch ON/OFF more frequently for fine Z. This overcomes drop size variation and allows very accurate calibration.

----------


## Slatye

Do we actually need to control the flow rate? I'm wondering whether a better option would just be a float (can be printed) and a potentiometer (under $1) to give an absolute measurement of water level. Then the Peachy can adjust its own speed to match however fast the water is rising, as long as it's within reasonable limits. For feeding back to the computer, just using the potentiometer to drive a 555 timer should work perfectly.

This would also mean that the container shape really doesn't matter. Slightly angled sides (eg. chinese food containers) would mean that the print slows down towards the top (more water volume required to raise the print height by one layer) but since you've got a reliable measurement of the true height it's easy to compensate.

----------


## cephdon

So, after looking around a bit, I think it is possible to have something land in the $50 range as an add-on with a motor and pump.  That would make it a ~$150 kit instead of $100.  Still, I understand about the cost sensitivity.

----------


## mike_biddell

> Attachment 714here's the 555 light toggle switch. Just substitute a FET of your choice and the valve as load on pin 3 in place of the 2n2222. This circuit also works well in the simulator. Unfortunately the allowed file sizes are rather small. so it's only just legible. Compared with the first circuit, it's completely analogue.


Oh, forgot to say, to allow light threshold switch point tweaking on the first transistor, change the fixed 10k (R1) to a pot.

----------


## Anuvin

Ask 10 engineers for a solution...

I have never spent so much of my time thinking about valves. It's tempting to use stepper motors with the peachy printer, in similar and entirely different methods than the ones presented by cephdon, but electric motors are troublesome devils. Look into motor issues with 3d printing, you will find plenty of scary stuff. One of my favorite things about this project is that it contains no motors. That feature alone differentiates the Peachy printer from all others, and I intend to maintain that perspective for as long as is reasonable.

Is it possible to use more than one drip counter on the mic line? If so, we don't have to bother with flow rate, motors, OR in-line valve mechanisms. We would still need to make a valve, but it can be in the reservoir itself, alleviating some typical leak problems that you get with in line valves. Same peachy printer, just with 4 reservoirs instead of 1, or a single reservoir with 4 outlets. If each line were set for sequentially faster drip rates, you can combine them for a large variety of speeds. For example, if line 1 drips 1 per second, line 2 drips 2 per second, line 3 drips 4 per second, and line 4 drips 8 per second, you get every speed from 1 to 15 drips per second. 15 steps of speed is good enough for me, I should think.

I think a pot and float is a really good idea. My fear is that it would take too long to respond. A float is a bit reactionary, compared to counting the drips. Then again, drips are inconsistent, so that may be less accurate than a float/pot could be. Please share any designs for the float you may have, I know I'd like to see them.

----------


## mike_biddell

> Ask 10 engineers for a solution...
> 
> I have never spent so much of my time thinking about valves. It's tempting to use stepper motors with the peachy printer, in similar and entirely different methods than the ones presented by cephdon, but electric motors are troublesome devils. Look into motor issues with 3d printing, you will find plenty of scary stuff. One of my favorite things about this project is that it contains no motors. That feature alone differentiates the Peachy printer from all others, and I intend to maintain that perspective for as long as is reasonable.
> 
> Is it possible to use more than one drip counter on the mic line? If so, we don't have to bother with flow rate, motors, OR in-line valve mechanisms. We would still need to make a valve, but it can be in the reservoir itself, alleviating some typical leak problems that you get with in line valves. Same peachy printer, just with 4 reservoirs instead of 1, or a single reservoir with 4 outlets. If each line were set for sequentially faster drip rates, you can combine them for a large variety of speeds. For example, if line 1 drips 1 per second, line 2 drips 2 per second, line 3 drips 4 per second, and line 4 drips 8 per second, you get every speed from 1 to 15 drips per second. 15 steps of speed is good enough for me, I should think.
> 
> I think a pot and float is a really good idea. My fear is that it would take too long to respond. A float is a bit reactionary, compared to counting the drips. Then again, drips are inconsistent, so that may be less accurate than a float/pot could be. Please share any designs for the float you may have, I know I'd like to see them.


Just how can we get the float reading back to the software, without changing the design to digital? Also, the resolution of a float and a potentiometer would be poor and very unreliable IMHO.   We only have to remember the volume controls on our old audio devices crackling as they lose contact with the potentiometer track. A much more reliable measure of depth and which would have good resolution, is an ultrasonic transducer, bouncing a sound wave off the surface of the liquid. Same problem though, no way of getting the reading back with an analogue Peachy.

----------


## Slatye

> Just how can we get the float reading back to the software, without changing the design to digital?


Easy! You just use the potentiometer as one of the resistors (or potentially both of the resistors) driving an astable 555 timer, with the output going to the microphone input. Measure the frequency of that signal and you've got the height. Or, if you can persuade the microphone to just act as a straight ADC, you can put the potentiometer in voltage divider mode and read off voltages directly.

Pots have a fair bit of friction, which would require a long lever and/or a big float to compensate. The other easy (and cheap) option I can see is a 2-axis analogue accelerometer mounted on the arm; that tells you the precise angle of the arm *and* gives a fair bit of information about whether there are waves in the liquid, whether the Peachy is being moved, etc. An encoder would work too, but high-resolution encoders are expensive.




> Also, the resolution of a float and a potentiometer would be poor and very unreliable IMHO.


Yes, I'm not sure that you'd get the sort of resolution required for this job. You should definitely get ~250 steps that can be measured consistently, but with 0.1mm layers that's only a 25mm high object - pretty tiny. Ideally you'd want more like ten times that, but 2500 repeatable steps from a cheap potentiometer is a big ask.




> We only have to remember the volume controls on our old audio devices crackling as they lose contact with the potentiometer track. A much more reliable measure of depth and which would have good resolution, is an ultrasonic transducer, bouncing a sound wave off the surface of the liquid. Same problem though, no way of getting the reading back with an analogue Peachy.


I thought about ultrasonics, but the ones I've used have a resolution on the order of 1cm - definitely nowhere near enough for a 3D printer. They also tend to be fairly expensive.

Ideally you'd use either a pressure sensor or a direct liquid level sensor. Unfortunately even cheap pressure sensors are expensive and super-high-resolution ones that can cope with potentially nasty substances are *very* expensive. Liquid level sensors like this are nice, but again resolution and cost would be an issue.

Edit: here's the float idea. For the accelerometer version you'd just replace the pot with a bearing and glue the accelerometer anywhere along the arm.

Peachy_container_asm.jpg

----------


## mike_biddell

Slayte..... now I see where you're coming from !!!! But for my part, I think Rylans valve set to large drips (unalterable) and the 555 light switch will give us all we want (fine Z, coarse Z and combinations of both) all under software control. The components and PCB and valve together, probably under $10. No changes whatsoever to the main Peachy. I would be very happy to receive a Peachy with that config.

----------


## cephdon

What about capacitance sensing? It seems like the proper application of conductors along the side of the printed tank should have a capacitance that changes with the increase in water. If they could be arranged in such a way as to produce some predictable outcome (change in frequency from LC circuit?) then we could determine height of the water.  Maybe the frequency produced could be returned through the mic input instead of drip counting as a way to represent position.

BTW, I don't expect anything to come from my ramblings. When I have my peachy printer, I will be making the stepper mods myself and testing other ideas to see what is possible. :-)  However, in the sprit of participation, I figured I would throw out a few ideas to see what others thought of them.  I love the approach for this printer and I just can't wait to get my hands on one.

----------


## Slatye

A capacitive sensor would be sort of cool. It'd definitely have to be an end-user addon (since the Peachy doesn't come with a container and the capacitive sensor is definitely going to depend on the container) but at the same time a simple aluminium foil sensor can offer pretty decent accuracy.

The easiest way to get it into a computer is probably the same as before: replace the capacitor in the standard astable 555 timer circuit with the capacitive sensor, and use the microphone input to measure the frequency of the resulting wave.




> Slayte..... now I see where you're coming from  !!!! But for my part, I think Rylans valve set to large drips  (unalterable) and the 555 light switch will give us all we want (fine Z,  coarse Z and combinations of both) all under software control. The  components and PCB and valve together, probably under $10. No changes  whatsoever to the main Peachy. I would be very happy to receive a Peachy  with that config.


I'm torn between the two options. Having a pure open-loop system would be neat, and being able to adjust the speed is nice. However, I can't get away from the feeling that feedback of the actual water level would really help for Z-axis repeatability in large jobs. Especially for something like the canoe, I'm having trouble accepting that an open-loop system will be able to keep the height accurate enough.

----------


## rylangrayston

Well I haven't got an inexpensive valve working quite yet, I think more than one of the designs we have explored will work well when we have the time to do a higher quality job. 

For now iv made an expensive one, using a servo. here are a few pics and some arduino code. 

20140318_205947.jpg 20140318_210001.jpg




```
/*


with a servo shaft connected to a ball valve 
use 2 pots one to set the open position and the other to set the closed position. 


*/






#include <Servo.h>


Servo valve_servo;  // create servo object to control a servo 


int potPinOpen = 0;  // analog pin used to connect the potentiometer that sets the open postion of the valve
int potPinClosed = 1; // analog pin used to connect the potentiometer that sets the closed postion of the valve
int val;    // variable to read the value from the analog pin 

int openTime = 300;  
int closedTime = 300;




void setup() 
{ 
  valve_servo.attach(7);  // attaches the servo on pin 7 to the servo object 
} 






void loop() 
{ 
  
servo_valve_on();


servo_valve_off(); 


} 






void servo_valve_on()
{
  for (int loopCount = 0; loopCount <= openTime; loopCount += 1){   
  val = analogRead(potPinOpen);            // reads the value of the potentiometer (value between 0 and 1023) 
  val = map(val, 0, 1023, 0, 179);     // scale it to use it with the servo (value between 0 and 180) 
  valve_servo.write(val);                  // sets the servo position according to the scaled value 
  delay(10);
}
}


void servo_valve_off()
{
  for (int loopCount = 0; loopCount <= closedTime; loopCount += 1){   
  val = analogRead(potPinClosed);            // reads the value of the potentiometer (value between 0 and 1023) 
  val = map(val, 0, 1023, 0, 179);     // scale it to use it with the servo (value between 0 and 180) 
  valve_servo.write(val);                  // sets the servo position according to the scaled value 
  delay(10);
}
}
```


PS

after some work on the capacitive feed back on the peachy printer pro, i think that capacitance feed back is a real possibility. 
I think if one was to make a plastic laminated strip  of aluminum foil placed in the top and bottom containers you could actually have two capacitors one rising and one falling in capacitance over time. 

Ive noticed that there are some very inexpensive digital calipers on the market that use capacitive feed back. It would be fun to hack into one and replace the variable cap with our own. .. 
it might be an informative little experiment.  The digital calipers are available for 10 dollars retail and have .005 mm resolution!

Here look at what r2k-in-the-vortex has to say at http://electronics.stackexchange.com...c-caliper-work





> Just had some fun trying to scope the signals, something really funky is going on there.
>   "Here is a good web page" <- that page? wrong! not what is  happening there at all, there is only one input signal, not sin and cos
>   "The key is using unevenly patterned conductors in proximity of two capacitors." <-- wrong again
>   If you ever find a webpage where someone has actually built a copy of one of these then i'll believe what they are saying.
>   Anyway this is what i measured, cant find any of that info from google
>   The vertical strips that are grouped by 8, these are connected to  digital outputs of the chip on blob, they are driven by PWM signals -  approximating sinewave. 8phases, sinewave period 1800us(YMMV), pulse  period ~5.6us. Each phase shifted by 1800us/8 = 225us
>   The receive plate gets the summa summarum that comes through stator  by capacitive coupling. Now the receive signal is bunch of garbage  mostly, but the signal peaks that correspond with output pulse rising  edges do form a sinusoid. Phase of that sinusoid depends on position of  the stator. Im guessing rx measurements must be timed with output  pulses, and then there is some funky signal proccessing to get the phase  shift, im not 100% sure on how to do the rx side of this.
>   As stator pattern and pattern of tx plates repeats every 5mm that  means the final value is summa of coarse and fine measurements. Coarse  measurement is the count of 5mm repetitions, counted and remembered just  like regular encoder values, you can mess this count up is you move the  scanning head on the caliper too fast, caliper loses its 0 point. Fine  measurement is the phase shift measurement of the output sinusoid. These  are summed and displayed on the LCD.
>   Here is an illustration: http://no.life.ee/rainer/pics/stator01.jpg
> ...

----------


## Slatye

Well, just a minor update. I've ordered one of the ultra-cheap eBay diaphragm pumps just to see what I can do with it. Mostly just seeing if the one-way valves are in any way good enough to provide reliable drip rates - if 1000 cycles gives me 200mL once, does it give me 200mL the next time too? Or do I get 250mL the next time?

----------


## Pete

> I've ordered one of the ultra-cheap eBay diaphragm pumps


Sorry think this might have been my suggestion earlier in the thread, and I forgot to post when I got it.....the wrong thing arrived, something second hand (wish I could work out what it's from) but didn't have an in and an out port as pictured, I think it was for sitting in a reservoir but I was kind of hoping not to cut holes in the bottom of my containers, I figure dangling pipes in the top is much easier and safer. I asked for a replacement as described and just got a refund :-( . I've now got a cheap peristaltic dosing pump on the way. Also now looking at water pumps for coffee machines...I'll let you know how I get on with this.

Thought for everyone, although Rylan's laser cutter design is good for the peachy team to manufacture (Respect Rylan, I've actually got an idea for a pump from laser cut slices) since we'll all have a stock printer can we not invent a drip governor that can be mostly printed and maybe hand wound!?

----------


## Pete

Topically, the peristaltic pump I ordered arrived today and I think £6.99 well spent.....http://www.ebay.co.uk/itm/1910373982...84.m1439.l2649

First impressions are very good, I set up a quick test with a PSU and it ran with no load between 3.5 and 6V and 7-14Hz ish came out (there's 3 rollers).

Set up a second dirty test (see picture) and hooked it up to a USB lead so was running from ~5V and I got 50ml in 46 seconds.....and I repeated and got the same numbers three times even with my crude setup, it even gave me the same number once in reverse.
IMG_20140402_173707.jpg
and a horrible video if anybody wants it (I need to clean my kitchen!)




A couple of small cautions if anybody else tries this
-The pipe supplied is short short, I found a slightly longer silicon pipe in my old nitro RC car, and it was easy to replace...I think it's 5mm with 1mm walls but I don't have a measuring stick here
-The pipe seems to work its way around the pump slowly (this seemed better under load but that's not scientific). I think this can be easily fixed by cutting the pipe shorter and putting those fish tank pipe connector things in and a couple of cable ties butting up to the housing

A few things I noticed
-this appears to drip rather than flow, I'm not sure if this is a drip per trapped compartment or more, I'll try to work this out, it's easy to see at low speeds that the motor slows down as another roller hits the pipe so this might just be differing flow rates over the cycle.
-when you stop the pump the liquid remains exactly where it is...this is great as starting and stopping the pump does not appear to need priming to get flow again
-you can hold the output shut with air going in and actually see the pipe inflate slightly (and go phut when you let go)

My next steps are
-get some longer pipe
-add opto feedback so I can detect the rollers going past

Hopefully once I've got the feedback mechanism I'll be able to find out if the volume of water per roller is constant regardless of RPM...I think this is a bit hopeful but I'll setup to plot frequency vs flow and we shall see.

----------


## Pete

I've got some initial testing with my peristaltic pump so I thought I'd share...seems to good to be true for the moment

So i added some feedback, I found some IR photo interrupters from an old line following robot school project and made a tiny board which handily fits in a space inside the pump housing out of the way of the rotors
IMG_20140404_154719.jpg
I can now read back with my scope every time a rotor goes past.

I setup some kitchen scales (this is my biggest inaccuracy, it shows whole grams ad I doubt it's particularly good but hopefully repeatable) and PSU with this feedback counting and then tried shifting some water at different rotor RPMs.
At 5V I was getting about 8.9Hz (that's 180RPM, 3 rotors per revolution) and 14Hz at 6V

One shot 100ml at 6V I got counts of 
833
819

and at 5V single 100ml shots
812
816

then I tried shifting 100ml in several on off on cycles
at 6V I got
835

and at 5V
840
833

so the RPM doesn't seem to make any difference (I need some more precise scales!). I'll try to see this afternoon if I can count flow both ways so that you can potentially put more in and take out again to overcome surface tension, I think there's another thread about this somewhere.

----------


## Pete

I just did a quick in and out test, I had to move my reservoirs, previously I had the header above but I tried to run the pump the other way and it wasn't so good at pumping uphill a couple of feet.

With them level I pumped 150ml in and 50ml out and got 1282 counts in an 430 out so 852 compared to the above is pretty good (or compared to the 150/1.5 value, 855), I suppose the slight extra can be attributed to my measurement error or the lower pressure this time on the input side. 

Regardless this looks to be a pretty good mechanism for getting in and out a known quantity of liquid. I'll set up a better test fixture that counts in and out a set amount and mark on the resevoirs the high and low, then I can leave it running for a longer time and see if there's an accumulated bias on one side.

----------


## rylangrayston

Wow!!!! I only just saw this now!

Thanks Pete!!!  This is realllllly valuable work your doing.
Id say your, once again, leading the way for the pro! First with the micro controller and now with the pump! 
Its just so cool to see people like you and everyone else here on this forum leading development ahead of even those of us that work at peachy!
Seriously a big Thankyou from the hole team.

Since you have had success with this pump im ordering some too! 

PS  I think all this wonderful pump stuff could use a thread of its own..  it seems obvious to me that both the pump method and the drip method  will be widely used.  Any mods reading this? I suggest we move the last  few posts to there own thread called Pete's pump's  :Smile: 

@Slatye
Im supper curious to know how diaphragm pumps preform, did yours arrive yet? 
I have a bunch of gear pumps but there are 2 problems .. they lots of tiny bubbles and when the pump shuts off 
it still lets water flow.

----------


## Anuvin

I have tried 3 times now to write a post that is both engaging and reflective of the effort you put into your posts, but you set the bar really high. Great work Pete, I really enjoy reading your findings, and I can't wait to see what else you come up with.

----------


## jjmouris

Pete, nice work!!! Keep it up!!!

With a large enough reservoir using your method we could really get some accurate height management going with potentially the option to "dip the print" by very small amounts and great return accuracy. Something currently not possible with just a drip.

----------


## Pete

Thanks for the kind words, Rylan/Anuvin/jjmouris.

jjmouris, working on a few quick things from my initial testing
-I can easily control a micro to do discrete steps since the pump is only a handful of Hz (it's actually a really cool epicyclic gearbox, I'll do some macro photos and post them)
-approx 0.12ml per rotor arm

A 150mm square reservoir would give ~0.005mm Z height per count. I've seen a lot of printers using 0.1 or 0.05mm Z height resolution so to achieve the 0.05 you'd need 10 counts which is around 2/3rds of a second to pump in that water. If you had a print liquid that maybe needs 1mm over that and then back out again (don't know if this is reasonable) then the total time would be about 30 seconds in between each layer, so it's not all perfect. Just to put this in perspective printing a 25mm high object would run the pump without any printing happening for 4 hours! All this said, I'm probably going to be happy leaving my peachy printing stuff overnight and if it resolves a host of issues then I'm good with it!

----------


## jjmouris

Pete, without having any real experience with peachy printing. I would imagine that 1mm above the printing level is way more then needed to break the surface tension when printing at 0.05mm accuracy. I guess it depends on the resin but my gut feeling says that twice the accuracy should be enough (0.1mm), thus reducing your time estimate by a factor of 10.

For me however it is not about speed but final accuracy. I can see how surface tension would stop the resin from flowing properly even if left for hours if the change in Z level is not enough. Breaking the surface tension and then lowering the fluid level down to the next layer height sounds like a more accurate method to me.

I guess this is where much more trial and error is to come in the near future. Your work will no doubt prove essential in making this possible in the first place!

With regards to controlling the pump, maybe we need to look into stepper motors and absolute digital control of the stepper motor rather then sticking with the rather old hat brushed motor combined with timed runs. You can use a cheap of the shelf brushless RC motor and simply make it step round by controlling the current on each of the 3 phases.

J

----------


## Pete

> Pete, without having any real experience with peachy printing. I would imagine that 1mm above the printing level is way more then needed to break the surface tension when printing at 0.05mm accuracy. I guess it depends on the resin but my gut feeling says that twice the accuracy should be enough (0.1mm), thus reducing your time estimate by a factor of 10.


I've got no experience either, yet! I really hope you're right but I fear might not be, the meniscus on water can be easily seen and these are much thicker liquids, although it's been a long time since I've tried doing physics of this nature so hopefully my feelings are wildly inaccurate.




> For me however it is not about speed but final accuracy. I can see how surface tension would stop the resin from flowing properly even if left for hours if the change in Z level is not enough. Breaking the surface tension and then lowering the fluid level down to the next layer height sounds like a more accurate method to me.


Ditto...although I have seen a thread somewhere talking about floating another liquid level on top to effectively lower the surface tension which may prove a good addition or just better on it's own. I'll also be experimenting with ultrasonics to try and resolve this issue.





> I guess this is where much more trial and error is to come in the near future. Your work will no doubt prove essential in making this possible in the first place!


trial and error......thank you, you god! When I was leaving school they were trying to change this phrase to 'trial and improvement', some ofsted nonsense about positive motivation......it's all about the error!
I hope my future work will yield much more than this ;-)

----------


## jstrack2

Here are a few pictures in CAD of an idea for the drip governor I had after doing some online searching:

valveA.jpg valveB.jpg valveC.jpg
The first picture is how it would look assembled, whereas the second and third picture I moved the outer casing aside to show what is going on internally. The blue thing is a rubber ball cut in half. The dark gray thing attached to it is iron (coated so it won't just rust). Normally the rubber ball stops the flow of water (as shown in picture 2). When the solenoid is powered it raises it and allows water to pass(as shown in picture 3). Because the ball is rubber (and spherical) it will form a good seal. The whole setup is vertical, so it will fall from gravity when not powered, thus closing the valve. 

Also this can be made super easily by using a thin male pvc pipe adapter and pvc pipe. These two PVC parts will be everything that is beige in the CAD drawings except the cao at the bottom and top to connect the tubes to. The caps can just be a thin sheet of plastic cut in a circle with a hole drilled in it. PVC pipes can be as thin as about 1 centimeter outside diameter. So it could be small. Also if it needed to be cleaned (besides just turning it upside down and running water through it, it could also just have the tube pulled off and then be cleaned. Of course no parts here even cost close a dollar. And assembly should be very easy. With a transistor (and diode to protect against a back emf) all that would be needed would be a simple signal to turn on the coil.

male pvc.jpgpvc.jpg 
By the way here are the male PVC pipe adapter and PVC pipe I am talking about.

Happy Father's Day!

----------


## jjmouris

Pete, any progress with your pump?


 :Smile:

----------


## Pete

Hey jjmouris,
Haven't played with pumps recently, there's a few more fundamental issues to sort out before addressing pump improvement i.e. software efficiency and hysteresis in the damping system, both of which are improving at a great rate but still are not there yet. I am building the control and feedback mechanisms for the pump into my USB controller for the peachy so I expect when the bigger issues are sorted that my addition of these will be relatively quick and I'll be sure to post the results.

----------


## Chayat

Anyone else read the title of this thread in the voice of Keanu Reeves from Bill and Ted?

----------


## jstrack2

Here is a little video showing what I was talking about in the CAD files I posted last week. I put food coloring in so the water is easier to see: 



I used a neodymium magnet I had laying around instead of iron since it had a nice shape, performed well and won't corrode. Therefore Here is a video of it going up and down: 



It only uses about 50 mA at 5V. I used 36 gauge copper magnet wire btw, but a little higher gauge may be better. Also a smaller PVC adapter would be better, but the one I used was just what they had at a local hardware store. It has a diameter of about 27 mm. A tube can be glued to the top and bottom of it, or to have things sealed you can use a little PVC cap. That way to clean things all that is needed to be done is just pull the little PVC cap off and it can be everything can be super easily cleaned then. Since it uses so little of current a transistor is not needed to power the solenoid (even if powered by a microcontroller), although a diode should probably still be used to protect against backwards voltage. Here is a picture of the rubber ball glued to the magnet and a picture of the PVC with the solenoid glued on:

halfball.jpgPVCsolenoid.jpg

The total cost of everything I used is only a little over one dollar, and especially if bought in any volume could be less than a dollar. It should be very reliable too. Nothing should corrode (I think the rubber used in bouncy balls won't, but worst case things can be coated). If the solenoid was only powered for a small fraction of a second (instead of me slowly flicking a switch) then only a tiny amount of water would flow through. So the software could totally control exactly when and how much water flows through. I think that this will be cheaper, more reliable and more precise than using a pump. Let me know if anyone has any questions or would like me to show something else (like actually having the tubes attached for example).

----------


## BrockMcKean

> It only uses about 50 mA at 5V.


That looks really simple and could be very effective. However, I think you should modify it to work around the current modulation scheme the peachy uses for mirror positioning. This would need to use FM, because AM is already used using it or PM would just be too complicated and costly in my opinion. Also, using FM directly should translate into an up and down motion in the magnet, so it should be able to easily control the actuation directly. Problem is, the line level of most audio output is very low, so I think there's really no way of getting around an op amp or some other kind of amplification, which also means you need a DC bias, and as far as I know there's basiaclly no way to get around this without using requiring separate USB power, batteries, or a transformer. A transformer could be used to directly power the bias from the audio output, but then you're at least doubling the cost and probably quite a bit more ( think) to achieve the Voltage and current simultaneously. So, in my opinion USB power would be the way to go here since it's already connected to audio and practically every source of audio is going to have some sort of USB connection. I'm not sure what kind of power mico and mini USB provide, though. So, powering this entirely from a device that doesn't have a standard USB connection might be a little bit tricky.

As for the magnet itself, it would probably help to have some sort of support system inside the pipe as well to provide some surface the magnet can press against when it is up so that the viscosity, pressure, and flow rate of the resin does not affect the orientation of the magnet very much either. Any ideas there?

----------


## 3dspider

We need to watch what metals we place into the saltwater. Most neodymium magnets are nickel plated and will cause any aluminum parts (like the drip sensor) to corrode faster. see https://en.wikipedia.org/wiki/Galvanic_corrosion . To get around this, we could use plastic coated magnets or epoxy coated magnets like this.

----------


## BrockMcKean

> To get around this, we could use plastic coated magnets or epoxy coated magnets like this.


Yes, and it really doesn't change the price much either. They should definitely be epoxy/polyurethane coated.  Also, I did a bit of digging looking for some indication as to whether a cell phone could provide 5V output from micro usb and haven't found anything conclusive, except that micro and mini usb are indeed capable of passing 5V power. It's just a wire so I assumed as much, but if the ability to print from a phone is a feature the Peachy project is serious about, we should address this now and incorporate it into proposed variable speed drip systems.

Does anyone know if there is a standard for voltage output from phone usb or if that's something you can rely on at all...? I'd like to see the peachy's schematic if anyone can point me in that direction or if a beta tester can work one up in a SPICE program for us all. We can come up with a better guess at how to include an electrically controlled drip governor like this without disturbing the work that's already been done.

----------


## jstrack2

Thanks for the feedback! Again if anyone wants to see something more let me know. I know the videos were very short.


Brock McKean: I think that while it would be possible to use frequency modulation (or other techniques discussed in this forum) to directly control the drip speed with the speaker, in my opinion this is not the way to go. I think that having the speaker control the laser as well as possible should be the priority. Adding a bunch of complexity (or greatly limiting the drip governor's functionality) to save one or two dollars does not make much sense to me. I agree that USB power sounds good. What I did here was about 50 mA. I think any USB 2.0 including the micro does at least 500 mA. I think they are always at 5V. If it were made smaller and the coil was not poorly hand wound as it was here then I think it could work on even less than 50 mA. Since when the valve is open liquid rushes through fast I think that there is not a need to have it stay open when the coil is not powered. The coil will only be powered for a tiny fraction of a second anyway.

I agree that some schematics would definitely be helpful.


As for maintaining the orientation of the magnet this happens naturally, so no extra work is needed. The field makes the magnet's orientation stable.


There is something about the pressure worth thinking about though. This valve should be placed as high up as possible to minimize the pressure and hence the magnetism needed. Again having the valve be smaller will reduce the magnetism needed, since of course less area experiencing a pressure means less force. If the method of having the salt water drain out is used instead of poured in then the pressure level may vary significantly over the course of the print (depending on the setup the pouring method may also result in significant pressure change too). This may have to be corrected for in software (longer/stronger pulse when pressure is high). I don't think that spectacular accuracy is needed here though because that will be provided by the water level measuring methods.




3dspider: Great point, I forgot about that. I also agree prebought or coating afterwards of the iron/magnet will probably be needed. As you and Brock McKean said this shouldn't be a big deal.

----------


## BrockMcKean

*EDIT:* _I just realized that Rylan has already taken pretty much all of this into account save specifics of electrical and programmatic operation, so perhaps we should focus on that._ :S




> Brock McKean: I think that while it would be possible to use frequency modulation (or other techniques discussed in this forum) to directly control the drip speed with the speaker, in my opinion this is not the way to go. I think that having the speaker control the laser as well as possible should be the priority. Adding a bunch of complexity (or greatly limiting the drip governor's functionality) to save one or two dollars does not make much sense to me.


If the point is to keep the cost as low as possible and it's reasonable to do something that would decrease the cost I don't see why it shouldn't be done. If the mirrors truly operate on AM, FM should not affect them at all.   But if we did want to add a filter before it, it would guarantee that no FM would ever reach the laser assembly. Adding somethign like that will cost basically nothing, pennies. Placing a low pass filter before the peachy's mirror/coils would completely isolate it. Using an op-amp to, connected to the 5V for DC bias, and passing the frequency from the audio jack, the coil can be controlled directly. I guess it sounds a little complicated, but I assure you things like this (using multiple and separate modulation schema) are done all the time in many electronic devices.




> Since when the valve is open liquid rushes through fast I think that there is not a need to have it stay open when the coil is not powered. The coil will only be powered for a tiny fraction of a second anyway.


Yes, I agree. It shouldn't stay open. This means we need a switch between 5V DC and Ground, or some way of using the AC signal directly from the audio output that will result in the desired movement. Maybe we can use PWM over USB instead if we are going to use it for a DC bias directly from the device anyway. This would probably be easier and certainly separate if it can be achieved at the correct voltage/current level on the data line USB data line.




> As for maintaining the orientation of the magnet this happens naturally, so no extra work is needed. The field makes the magnet's orientation stable.



Unless the magnetic field is on the entire time and the desecent of the magnet is forced and controlled, there's no way to guarantee that freefall will not result in the magnet ending up lop-sided, assuming there is pressure above the magnet still. However, if  it has some sort of guiding rod to prevent it from turning to that kind of angle that extends from the magnet up/down the drip a bit it should be no problem.




> There is something about the pressure worth thinking about though. This valve should be placed as high up as possible to minimize the pressure and hence the magnetism needed.



Yes, but then you also have to worry about the reservoir's resin level. I'm not really sure how the drip works now exactly (at all really), but any resin below the valve would have to be pumped to the valve somehow or the reservoir would have to mechanically change to deliver the resin. So if this is not a problem it should be placed as high as possible.




> I don't think that spectacular accuracy is needed here though because that will be provided by the water level measuring methods.


If the drip governor can only move to one position we're limited to altering the period for variability, which is fine and probably the best approach. However, the dynamic range will then be determined by the minimum amount of time we can open the valve. Accuracy is not a problem here, but if we want to be economical about it, the software should take the drips into account and calculate the resin level without measuring afterwards (because the drip resolution and number of drips are known, the entire volume is known). This would require using a well defined right rectangular prism as a reservoir (all opposing sides parallel, all adjacent sides perpendicular) so that the area for each level is identical. I'm not sure if that's part of the peachy's design right now or not to use some sort of level measuring method, but calculating it this way would be much less invasive and not disturb the print surface/material in any way and would allow for more printable volume.

----------


## jstrack2

He has already worked on something very similar, however I don't think that he has gotten a super cheap and easy to make valve to work well yet. I could be wrong though.





> If the point is to keep the cost as low as possible and it's reasonable to do something that would decrease the cost I don't see why it shouldn't be done. If the mirrors truly operate on AM, FM should not affect them at all. But if we did want to add a filter before it, it would guarantee that no FM would ever reach the laser assembly. Adding somethign like that will cost basically nothing, pennies. Placing a low pass filter before the peachy's mirror/coils would completely isolate it. Using an op-amp to, connected to the 5V for DC bias, and passing the frequency from the audio jack, the coil can be controlled directly. I guess it sounds a little complicated, but I assure you things like this (using multiple and separate modulation schema) are done all the time in many electronic devices.



Yes I know that using multiple modulation is common and relatively simple. However I am skeptical here that this will not cause issues by trying to do too much at once. Very little can throw off things when stuff is controlled directly by varying voltage levels as the mirrors are. Also if USBs are already used for power, why can't they just control this too? I think using the USB would be cheaper anyway. I am still not totally clear on the details of how everything is powered, but yeah I think using the USB is the way to go.





> Yes, I agree. It shouldn't stay open. This means we need a switch between 5V DC and Ground, or some way of using the AC signal directly from the audio output that will result in the desired movement. Maybe we can use PWM over USB instead if we are going to use it for a DC bias directly from the device anyway. This would probably be easier and certainly separate if it can be achieved at the correct voltage/current level on the data line USB data line.



Exactly. Although it doesn't have to be pulse width modulation necessarily, just a pulse whenever it wants! Although I assume this is what you mean. As for the voltage and current I am very confident this can be made to work.





> Unless the magnetic field is on the entire time and the desecent of the magnet is forced and controlled, there's no way to guarantee that freefall will not result in the magnet ending up lop-sided, assuming there is pressure above the magnet still. However, if it has some sort of guiding rod to prevent it from turning to that kind of angle that extends from the magnet up/down the drip a bit it should be no problem.



I disagree. I think this is a non-issue for multiple reasons. First if the solenoid gets pulsed for a tiny amount of time then the magnet rubber ball object plug won't have time to rotate. However let's say that instead it is pulsed for a long period of time, like in the videos that I showed. Say then downstream of that a narrow opening is used so that the tubing still has drops come out. In this case there still will not be an issue because the rotation forces caused from asymmetries of the water passing through the valve will not be enough to rotate it, even will some pressure. Also if there is minor rotation this is fine. The ball is a sphere of course, so even if it is rotated some it will still plug the hole the same way. If you are still worried about it then if the magnet/iron is thick enough and close in diameter to the PVC adapters inner diameter it won't be able to rotate. And in addition to this if there was still problems then people could figure out what is causing crazing rotational forces and maybe have the solenoid semi powered when the magnet/iron is falling. So yeah there are a lot of reasons this is not worth worrying about.





> Yes, but then you also have to worry about the reservoir's resin level. I'm not really sure how the drip works now exactly (at all really), but any resin below the valve would have to be pumped to the valve somehow or the reservoir would have to mechanically change to deliver the resin. So if this is not a problem it should be placed as high as possible.



I should have been more clear here. When I said "as high up as possible" I meant taking this into account. If the salt water is dripped in then the valve will have to be below any water that it going to be dripped in eventually. If the salt water is slowly dripped out (as would be done if the salt water + resin + fresh water printing method is used) then the pump will have to be below the lowest point that the resin gets when the print is finished (which is when the resin is in its lowest point). 





> If the drip governor can only move to one position we're limited to altering the period for variability, which is fine and probably the best approach. However, the dynamic range will then be determined by the minimum amount of time we can open the valve. Accuracy is not a problem here, but if we want to be economical about it, the software should take the drips into account and calculate the resin level without measuring afterwards (because the drip resolution and number of drips are known, the entire volume is known). This would require using a well defined right rectangular prism as a reservoir (all opposing sides parallel, all adjacent sides perpendicular) so that the area for each level is identical. I'm not sure if that's part of the peachy's design right now or not to use some sort of level measuring method, but calculating it this way would be much less invasive and not disturb the print surface/material in any way and would allow for more printable volume.



I think that measuring after the fact is pretty important. I am skeptical that only counting drips will ever be that accurate (at least with low cost equipment). Drip sizes vary some. It is pretty hard to get around that. Now if you don't care about print accuracy this can be fine. For example you could print some object that is real detailed but is ten percent too tall and it may still look great. However for other applications very high accuracy is needed. Gears would be a very clear example of that.


I submitted a video in a different thread using a caliper I took apart to measure the water level with up to 0.02mm accuracy: http://3dprintboard.com/showthread.p...on-idea/page11 Check out the improved video, the first is really bad!


 It is quite cheap. Unfortunately the video may not do much to calm your worries that it will take up space, since I used a huge sheet of styrofoam. However I assure you this is not at all necessary. With a properly designed float it can have almost no effect on the maximum size of the print. Additionally, a slightly bigger container for the printer could always be used! Also it will not cause an ripples. The float steadily rises with the liquid if built properly (which laser cut parts would be). As I stated on that thread this with a Kalman filter will allow for very very high accuracy and resolution in the Z-axis. The USB can be used to receive the data here too! haha

----------


## BrockMcKean

> Exactly. Although it doesn't have to be pulse width modulation necessarily, just a pulse whenever it wants! Although I assume this is what you mean. As for the voltage and current I am very confident this can be made to work.


Yes, which should be a constant PWM per layer. The only time the PWM should change is when a layer will take more or less time than the previous layer. The only time the PWM will be off is when the print is finished or paused. I think we are essentially saying the same thing.






> I disagree. I think this is a non-issue for multiple reasons. First if the solenoid gets pulsed for a tiny amount of time then the magnet rubber ball object plug won't have time to rotate. However let's say that instead it is pulsed for a long period of time, like in the videos that I showed. Say then downstream of that a narrow opening is used so that the tubing still has drops come out. In this case there still will not be an issue because the rotation forces caused from asymmetries of the water passing through the valve will not be enough to rotate it, even will some pressure. Also if there is minor rotation this is fine. The ball is a sphere of course, so even if it is rotated some it will still plug the hole the same way. If you are still worried about it then if the magnet/iron is thick enough and close in diameter to the PVC adapters inner diameter it won't be able to rotate. And in addition to this if there was still problems then people could figure out what is causing crazing rotational forces and maybe have the solenoid semi powered when the magnet/iron is falling. So yeah there are a lot of reasons this is not worth worrying about.
> 
> I think that measuring after the fact is pretty important. I am skeptical that only counting drips will ever be that accurate (at least with low cost equipment). Drip sizes vary some. It is pretty hard to get around that. Now if you don't care about print accuracy this can be fine. For example you could print some object that is real detailed but is ten percent too tall and it may still look great. However for other applications very high accuracy is needed. Gears would be a very clear example of that.


These two issues are related. If we want lower cost, we want a smaller magnet, smaller coil, and less current. A larger magnet and stronger field will be less susceptible to fluctuations caused by the viscosity and pressure of the fluid, but shrink it all down and the forces might become relativistic. In either case, the solution is to create a guiding element with the epoxy/polyurethane. If you look at Rylan's original design concept in his video at the beginning of the thread, it is "encased" in a right circular cone on each side. This will keep the magnet coming back to where it should be regardless of minor fluctuations and will allow the magnet to be much smaller, require less energy to operate, and potentially increase the drip frequency. 

Additionally, the drip is not precise, you are correct. However, it is accurate. That is to say, it does of course deviate a little, but this magnet can only come up and go down in so many ways. The drips will be of a size that will all fit under a normal PDF curve, and the drips are so small in comparison to the level  (assuming a_ large enough_ print volume), the error in calibration and calculation should be no more negligible than the error in measurement and calculation. You have to either assume the drip and container volume or assume the resolution and the zero position of the measurement device. Standard PLA printers do calibration tests. Inkjet and Laser 2d printers do calibration tests and alignment prints. Doing an alignment print on the peachy and assuming you are using a right rectangular prism for the print volume is no different than assuming you have assembled and properly calibrated a level sensor within the print area.

In shrinking the magnet and speeding up the drip frequency, the constant surface tension and viscosity should hit a critical point that will simply not allow liquid to pass. If it is designed such that it's relatively close to this critical point the surface tension and viscosity should maintain a very constant drip volume. Another approach to this would be to use some sort of telescoping system for the magnet that only allows a specific volume by design to enter a chamber. Magnet goes up, chamber is released, magnet goes down, chamber is refilled.  Not sure how to do that right of the top of my head, but I assume something like that could be done.

Calibration and assumption is used often in electronics for many purposes, but yes, there is usually some feedback mechanism to determine that the calibration and assumption still holds true. I would agree that measuring is important, but adds another layer of complexity for users that just want the $100 printer To print some really cool objects or don't care about it being accurate to a few microns. So, for simplicity and costs sake I say why bother? On the other hand, measuring afterwards allows you to have basically any printable volume container shape. Whichever solution is more important  for the most basic $100 users and cost lest to implement, we should pursue. Hell, why not just do it both ways?

----------


## jstrack2

If you look at the video I posted there really isn't any rotation. If it were made smaller I agree the rotation effect would increase, but not that much. I think it would scale linearly with the radius of the plug, if not even sublinearly. So even if the whole thing were four times smaller in all dimensions I think that this effect would still be pretty negligible. Even with my 27 mm wide design the current draw was not much. At a fourth this width the current draw would be absolutely tiny. Also as I said the PVC tube itself already guides the plug some. Finally I don't know what you mean by relativistic, maybe you mean quantum? But that is irrelevant unless you get down to the scale of a few nanometers! Anyway since I don't understand the theory nor did my experiment show this to be a problem, I think that you should make a video of the valve if you are still concerned about it. If it has that problem then I will try to help and address it.

It is neither super precise nor accurate. You can not expect it to behave with the same predictable probability density function every time (such as a normal distribution for example). It will always drift. This is why for example gyroscopes and accelerometers are used together, and not just gyroscopes. Gyroscopes measure rate of change of the angle with respect to time. So then angle is found by integrating over time. But there is always drift, so accelerometers which directly measure angle are also used to correct for this limitation. Another example is how battery capacity remaining is calculated. In theory you could integrate current use over time. However because of the drift problem a direct measurement method is also needed (such as checking voltage here). This is why the threads discussing making a direct measurement were created. It is not a matter of just calibrating it once. That will not get very accurate results. Again if you want to save a few dollars on the printer and have not very good at all accuracy in the z axis that is fine. But this problem can cause the z axis to be off multiple percent (not microns) and direct measurement should only add a few dollars cost (probably less than 5). I do not mean to say that drip counting shouldn't be done however. It gives amazing resolution, just not accuracy.

----------


## BrockMcKean

> If you look at the video I posted there really isn't any rotation. If it were made smaller I agree the rotation effect would increase, but not that much. I think it would scale linearly with the radius of the plug, if not even sublinearly. So even if the whole thing were four times smaller in all dimensions I think that this effect would still be pretty negligible. Even with my 27 mm wide design the current draw was not much. At a fourth this width the current draw would be absolutely tiny. Also as I said the PVC tube itself already guides the plug some. Finally I don't know what you mean by relativistic, maybe you mean quantum? But that is irrelevant unless you get down to the scale of a few nanometers! Anyway since I don't understand the theory nor did my experiment show this to be a problem, I think that you should make a video of the valve if you are still concerned about it. If it has that problem then I will try to help and address it.


I'm just saying it is something that should be given some attention as it's scaled down more. All I mean by relativistic is that the forces from viscosity is basically negligible beyond a certain size and magnetic field strength. I don't know what size magnet and field strength you would need to go down to to make these  two relatively close, but there is a point that it would happen. We can probably just use more coil windings if in shrinking it that did become a problem, but that is my point. Just something to think about and be aware of as a factor that could possible have some influence on a smaller scale.




> It is neither super precise nor accurate. You can not expect it to behave with the same predictable probability density function every time (such as a normal distribution for example). It will always drift. This is why for example gyroscopes and accelerometers are used together, and not just gyroscopes. Gyroscopes measure rate of change of the angle with respect to time. So then angle is found by integrating over time. But there is always drift, so accelerometers which directly measure angle are also used to correct for this limitation. Another example is how battery capacity remaining is calculated. In theory you could integrate current use over time. However because of the drift problem a direct measurement method is also needed (such as checking voltage here). This is why the threads discussing making a direct measurement were created. It is not a matter of just calibrating it once. That will not get very accurate results. Again if you want to save a few dollars on the printer and have not very good at all accuracy in the z axis that is fine. But this problem can cause the z axis to be off multiple percent (not microns) and direct measurement should only add a few dollars cost (probably less than 5). I do not mean to say that drip counting shouldn't be done however. It gives amazing resolution, just not accuracy.


Gyroscopes measure orientation and accelerometers measure acceleration. Sampling your accelerometer will give you a function of acceleration. Integrating that gives you velocity and integrating that will give you displacement. Match that up with your gyroscope samples, and you have a time correlated displacement and orientation pair that can be used to explain where you are in space from a given reference point along this vector.  So, if you were to depend on only the gyroscope you would not be able to determine if you were moving at all. The gyroscope does not know the difference between facing a direction for a specific amount of time and traveling in the exact same direction for the same specific amount of time. Likewise the accelerometer doesn't know direction at all. It only knows force due to acceleration, so you can move it in any direction with identical force and it doesn't know the difference between any direction in particular. However, even using an accelerometer and gyroscope together, you cannot be sure of how much time and distance was covered exactly, due to drift.

Drift occurs in sold state devices and crystals with respect to time. The crystal structure's and electron affinity changes overtime and becomes misaligned internally. The same can be said for any kind of doped semiconductor. The depletion regions do not stay the same and therefore the output of diodes and transistors is not consistent over long periods of time. Any clock dependent measuring source also experiences this drift depending on the precision of the clock source. 

This proposed drip governor does not contain any of these elements. The mass of the magnet will not change. The mass of the coils will not change. The strength of the magnet and the strength of the field induced by the coils will not change. They will operate the same way every time, given a specific voltage. The voltage/current and modulation will be SLIGHTLY different each time, probably by a few uV/uA and ns/ps. That is to say, using PWM or any other clock dependent form of modulation (anything coming from a computer would be), is susceptible to this. Computers adjust their clocks because they experience drift, but they do it only frequently enough for everyday units of time. microsecond, nanosecond, and picosecond drifts pile up until the clock decides millisecond drifts are too much, so this would happen. However,since our drip rate shouldn't be near the frequency to have a period of microseconds, the computer's compensation for this drift should actually keep it pretty steady.

Beyond that we're talking about the consistency of the voltage output from the USB. If one system uses 5V and another puts out 4.99V and another puts out 5.01V, that will certainly result in some amount of variability in the drip, but not much, and it can be accounted for by a calibration print that assumes differing amounts of variability within a range measured in development for small "identical" objects. Whichever prints the best is the correct amount of variability. All other printers 3d and 2d have some form of calibration. Measuring digitally would be ideal, but software is free and the resin is pretty cheap. So, unless it costs less than a first calibration print of a few mL and it can be accurate to 100 micrometers or so, I would rather make sure the kit costs as little as possible. Now, for an assembled kit or a higher quality commercial version, I agree with you 100%. I'd be a bit confused if there was no measuring of the fluid level.

Also, I'm very busy with some other things right now but I'll be wrapping them up today and have a lot of free time for the forseable future, so I will most certainly be doing my own experiments and contributing as much as possible. I just REALLY want to get working on this and I just don't have the time until tomorrow on, so I'm talking about it instead.  :Smile:

----------


## jstrack2

Oh alright you mean relative. Relativistic means that relativity is applicable. Like for example the water is flowing close to the speed of light. If that is the case then I have no problem believing that there could be some rotational effects on the plug! haha Seriously though I definitely think in general that trying to find problems before something is built is a good thing, but here I think that rotation won't be an issue.

As for the gyroscopes I was again not clear. Sorry about that. It is true that these gyroscope sensors can not measure linear acceleration, so an accelerometer (or something else) would be needed for an application requiring linear acceleration measurement. They measure angular velocity. Accelerometers measure acceleration, but since there is gravity pointing the same direction they can be used to measure angle as well. So anyway my point of the example was that if you tried to know the angle by just integrating the gyroscopes data about angular velocity you would over time be more and more wrong. Just using the accelerometer may not be optimal either, because linear accelerations like vibrations will in the very short term give weird readings. If the information is combined then you can get very good orientation data. This is similar to the drip and direct measurement system for the Peachy Printer. If only the drip counting is used then the accuracy will not be great. If a direct measurement method is used and not the drip counting method then the accuracy will be great, but it likely will not have the potential submicron resolution that the drip counting offers. If both methods are used and the software uses the Kalman filtering method then the printer will have both great accuracy and resolution. This is why I was excited to make the videos showing the caliper working. Having submicron resolution and extremely good accuracy with a 100 or so dollar printer is pretty ridiculous!

As for why this will have drift it is for different physical reasons then a MEMS gyroscope sensor. Here I think the main source of inconsistency will be how the salt water flows through the valve. Maybe the changing pressure could be correctly compensated for in software, but that won't be enough. Especially if the valve is only open long enough to allow for a drop or a few drops to pass through at a time. The exact amount that gets through will be very complicated. There are a lot of factors at work here which will lead to the amount of water getting through each time varying. Also when you consider that there is salt here to which can change the properties and that the valve and rubber ball aren't flawlessly manufactured you will have inconsistencies. This will happen way way before you get the plug rotating. Also if you perfectly calibrated it (which would not be that easy) and then did a couple prints the accuracy might be half way decent (but still not that great). But then could you say that a couple weeks later without more calibration it would be? I don't like the idea of having to do intense calibration all the time for only decent accuracy. I mean I would still buy the Peachy Printer without this feature, but I would rather spend an extra five dollars or so to have this direct measurement. On a side note though it is weird to be someone arguing for a more expensive solution, usually I am fighting to spend less! haha

But yeah I look forward to seeing the videos you make!

----------


## BrockMcKean

Yeah, it probably wont' be an issue but I like to build things so that it's not possible for them to be an issue. Kind of like how you suggested PWM instead of further complicating the AM signal with FM. Yes, you are right that error compounds in calculating something like the integration of the gyroscope, but that is due to the device's clock drift and breakdown of the semiconductor over time.  And yes! I meant relative, not relativistic. Brain fart.  I hope the drip doesn't get close to the speed of light either, although it would be quite interesting.

I guess it's just my experience that rigorous testing in r&d phases can result in a true value calculation. That is to say, you can usually measure the system in some way that can guarantee accuracy one time in r&d, one time in production,  or extremely infrequently in use.  If we were to vary the frequency of the drip, using the same voltage and current each time, shorter pulses for higher frequency, longer pulses for lower frequency, we would see that the drip size will be fairly similar across a band of drip frequency in the middle, but at a critical low frequency, the drip volume begins to increase much faster until it becomes an intermittent stream and at a critical high frequency the drip volume decreases until it does not drip at all. Those critical frequencies will be based on the viscosity of the mixture and the cross sectional area the mixture has to flow through. If you observe the band between these two critical frequencies for "long" periods of time at a frequency resolution twice or greater than the frequency resolution the governor will use to vary the drip speed, you will see that the drips will be a little larger or a little smaller than the previous drip, but the drip volume at a specific frequency will fall under a normal curve and over a large number of drips, this is calculable.

I'm not saying it's the perfect or best solution, I'm just saying if we want to keep the cost down, this should be an option on the table and it should be tested. These kinds of things cannot be proven to be viable or not one way or the other without a wealth of related experience with this specific kind of system, specific technology, specific materials, etc. Doing it should be a matter of keeping manufacturing error smaller than the measured PDF that governs the drip volume for a "perfect" version of this drip governor and proving (or disproving) that the manufacturing error is indeed small enough with testing. In a DIY kit, it would be useful to keep the cost down. In a pre-assembled printer or a professional quality printer, I would want a measuring device on the other side and I would expect a self cleaning and calibration function just like every other printer. I would not expect the cleaning or calibration to be as trivial as calibrating a 2d inkjet or laser printer. I would expect it to be relative to the print time of a 3D printer, and I'm fine with that just so long as it calibrates and cleans itself!  :Smile:  So, I'm not arguing either way. I'm just saying both are viable and one makes more sense than the other in different contexts.

Still waiting on a new camera.  :Smile:  Maybe we can Google+ sometime and get a hangout going or work on parts of this together. Virtual peachy makerspace!  :Big Grin:

----------


## jstrack2

Alright yeah I think that I also have a bias towards doing things that make operation real stable and reliable, since I have seen shortcuts lead to delays too much. But yeah I agree that governors should be tested and then a logical decision should be made on exactly what to do after that. If the governor gave decent accuracy then I think that having a direct measurement method only be an option very well might make sense. It would probably be real easy to include it as an option. I am just worried that this could cause users significant headache.

I filmed my videos with just a phone so I expect you to have top notch production quality now haha. But yeah I do like Google+ Hangouts. It could definitely be helpful. Although I think that still nothing comes close to matching real life working together. Maybe virtual reality in the future can bridge that gap?

----------


## BrockMcKean

Ugh... virtual reality. When we can connect telepathically and using something like the Matrix I'll be a believer.

----------

