Picking things back up

[webby2]

changing that design to go another way the part will take 30 hrs to print,, still need 3 of those, and then there is the timing parts,,, this is going to take a long time to print either way I go about it.

[webby2]

I think I am going to make a test-bed that does not go into a full continuous rotation but rather a reciprocating lever function.

This will make the parts smaller and easier to print, probably small enough for almost any printer to print them.

I could then take the output and run it through a mechanical rectifier if I feel the need to have a continuous input oscillation converted into a continuous output rotation.

[webby2]

Well,, that was frustrating.  I started the design and slowly got more and more carried away with until it was another huge elaborate part that would take 33hrs to print.

Next try

[webby2]

I am trying to design my test-bed so that it can be printed on almost any printer.

In going through this exercise I think I have figured out why my other test-bed was providing me with some funny values that I did not like.

In my system I can pass the work through the the system in several ways but basically I have two sides to the system.  I can pass the force value at a 1:1 or I can pass the distance value at a 1:1.

If I were to use one side as the input and pass the force value at 1:1 then the input side will pass 1N of force by a distance of 1m, the output side will provide for 1N of force by a distance of 2m, if then I were to use the output side to reset the system I would need to provide 1N of force by a distance of 2m to recover 1N of force by a distance of 1m.

If I were to use one side as the input and pass the distance at a 1:1 value then the input side will pass 1N of force by a distance of 1m, the output side will provide for 2N of force by a distance of 1m, if I then were to use the output side to reset the system I would need to provide 2N of force by a distance of 1m to recover 1N of force by 1m.

What I am designing right now is a partial system and so these exchanges can be easily observed but a full system provides for a unique situation where there is no reset required, the end of one exchange brings the next exchange into its starting position and since there is no work transfer being performed from the next system while it is not being used, only moved, there is no cost to moving it.

This is my concept anyway, so far it looks functional but I will not know for sure until I finish the test-bed.

[webby2]

So I decided on the fishbowl part and am now designing the table,, I am printing the fishbowl

[webby2]

Wellllll,,,

The table leg is going to take 84+ hours to print and it is 196mm x 252mm x 150mm
I say + because my printers do not always end up taking the same time as the slicer says it should take,, the printer usually takes longer

[webby2]

as the print goes on, and on,,,

If this does provide what I think it should then I was thinking that I could then actually cut the parts in half, only using one half would make the print size small enough for most printers that can go at least 150mm high.

A complete system is another matter all together, it has a few more parts, like 6 full subsystems,, I am only making a partial subsystem for this test-bed.

[webby2]

Still printing,,,,......
I have designed the other 2 parts I needed to and when my other printer is done with its print job I will print those so then all I have to do is assemble

[webby2]

still printing,,,,,........

[webby2]

This is really interesting.

My system breaks the pathway of the work transfer function, sort of.

I was looking at the rendering of my system that I am printing and noticed something that I thought was kind of there but did not overly think about it, so I took my current test-bed and set it up so that I only had a single interaction just to see if what I saw in the rendering was actually there.

The interaction of the input to the output has a force a path and a direction, several actually, and it is showing that a pull is not the same as a push, it is showing that if I wanted to have a longer distance of interaction that I would need to transition a pull into a push at the peak gain in leverage for the input over the output.

So, the system is showing in the real world that when the input is pulling the output through the beginning ramp up of leverage advantage it *appears* as tho the input is moving the output a further distance, it does actually in a sense, and then if I keep the input pulling on the output the input then is traveling a further distance than the output,, IF however at the peak I change the input force from a pull to a push while maintaining the same direction of interaction then the input is moving the output a further distance still.

Even tho I can see these changes the changes themselves are almost inconsequential to the work transfer from the input to the output, what I mean is, if I focus on watching those changes I can see them but if I only look at the rate of rotation between the input and output that stays as a constant 1:1.

This is getting to be really interesting.

I will have to wait until I have the test-bed finished to be sure but I think I will need to print another "adapter" part so I can change the input from a pull into a push but I should be able to measure a difference in distance between the two sides of the leverage function, that is as the leverage is growing up to a 2:1 compared to when it is reducing from a 2:1.

[webby2]

Still printing,,,,....

[webby2]

4 days 5 hrs and 42 minutes,, longest nonstop print I have done so far.

[webby2]

basic clean-up and parts fit, motions and all that so far are looking very good.  The input rotates 45 degrees for this test-bed and the output rotates 45 degrees as well.  When I try and continue the input as a pull past the point of change it rotates another 45 degrees and the output rotates maybe another 15 degrees, this behavior is what was predicted.

Even without all of the supports and lock pieces in place this test-bed is way more stable than the other one.
It looks like I am off on one of the contact surface faces, it should be touching but I have a gap of about 1mm or so, I may decide to print another face that closes that up,, I will see how it goes.

[webby2]

I am rather confused by all this.

The test-bed works fairly well as far as being smooth and all that so I think frictional losses and what-not are reasonable.
I designed this one to provide for up to a 2:1 and it is only a single tooth and only works for a partial movement.

When I keep the system still and pull on both of the spring force scales they will both most often read the same force, I can then allow the system to move and maintain that same force reading OR I can take the output side and increase the force while the system is in motion, if then I bring the system to a stop there can be a difference of force or it most often will drop back to the same values again.

I have not noticed the input side going higher while doing this, but I have not tried that way so much because the output side seems to make the change.  I need to work on that part more.

I have not yet actually checked the distance of motion but since both the input and output pull strings are using the same diameter pulley and they both are rotating approx. 45 degrees I am just assuming that they are moving the same distance.

When I move past the change position there is a large difference in distance of change and a large difference in force readings.

When I hook the 2 force scales together by themselves I can not get a difference in force readings whether I am moving them or holding them still.

So far I have been using about 600g of pull force on the input while allowing things to move and the output side will read a force of opposition of 600g and up to about 1.2kg.

This test-bed has not answered the question of how and why yet,, I was hoping that answer would just sort jump right out at me.

[webby2]

I am running with the assumption that I have some kind of bind situation occurring while I am stressing the system.
I can go from the start position and pull on both spring scales the same amount and make a motion maintaining a close value between both scales.  I can also choose which one I will pull harder on and watch its scale go up but see very little increase on the other scale, within a reasonable amount of increase, like 150g.

I "broke" one pathway with this build, I thought I might break the test-bed if I did not, I have since printed off a part that puts that pathway back into play and things appear to have changed somewhat in behavior.
Now I am printing off some parts to close up some slop.