Model Engine Maker

Help! => Hints, Tips & Tricks => Topic started by: MuellerNick on September 24, 2013, 09:46:39 PM

Title: CamCalc. The weird lobe-calculator
Post by: MuellerNick on September 24, 2013, 09:46:39 PM
Hi!


Since many years, I'm interested in the theory of cams (the lobes to be prices). I have written some programs for my own use.
About a year ago, I came up with a distinct way to calculate lobes. I couldn't find any references about my way. Only one, that was just half of my solution.
But thinking about programming it, I decided that it will be too much time-consuming.
So I gave up programming that.


Just last Saturday, I stumbled over a programming-environment, that seemed to offer some of the building blocks I would have needed. So on Sunday, I started programming. This evening, I finally got that crap running (the language is quite weird).
The result is quite crude and basic. It still is waaaaay off of my initial idea.


But, I decided to share my result with you. At least as it is now, it is of some help.


The language chosen is Pd or Pure Date. This is an environment for programming music, videos and Midi. Not exactly a match for physics and mathematics. hahaha.
BUT! The environment is free. Have a look at www.puredata.info and download the Pd-extended version.


So first, you need some instructions how to use my crap:
In the upper left, you'll find boxes (for numbers) named:
h (the lift)
Theta (the timing angle)
R (the base circle's radius
and rs (the tip radius)
These are the only fields where you have/should enter values (one more field later).


You enter values by clicking the box, typing the value and then hit return. Or you click inside and drag the value up/down (pressing shift changes the decimals).


Obey the field "resulting chest radius". Its value must be positive!


Now, you can play with your values to get a harmonic lobe.


In the topmost line, in the middle, there is a box titled "Cam angle". When you drag-change its value from 0 to 360°, you will get a (jaggy) plot of the lift. Currently, it will clip lifts above 6 mm. And the plot looks a bit crude. Think I'll make a loop around the math that will update the plot completely as soon as you change values.


Well, that's it for now!


Feel free to make the most nasty comments you want. I know, this is a sketchy hack.


Nick
PS: I have no clue wether up/downloading works. I'll hear! :)
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on September 25, 2013, 06:16:49 PM
Found quite some bugs. The language is too weird for me. But I'm trying hard.  :LittleDevil:


Here is a better version:
You no longer can slide the cam angle to get the graph. That only made a mess if you weren't sliding really slow. Now there is a button to click ("Click here ..."). And then you get lift, speed and acceleration. Haven't found a nice way to scale the graphs properly, so it will shoot out of the box sometimes.


Also cleaned it up a bit (and added more mess).


To be able to calculate speed and acceleration, you need to enter the cam-RPM (so that is half the crankshaft-RPM, just as a reminder).


Plan is to actually output G-code to mill the cam. There are two ways to mill one:
* Milling axis parallel to the cam-axis (simple to generate a code)
* Milling axis perpendicular to the cam-axis (more complicated unless you want to cut air for an hour).


Still, comments are welcome. Anonymous downloaders without feedback will be banned!  :LittleDevil:
Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: smfr on September 25, 2013, 06:39:11 PM
I haven't tried it, but I like the idea of sharing software that helps us compute machining-related stuff!

I think web technology is now at the point where most of the simulation/computation we need to do can call be done in a web page, for example my Joys Valve simulation: http://smfr.org/sim/joys-valve-linkage/ (http://smfr.org/sim/joys-valve-linkage/). This makes it super easy for someone to play with it, and the code is easy to grab and modify. I'm not sure how good you are with JavaScript, Nick, but maybe I can help you convert your program to run in a web page.

Simon
Title: Re: CamCalc. The weird lobe-calculator
Post by: tangler on September 25, 2013, 08:18:51 PM
Back in 1990 Bob Washburn published a Basic program of mine to calculate harmonic cam profiles in Strictly IC.  Ron Chernich picked this up and re-wrote the program in a web friendly form http://modelenginenews.org/ (http://modelenginenews.org/)  "Resources Design Center".  I developed my program further in QBasic but as this interpreter disappeared from distribution with Windows I've written the program as an Excel spreadsheet.  For what it's worth I've appended it to this message. There isn't any VB component so it should download without issue.

Rod
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on September 25, 2013, 10:22:14 PM
I don't like JavaScript. And I don't like client-side-programming (that includes JS). Only server-side because that's what makes the crap more independent (tested on IE$blabla).
And I won't do any server-side-programming, because I forgot all that crap (Perl).


I compared my results to the ones on ModelEngineNews.
Well … Geometry is the same, but velocity and much more acceleration do differ. I assume MY results are wrong. I'll check … OH wait! I do calc in cam-RPM. As far as I remember, values do match.


Note:
The values are not for rocker arms (one of the next steps) but just for … um … howsitcalled? We call them cup-pushers. The lobe more or less hammers directly onto the valve stem.


New version (I should have done something real in my shop):
Now, you no longer have to trigger the calculation of the graphs. If you drag-change values, things get a bit sluggish (had to insert a delay for all values to be calculated).
Still, I din't find a way how to resize the graphs so they fit. At least not a way how to do that with variables, only hard-coded constants (that makes no sense to me).
Also cleaned up some more mess (and added a little bit more).


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: AdeV on September 27, 2013, 01:41:51 PM
Note:
The values are not for rocker arms (one of the next steps) but just for … um … howsitcalled? We call them cup-pushers. The lobe more or less hammers directly onto the valve stem.

Overhead cam acting directly on the cam follower/tappet?

Do you include a clearance ramp in your cam profile? I've only just seen this thread & haven't had chance to look at/run your code yet; I'm just wondering if I may be able to use it on an engine I'm working on (not a model one...)
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on September 27, 2013, 06:49:26 PM
Quote
Do you include a clearance ramp in your cam profile?


Good point!
No, clearance isn't built in.
But it is the very next thing on my list of things to do.
As far as I have seen, the clearance ramp is left out in model IC-engines (I might be wrong). Basically, it is just a new circle a bit smaller than the base circle. I'll have to figure out the details, maybe this weekend.


How do you intend to mill the cam? In segments or with the spindle along the cam axis? For the later, a CNC is almost a must and you need to work with cutter compensation (makes the G-code simpler).


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: petertha on September 27, 2013, 08:04:46 PM
Be interested to see what you come up with Nick. I remember looking at some cam equations in an old engine design book a while back for (I think) harmonic cam profile generation, probably similar to what was posted here or Camcalc (which I never got to work properly on my PC). I dont recall though, is there any looping or math iteration/convergence type issues in developing the profile? Just wondering why plain old Excel would not satisfy the task assuming its crunching equations kind of linearly?

Sidenote: I'm in the process of drawing up a single cylinder design for myself as a starter IC project. I got looking at a bunch of model engine plans or reference & noted (so) many cams used simple [base circle / flat segment / nose radius lift] type configuration, generally running against a flat lifter. I have read pros & cons 'opinions' on cam profiles, ease of making vs. performance etc. So I just temporarily put the profile issue aside for now.

But a bigger mystery to me was how to phase intake/exhaust cams relative to each other. I compared designs & the timing seemed to vary all over the map despite similar engine types. I made a spreadsheet that considered these parameters. It spits out resultant cam phasing values, valve overlap, visual plot etc. I'm posting some screen caps as output example for now. I have to go back & check for boo-boos. Just providing a suggestion, maybe Excel could be considered for model cam design as its used widely?
 

Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on September 27, 2013, 08:19:17 PM
Quote
I dont recall though, is there any looping or math iteration/convergence type issues in developing the profile? Just wondering why plain old Excel would not satisfy the task assuming its crunching equations kind of linearly?


There is no, or better, there is no need for looping. To get the profile, a few equations are enough. Only to get the plot needs looping.
For me, Excel is no software to use. Users would have to buy Excel and I certainly am not among their clients. I have tried a spreadsheet from OpenOffice for other tasks, and I quickly realized that it is just an accumulation of odd features good for ... not for me!


To avoid further confusion, I will have to rename my cam-calculator. CamCalc wasn't the most brilliant idea. ;)
CamBam also isn't a good one. :)
For now, I'll call mine KamKalk, so it sounds kraut-isch. But I hope to find a better name.  :Jester:


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: petertha on September 27, 2013, 08:58:49 PM
For me, Excel is no software to use. Users would have to buy Excel and I certainly am not among their clients.

I suppose cost always plays into the decision issue. I use MS-Office every day at work & at home. My kids learn it in school. Now I see its bundled on tablets. If you use it at work, chances are very good you can get a highly discounted home licence, mine cost me $13. Looks like the full Office suite (Excel/Word/Powerpoint/Access) goes for 100-150$ depending on vendor & version.

http://www.amazon.com/Microsoft-Office-Student-1User-Download/dp/B00B1TGUMG/ref=sr_1_1?s=software&ie=UTF8&qid=1380310057&sr=1-1&keywords=microsoft+office

Kind of off topic, but since we are discussing 'hobby expenses'... I finally cracked & decided to buy a certain Bison chuck that I 'needed'. Altough already too expensive for my liking, I then discovered the current price was ~38% higher than catalog price from last year. I asked the dstributer why & they cited 'rising manufacturing costs in certain eastern block countries' . After confirming other distributers, I violated the piggy bank some more & made the purchase. Tools are an investment, right? Chuck was delivered, very nice. Then I noticed manufactured date stamping: year 2009! Apparently these items age like fine wine sitting on a storage shelf.
 :old:

For now, I'll call mine KamKalk, so it sounds kraut-isch. But I hope to find a better name. 
Nick

My surname is Thannhauser, I'm not offended :)
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on September 29, 2013, 02:29:08 PM
New version.


Added the clearance-thing:
You need to enter the clearance (labeled "clearance", now that makes sense!) and the clearance-angle. That angle is the length of the clearance-ramp (in degrees, obviously).
This results in two new values:
* New base-circle radius reduced by the clearance (the plain base-circle still is the mayor design-value and used for calculation of speed, lift etc.)
* Radius of clearance ramp. This radius joins the base-circle w. clearance and the flank-radius. These three radii are (as always) joined with a constant tangent.


Added a feature, that the number-field for the flank-radius (rho) gets red when it is negative. That works, but you'll get warnings that the field doesn't understand "color". Maybe it gets red because it gets so upset about that message?
Pay attention, the radius of the clearance ramp has to be positive too. I think it is always positive, as long as the flank radius is.  :thinking:


Also removed most of the sluggishness and things still seem to work!  :whoohoo:


I will have to increase resolution of the diagrams (now 0.1°), as extreme acceleration-peaks simply get lost. You get that, if the flank is very short and the flank-radius is relatively huge (compared to the base radius). This happens with short durations (less than 120° or so; depends on other factors too).


Getting no feedback is motivating!  :rant:
Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: steamer on September 29, 2013, 03:51:13 PM
Hey Nick

Sorry.....just haven't had time.....

I've used the Modelenginenews program and it works well.....but I don't program.

but I am interested the results!

Watching.......

Dave
Title: Re: CamCalc. The weird lobe-calculator
Post by: AdeV on September 29, 2013, 08:02:50 PM
Hi Nick,

Cool!! I haven't had a chance to look at it (either version!!!) yet, but then I am only just starting down this particular road...

I'm hoping to make my own cams for a racing car engine (Jaguar V12), which has 2 single overhead cam heads. I don't yet know how I'll make them; probably rough them on a CNC lathe, harden, and do a final grind on a CNC grinding machine - both of which I have to find & purchase...

I have a million other things to learn/do as well, so it might take me a while to get around to it - I have allowed myself 2 years to do this project.

BTW, for a name, how about Camtastic?
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on September 29, 2013, 08:24:37 PM
Quote
Camtastic


Great name!
But it is a "bit" of an exaggeration for the software. At least in its current state.  :???:
Major point is the user-interface. Or better almost complete lack of it. There is a simple way ahead. At least, that will remove all the boxes and lines that do make no sense to a user. This will be one of the next steps ...


Currently, I'm removing clutter and still trying to size the graphs.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 23, 2013, 06:00:44 PM
Long time no hear.  :'(


I stopped development of the prototype with PureData. And switched to Tcl/Tk. My first program with that language and that toolkit. Tcl/Tk is not so bad!
At least, it promises that I can compile for Mac, Win and Linux. Currently, I'm just interpreting on a Mac. So I can only give you screenshots (see appendix).
The scaling of the graphs still is a bit of an issue (doesn't fit perfect, just almost perfect).
(Dynamic) resizing is an other issue.


Code generation still is completely missing, but I wrapped my head around it further more.


Now, I like the name "CamTastic"! Thanks for the suggestion!  :cartwheel:


Enjoy!
Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 24, 2013, 04:45:04 PM
 :pinkelephant:
The graph is right now. Might find a better method for the graduations (that change with size). But finding the right intervals and start values by software is quite tricky. I'll leave it that way for now.
Added colored regions to signal the contact zones. Pale red is flank, pale green is tip (in case you don't see that at the acceleration graph.
Also, maximum acceleration is right now. There is no easy way to calculate it. Now I search for it (and find it to about 5 digits precision).


Got the idea to add "Lift area". This is the area beneath the lift curve. If you increase the tip-radius, the area increases (and acceleration). Also (obviously) if you increase the timing angle.


Also got a great idea for a modified harmonic lobe that will increase lift area substantially if you have left room for more acceleration but don't want to increase the lift. I wonder, why I didn't find that in the literature.  :thinking:


I'll add "(equivalent) weight", so the minimum spring's force can be calculated. That aint complicated at all.


And for the screen-shot ... if you find a typo, or things are named different, let me hear!

Edit:
Dont ask for imperial units. That won't happen.  :LittleDevil:
Enjoy!
Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 25, 2013, 12:26:19 PM
I actually managed to make an app out of it. As long as you are a happy Mac-owner, it runs (or it should).  :old:
That's not at all the final version, but you can already play with it (fixed a bug where I confused flank radius and ramp radius).
Also added parameter checking, so it should get harder to make hang the app.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 25, 2013, 07:29:39 PM
Does anybody care?


Well, I do! I implemented the idea about the modified harmonic lobe. It now is a harmonic lobe with a plateau. Not that the physical lobe has a plateau, but the plot of the lift has one. The lobe has a circle touching the tip radius and that circle is concentric to the center-line.


Say you have a given lobe with some certain timing:
By adding a plateau (without trying too long), you can get almost 5% more lift are but still keep the maximum acceleration. With more tweaking: 17%


I made 4 screenshots. You'd have to study them for a few minutes to see the difference.


"No feedback is bad feedback"


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: stevehuckss396 on November 26, 2013, 01:14:33 AM
Sorry for not commenting Nick but to be frank I have no idea what good or bad data is.

Timing angle I assume is the same as duration
I have never heard of plateau angle
Tip radius i assume is nose radius
Clearance and clearance angle?
Max and min acceleration I wouldnt know a good number from a bad number.

Sorry buddy but i suspect the lack of feedback is due to the fact that you are working beyond mine and most peoples understanding. I respect what you are doing I just dont understand it.
Title: Re: CamCalc. The weird lobe-calculator
Post by: petertha on November 26, 2013, 01:51:52 AM
Couple questions Nick (I haven't downloaded)

- if one wanted to evaluate a flat side cam for comparison (to harmonic), is this be a non-starter for your program because it is confined to harmonic input parameters & shape development?

-presuming a typical harmonic cam output profile, does this completely remove the issue of tappet bottom profile & cam tangency? My understanding is with harmonic it doesn't matter if the tappet bottom is flat or curved or roller etc, it will always 'open' & 'close' at the defined angular input values? Hopefully this makes sense, I'm talking about the situation where a flat bottomed tappet edge can 'dig' on a (non harmonic / flat sided) cam profile & thus lift prematurely & (suspect also) remain open longer. I thought I read somewhere with a properly developed harmonic profile, this can't happen, its always tangential contact between tappet & cam.

- is there any way to develop or evaluate typical ring gear cam lobe profile like on radial engines with your tool? Or is this involve a different algorithm?
Title: Re: CamCalc. The weird lobe-calculator
Post by: stevehuckss396 on November 26, 2013, 02:19:41 AM
I'm talking about the situation where a flat bottomed tappet edge can 'dig' on a (non harmonic / flat sided) cam profile

Have you given thought to calculating the minimum diameter lifter so this cannot happen?
Title: Re: CamCalc. The weird lobe-calculator
Post by: petertha on November 26, 2013, 03:30:49 AM
Have you given thought to calculating the minimum diameter lifter so this cannot happen?

Hi Steve. I think I worded my sentence poorly. Personally I don't think a flat bottomed tappet + flat sided cam profile make a very happy marriage because of edge rubbing & related off timing issues. I suspect a dome shaped or radiused tappet bottom might work better & more what I was wondering about. I've seen this configuration on some model engines. If the program facilitated entry of these parameters a guy could compare valve timing & information on the plots. But I suspect I already know Nicks answer.  :)
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 07:41:53 AM
OK!


I think, I'll answer in two or three posts.
1: Namings


Timing angle is duration. Should I change to duration? Others agree?
Tip radius is the radius on the tip of the lobe. If it is called "nose radius", why isn't the flank radius called "chest radius"?
Plateau radius: Well, if someone ever heard of it, than that's because I invented it a few days ago. This never existed before (well, at least I don't know of its existence). This is a modification to the classical harmonic lobe. Take a harmonic lobe, cut -at the very top- a slit down towards the center, bend both sides sideways and insert a radius into the gap. That radius is tangential to the tip radius and concentric to the camshaft's center line.
Clearance + clearance angle: A valve train needs clearance. So that's what it is for. If you design a harmonic lobe without clearance (and that's what the basic design exactly is), the valve/rocker/poppet will slam against the flank radius at the moment the lift starts. That clearance thing just adds a ramp to make that start of lifting smoother. It takes the base circle and subtracts the clearance (two times clearance for the diameter). Then, with that slightly smaller "base circle" (that no longer exists in the physical lobe) it adds a connecting radius from the base-circle-with-clearance to the flank. Both ends are connected tangential again. The clearance angle defines the length of that ramp.
Cam-RPM: There are two ways to display the speed and acceleration graph. One is with 1/rad, the other with m/s. The first one doesn't need RPM but the value is "useless" without further calculation. Maybe you don't care about speed, but acceleration is essential. If you double the cam-RPM, acceleration will be four-fold as big. Speed only twice.
What does that accel-number say? You can calculate the forces from it. Both for opening the valve and for closing. That's interesting, because you then know what force the spring has to have.
The formula is easy: F = m * a
F: Force in N (Newton)
m: mass in kg (kilogram)
a: acceleration in m/s^2
9.81 m/s^2 is the gravitational acceleration. So if the maximum acceleration is 10000 m/s^2 and you want to move 0.1 kg of mass, this will require a force of 1000 N. 1000 N is the force of 100 kg (that is not scientifically right! Mass and force are distinct things. But that way, it is easier to grasp for the common people).


I'll come back with lobe geometry (tangential lobe, harmonic lobe and jerk-fee lobe in about 45 minutes).
Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 08:32:54 AM
So!
I have cigarettes and a fresh cup of coffee!  :cartwheel:


Let's look at different lobe shapes ...


But first, we need to know the basics. They are simple (and maybe you already know them) but they are fundamental.


What is distance? Well, if you don't know that, I give up. ;)


What is speed? Speed is change of distance (or way traveled) over time. If you need half the time for the same distance, you have twice the speed. When the unit for distance is m, the unit for speed is m/s. Yep! Distance over time.
Or, in other words: Change of distance over time.
You get much speed, if distance changes suddenly.


What is acceleration? Acceleration is change of speed over time. So if speed was m/s, acceleration is m/s*s or m/s^2. Easy, eh?!
You all know acceleration from your car (or at least, you dream of it having some acceleration). You all know, that the you harder you accelerate, the more forceful you are pressed into your seat. Deceleration is acceleration in the "opposed direction" or just with a minus sign.
You also know, that it is not speed that kills, it is the sudden change of speed that kills. It is the deceleration that kills (or ruins your valve train).
You get much acceleration, if speed changes suddenly.


What is jerk? If you look back in this posting, and remember how I came from distance over speed to acceleration, you can predict what jerk is. Right, it is change of acceleration over time. So acceleration was m/s*s, jerk is m/s*s*s or m/s^3
Now is it worth thinking about jerk? Yes and no. The influence the jerk has on lobe design is almost just noise. Modern engines have to be quiet, and non-jerk-fee-lobes do make more noise. It also might have some influence on fatigue failure of the valve train. But we certainly can ignore that.
You get much jerk, if the acceleration changes suddenly.

In other words, and looking back over jerk to acceleration, speed and distance, it all is the quickness of change of the previous one.

Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 08:53:55 AM
So, did I forget about the lobe shapes? No.


There are three main shapes of lobes:
Tangential, harmonic and jerk-free.


We will ignore clearance here, it has no influence on selecting the lobe. Imagine you just file off a bit from the base circle.


Tangential: You have a base circle, a tip circle and both are connected tangentially.
Harmonic: You have a base circle, a tip circle and ... (you have to kinda remember the distance-speed-acceleration thing from above) ... both circles are connected with an other circle. All circles to touch each other tangential.
Jerk-free: Well ... if you remember the previous post and look back to harmonic and tangential, you will maybe realize what this is supposed to fix:
The tangential lobe has a sudden change of radius if you follow from base circle to flank. In fact, the change is infinite, as a straight line is a circle with infinite radius. Then going from flank to tip, you once more have a infinite change of curvature.
The harmonic lobe is smoother in that respect. It also has a sudden change in curvature (or radius), but at least it doesn't change to/from infinite.
So if you look at that point where the base radius and the flank radius are connect (in the harmonic lobe) ... how about cutting out a short piece and insert a radius that is bigger than the base circle's and smaller than the flank's? And after that, once more cut out a small part where the just inserted piece connects to it's neighbors? And repeat that until you get bored? That's what the harmonic lobe does. It smoothens the transition between sections. That's done with parts of a sine-curve or spirals or whatever helps.
I bet, that there are a lot of jerk-free designs to find. But literature about that is damned hard to find. I do have a thesis about the math for jerk-fee lobe design. But simply put: The writer must have been a jerk (pun intended). The math blows off your head (at least mine, that's way beyond from what I can understand).


This is an hidden answer (needs more reflecting, but I'll come back to it if I don't forget): The tangential lobe is is a harmonic lobe with an infinite flank radius.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 09:32:03 AM
Now, we will come into a dark area of my CamTastic and all the other cam-design programs that are free. It is the valve train that they all ignore.
Valve train is the link between the lobe and the valve's stem. You might drive the valve directly (with a poppet in between). You might have a rocker arm, you might have a poppet then a push-rod  and then a rocker.
The rocker arm itself might have different shapes: You can have the pick up side flat or curved. That curve might be off-center or not. It might have a big or a small radius. It might also well be a more complex shape. And the driving side also might have different shapes.
As there are so many possible configurations, I just ignore them. I once thought about a software that can handle that, but it would be absolutely $$$ and not at all for the hobbyist (that includes me).


But there is a simple or partly ignorant answer: The valve train can solve some problems that you get from a tangential lobe. But also, it most often will distort the plot of the lift at the valve. It even might distort the lift asymmetrical. Again, that's a complex story and you better ignore it (with one exception).


Back to the hidden answer "The tangential lobe is a harmonic lobe with infinite flank radius".
First conclusion from it is, that CamTastic can compare a tangential lobe and a harmonic lobe. But just almost! As CamTastic assumes a flat follower (flat poppet), the resulting acceleration would be infinite. You can not (currently you can, but that hangs CamTastic) get a infinite flank radius. You get that, when tip-radius + lift >= base circle radius. So if you enter a tip radius that is close enough to that limit, you *almost* get a tangential lobe.
Second conclusion is, that a tangential lobe doesn't work on a flat poppet. You will get infinite acceleration ("It is not speed that kills, ...") and the tangent will simply hammer against the flat. A tangential lobe only works with a rocker (with a curved pickup surface) or a poppet with a curved surface.


And yes, the minimum poppet width can be calculated. I'll add that (for a flat poppet).


I *hope*, that I have answered all questions. If *your* answer is missing, please feel free to repeat it. I won't get embarrassed at all!


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 09:43:45 AM
Quote
You get that, when tip-radius + lift >= base circle radius.

Edit: Screenshot and numbers didn't mach, so I fixed them...

Well, that aint' true I think. But, by increasing the tip radius, you will find the hot spot. That's when the flank radius snaps over to negative (that is not allowed in CamTastic).
I made a screen shot. The resulting flank radius in that example is 70907 mm (70 m) so that is almost infinite compared to the other dimensions.
But you also see, that the maximum acceleration is about 12.5 million m/s^2. That is about 1.2 million times gravity. "1 kg suddenly weights 1200 tons"
Also, the graphics fail to display that extremely narrow and acute peak of acceleration. The software find the peak, but the plotting routine simply misses that point (it only calculates values that are one screen pixel apart.

Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 10:34:23 AM
<Steve Jobs> "One more thing! </Steve Jobs>


All these diagrams are a bit useless, as long as you can't draw consequences out of them. And one parameter that is very interesting is the required spring!
I'll plot a graph of resulting forces from acceleration and a graph of the spring's force (assuming a linear one), with the values of force on the base circle and force on the top of lift. With know travel, that gives the required spring constant and the required compression from the spring's length in relaxed state.


And from these forces (spring and acceleration), there is an other interesting value to be derived: Area pressure (in German: Hertzsche Flächenpressung, can't find my technical dictionary). It depends on force and radius of the surfaces. If you have a small radius, the area pressure increases and might lead to failure of that surface (pitting). Cam followers are often hardened and ground. With area pressure, you know what you have to expect.


TBC ...
Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: steamer on November 26, 2013, 10:36:04 AM
Nick

I'm going to be off for a few days after today.. so I will be reading up....
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 10:52:16 AM
<Steve Jobs> "One more thing! </Steve Jobs>
An other interesting parameter is average lift. It is the lift area divided by duration. The higher the average lift, the more you get through the valve. Average lift is always less than lift. That's obvious.
You need that value, in case you want to flow-bench your port. Just measure and compare with the valve opened by the average lift.
That number is similar to the lift area, but is easier to grasp. If you add a plateau, the average lift increases (as does lift area) without increasing lift.


An other pro for the plateau:
With it, you can go down with the lift. One advantage is, that the valve maybe does no more hit the piston, the other is better flow at the valve's tulip (is it called tulip?) when the valve is full open.


Hope the ideas stop flooding in.  ;)


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: Admiral_dk on November 26, 2013, 06:37:31 PM
Very interesting, though I'm not thinking about Four Strokes now (have been preoccupied with workshop, lathe and other projects) and the fakt that I only program in Assembler, Basic or Pascal - but I'll try a comment or two.

Looking at your screen print - those sharp angled "edges" looked wrong, so I googled "speed profile harmonic cam" and found some examples and though they more or less looked like yours, it dawned on me what I thought was wrong (in my mind). I we look at your first cam profile on top of this page (2) - I would like to see a speed profile looking like a full 360 degree sine, with the start of the sine starting at the start of lift, max speed half way up the lift and down to zero at max lift, followed by max "negative speed" (opposite direction) at the half closed state and back up to zero where the valve closes. This would give us a accellearion curve being Cosine => starting at max accelleration going to zero at mid lift and down to max negative at max lift, back to zero at half closed and max accelleration at closing. Obviously we can't start or stop with max accelleration, so we'll have to have a more gentle start and end acelleration curves and this will also modify the start and end of the sine curve.

I'm also aware of the fact that we don't do negative speed, so that will modify both curves as well. Now yours look more the part, although to abrupt in the transitions.

You're right about the fact that all of us who end up making a spring closed valve will have use for this program. But for that to work, you'll have to include the weight of the valve + spring + cap etc.
That then brings the last possible and very interesting calculation max flow through valve. That requires diameter of the stem, head and seat in addition to the rest of the data you already requested. The result could point to too much or too litle amount of gas to the desired rpm for our engine.

I'm not sure that any of this helps you - but it cleared my mind a bit on the subject  ;D
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 08:50:58 PM
Quote
I would like to see a speed profile looking like a full 360 degree sine,


Simple answer: You don't get that with harmonic lobes. Maybe you read (again) what I wrote on the previous page.
I'm sorry


Quote
But for that to work, you'll have to include the weight of the valve + spring + cap etc.


Why "but"? If you want to *know* the force required, you have to give these values. If you don't know them (too lazy to use your scale? CAD doesn't calculate volume?) you wont get that answer. CamTastic has no built in crystal ball. It calculates but doesn't guess.
I'm sorry.


"How do I get to this place?"
"To *what* place?"
"I dont know"
"F*ck off"
I'm sorry.


Quote
That then brings the last possible and very interesting calculation max flow through valve.
CamTastic is a lobe designer, a designer for harmonic lobes, not a digital flow-bench. And it never will be. Buy a flow simulator package for your CAD and you will know why.
I'm sorry


Honestly, I have very little understanding for your posting.
Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 26, 2013, 09:45:17 PM
And here is a screenshot with both windows: The main window, and the "Forces window".
If the resulting force from acceleration exceeds the spring's force, that area is hatched red to signal a fault.
I had to use quite funny values. That spring is more than odd (but I'll re-check the values).


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: dieselpilot on November 26, 2013, 10:40:59 PM
Interesting work Nick. Area pressure is probably contact stress which results in fatigue failure? Real life valve train is very complex. Models can use simple cams and run just fine you just don't want them to wear out to fast. I don't understand talk of valve time area for an engine that will never do much other than an shaft run.

An interesting read if you like valvetrains. The Right Lift. (http://www.profblairandassociates.com/pdfs/The%20Right%20Lift.pdf)

Greg
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 27, 2013, 08:15:33 AM
Hi Greg!
I looked it up, it is called "contact pressure" in English. You are right, for a slow running engine that will maybe just run 100 hours during its life, it is of no interest. For a high rev engine that should output a lot of power, it is interesting. The more you go to the extreme with the timing, the more stress you get.


That link is great! I partially read it yesterday. What they did there, is part of my idea I had. But as I said, it is way too much work. Especially when unpaid.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 28, 2013, 10:19:39 AM
Next round ...
That "resulting forces" window from above was quite wrong.
The thought that I can calculate the unloaded spring's length was a brain fart.
And the resulting forces from acceleration were the wrong way round. Oh well ...


Anyhow! I implemented the Hertzian contact stress (http://en.wikipedia.org/wiki/Hertzian_contact_stress) graph. And it is much more interesting than I thought. Initially, I considered it as a gadget, but now it is extremely helpful.
Why? If you chose the design parameters in such way, that you get a big flank radius, the acceleration on the flank jumps upwards to frightening values. And you might think that that won't work. BUT! Hertzian stress goes down when the radius goes up. And that helps tremendously to reduce the stress at the flank. In fact, it decreases!


See attached screenshot.


Next, sort out all the glitches with window handling. At least, if you change values in the main window and recalculate (or press <Ret>), the forces window gets updated.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: stevehuckss396 on November 28, 2013, 01:08:43 PM
After the program is complete are you going to have tutorials on how to read the graphs and what all this data means. I would like to learn how to read and manipulate all this data for use in the engines I build.
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on November 28, 2013, 01:25:10 PM
Quote
After the program is complete ...


Slow!
It ain't complete. I have fixed most of the windows handling issues. I'm in the middle of File: Save/Save as/Open. I'd like to have several worksheets open (compare lobes side by side; but that is on the end of the list). I'd like to add a graphical representation of the profile.
And I need to add the g-code part!


For instructions, I'll just copy my postings here and make a PDF out of it and be done! :)
Yes, there will be instructions. No, I will not give any tips what duration and lift and overlap and whatever for what engine.


Forgot:
I added "Kld". Thats the ratio between opening area of a square shaped lift and the actual lift. That was inspired by the article dieselpilot linked to.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 02, 2013, 10:43:26 AM
Finally got that clearance ramp working.  :wallbang:
The literature I have, has a formula for the radius of the clearance ramp. I double checked the triple check, but still, the result of the radius was wrong. Then, I searched the error on my side and tried to figure out wether I misunderstood something. I tried to match both ends (pun: the end of the flank and the end of the base circle w. clearance) but never got that working. I also made the error, that there must be a way to get a radius for the ramp that connects to the other radii tangential.
Until I decided and realized that there is no radius on earth that connects tangential on both ends. And that the formula in the book is simply wrong.


So I finally got that running!  :whoohoo:


I also changed the name (for the last time?), as "CamTastic" was already used by two companies. I changed it to "CamCulator", like "Calculator", with the "m" just one letter off to the "l".  :thinking:


Here is a screenshot of the lobe view (with extreme values to better show the ramp). I have drawn a red circle where flank and ramp touch each other. The red dashed circle is the base circle (w/o clearance).


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: stevehuckss396 on December 02, 2013, 09:32:45 PM
So what do we (by we i mean you) have left to do before we release this thing to the beta testers (by beta testers I mean me)
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 03, 2013, 01:54:34 PM
Attached is a comparison of two lobes.
Both have the same duration. But one is with a plateau angle of 10°.
The one with plateau has a Kld of 0.645, without plateau the Kld is 0.573. What does that mean? 12% more throughput. The interesting thing is, that the maximal Hertzian contact stress is NOT increased.
So without changing duration and without changing lift and without higher stress, more power.
Even more interesting is, that the Hertzian contact stress at the flank is in fact being reduced, albeit the acceleration jumps up from 1026 m/s^2 to 2456 m/s^2
So, once more, the Hertzian contact stress is an essential design parameter. Just looking at acceleration will lead you to wrong conclusions.


Next step is generating G-code. I'll have to make some GUI-decissions and machining setup decisions.
Currently, I think I'll provide single lobe milling with the C axis parallel to the cam's axis. And the other one with an A axis. The A axis requires a "stitcher", so you can arrange different lobes (intake and exhaust) along the camshaft.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 03, 2013, 11:59:01 PM
Here is a screenshot of the dialog for generating G-code. This one is for the Z-axis parallel to the camshaft, no rotary axis involved.
I think, I'l have to add wether IJ for G2/G3 is absolute or relative. I will hear.
I'll add a picture for clarification. The code generated will make some air cutting while roughing. But I think defining the stock is more embarrassing than waisting a minute of machining time.


I think, I can cover everything with that dialog. Machining will work with G41/G42 (cutter compensation), so no need for the diameter. Any deviations in dimensions can be adjusted at the control. No, there won't be a PP for Haidenhain etc.


Tried the program on Linux in a tcl-shell and it worked. I just need to add a bit of code to adjust the accelerator-keys (Ctrl-S or Option-S etc.)


Currently have about 1600 lines of code. I'm starting to like Tcl/Tk. :Love:


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: stevehuckss396 on December 04, 2013, 12:06:52 AM
 :ThumbsUp:
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 04, 2013, 08:23:16 PM
Honed the G-code generating dialog. Some fine-tuning is left, but I'm quite happy with it.


If you look closely at the "Post-roughing cmd.", you see in the third line a "G00 $EndZ".
Now look at the left side of that screen shot at the generated G-code (well, *there* is work left!) what happened to the $EndZ! Yep! It was substituted with the value of End-Z And that is 30.0
Not sure wether that is useful, but I think it will be. Future will show.

Maybe I'll get that to make the first useful farts and try machining at the weekend.

I'll have two beer now!


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: tangler on December 04, 2013, 09:31:13 PM
I'll have two beer now!


Nick

That'll explain the farts then
Title: Re: CamCalc. The weird lobe-calculator
Post by: Jo on December 05, 2013, 08:15:10 AM
 :facepalm2: German beer all gas  :disappointed:

Jo
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 07, 2013, 10:43:45 AM
Roughing (in 3 layers and 4 rounds) and finishing.
Sample code with roughing and finishing combined.


Next: Machining with a rotary axis with the spindle perpendicular to the cam's axis.
There are two strategies:
Machining with facets.  Good for roughing.
Machining with the spindle right above the highest point of the arc. When milling, that works only if the mill's face is reground (normally, the face is concave), otherwise, the flat doesn't get flat. Also, there is zero cutting speed at the mill's axis.
This will end in a lot of "G1 Yxx Zxx Axx Fxx"


For facets, I envision an adaptive method that obeys a maximum/minimum angular and vertical (Z-axis) movement. Because with a fixed angular increment, flanks with a big radius get a bit crude and at the nose with a small radius, a lot of time is wasted.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 08, 2013, 03:32:57 PM
Still filling paper for the "Cam perpendicular to Z"-process. So nothing to show.
But I improved the GUI. Added the lead-in move and the compensation move (for cutter compensation).
Also added a "loop end cmd." to roughing. You could have an M1 here (and measure and compensate). But the main reason was to use it for grinding. Grinding wheel in the spindle, and with the loop end command, you could call a dressing cycle. Most controls allow to call a subprogram/macro. Here you could dress the wheel and make the compensation for diameter. To avoid dressing after each round, you could toggle "option stop" or how your control calls it. A counter would be helpful (insert command every n-th loop), but future will show.


Almost decided to add axis substitution in the Settings tab. This would allow fancy setups or machining in a 3 axis lathe or 3 axis cylindrical grinder.
2-axis lathe and 2 axis grinder is more complicated and I haven't made up my mind yet. Both lathe and grinder would require spindle orientation. So I guess, the need for that feature is a bit on the lower end of the wish-list.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: AdeV on December 08, 2013, 09:04:42 PM
Hi Nick - any chance this could output DXF format files? Seems to me that I could use it with CamBam then, instead of having to write something to reverse engineer your G-code into something my Heidenhain could eat....

Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 08, 2013, 09:35:08 PM
Quote
Heidenhain


Buy the G-code option!  :hammerbash:  +  :LittleDevil:
DXF should be plain easy. At least in principle. I have never looked at DXF, but isn't it something like HPGL? Just lines and arcs with start and endpoints and so? I'll have a informative look at WIKI.
The drawing routine for the lobe sketch works this way. I have a set of arcs and I plot them (after having written a wrapper around "DrawArc").
I'll put that at the end of the list. And if it gets dropped off, feel free to remind me!


I'm just writing the code for facets-machining (preferably for roughing). Found a nice way that doesn't use constant angular steps, is plain easy to understand for the user and that adjusts itself to keep the error at a given level.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 09, 2013, 10:40:49 AM
I looked at the DWG-definition. Or TRIED to. O!M!G!
A pile of versions and missing definitions and pointers and words and dwords.
Looks like one has to buy a library.
I can dump a file with all arcs, their centers, their starting angle and the ending angle. Than you would have to redraw that in some CAD that can export DWG/DXF.
I don't know how CamBam does it, but my bet is he spent some money. While searching, I have read that the free libs are unreliable.




Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 12, 2013, 01:11:55 PM
Roadblock:
LinuxCNC doesn't display the cutting paths in a useful manner when using a rotary axis (strange: I think it once did?!).
Anyhow, before cutting precious metal with the same worthless code over and over again, without seeing where the error is, I wrote a G-code interpreter.  :insane:
A PRIMITIVE one! But it does understand G00, G01, G02 and G03


First picture: That's a sign error in the simulator when transforming a point with the A-axis rotated. But it looks artsy.  :Lol:
Second picture: Slap on my head, error found and fixed: Roughing in 3 passes with adoptive facets (error 0.1 mm). At least, it should be. Well, I can work from that on ...


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 13, 2013, 09:26:58 AM
On with the monolog ...
Since my PrimSim works (as much as I need to debug the G-code), I was able to fix the problems in the screenshots shown in the previous post.
They were:
Too much travel (cutting air). But in these pictures, the tool diameter was 10 mm, so it needed more travel sideways.
Rapids inside of the stock.


First screenshot:
Polygon error (I'll explain that later) 0.1 mm. Tool diameter 0.1 mm, just to show that the cutter stops right at the end of stock. 27 facets generated.
Where I have drawn the solid red arrow, it looks like there is a rapid inside of the material. But that's my laziness with PrimSim. That is a rapid just of the A-axis and in fact, I should display it as an arc and not a straight line. So no cutters harmed.
In this picture, you also see a blue circle. That's the stock. PrimSim knows it with the statement "(!PrimSim 32 )" that you can see in the third line of the G-code in the G-code window in the left. PrimSim is just 460 lines of code.
For debugging, I have added the parts just being cut (like "(rampArc)") as comments.


Second screenshot:
Polygon error 0.01 mm. That makes 79 facets.


Polygon-error explained:
When cutting a circle with facets, you can't get a perfect circle. Except you have unlimited time. If you cut a circle with 10 mm diameter and 4 facets, it will get a bit bumpy. In fact, the biggest error with four facets in this example is 2.07 mm. This deviation from the perfect circle is the polygon-error. You might call it speed-bumps. If the polygon-error is 0.1 mm, the speed-bumps are 0.1 mm high. If it is 0.01 mm, they are 0.01 mm high.
When generating the G-code, CamCulator looks at the radius to cut and adapts the angular increment, so that the speed-pumps are exactly as high as wanted.
If you set the polygon-error to 0.001 mm (if your equipment actually works that precise), you'd get 237 facets with the lobe of this example.


In a lobe milling program that I once wrote in LinuxCNC, I used constant angular increments. And that became quite slow. With the polygon-error, you have precise control over the result and get the shortest machining time possible with that method.


Next, milling with the cutter over the top of the arc (that is easy, I think as for now) ...


Nick

Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 13, 2013, 11:29:31 AM
Quote
Next, milling with the cutter over the top of the arc (that is easy, I think as for now) ...



It was a piece of cake, if you look at the time I made the previous post.


What is "over the top" machining?
If you machine a circle that is coaxial to the rotary axis, the spindle is right over the rotary axis. As soon as the radius is off-center to the rotary axis, the highest point of that circle is moving off-center, depending on how much the axis rotates. At the extreme, the spindle is offset (in Y with an A-axis) by the off-center-nes of that circle.
So while rotating the axis, the cutter moves by a calculated amount to keep over the top. Or you might also say, the cutter is always over the center of the arc being cut.
If you look closer to the screenshot, you see that the cutter moves back at the point where flank and ramp meet (that's at 45° from the vertical in this example). That is, because the center of the flank's arc is far off from the cam's center. The center of the ramp's arc is quite near to the cam's center. The base circle is concentric to the cam's axis.
Here too, the movements seem to be straight. But they are arcs, as the cutter moves left/right and up/down and the axis rotates at the same time. Just look at the G-code. Don't know what the resulting radius is without stressing my brain. But I think it aint worth investigating. Because the increments can be made very small. For the CNC, that's just stressing the look-ahead and it increases code size. That only wears out some more bytes of the control's memory


Nuff for today I think.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: dieselpilot on December 13, 2013, 02:19:02 PM
That's fantastic. My only concern with the continuous motion is that the user would have to be certain they have a center cutting endmill, no brainer really. Even so, most center cutting endmills do not have axial cutting edges which are perpendicular to the axis, but slightly relieved (1-2°?) so the center is higher. I guess the error would be small enough not to worry about. I wouldn't go as far as saying it would give the desirable angle on the cam to help rotate the follower, but maybe.

I may have to give this a try, but I need to sort the runout in my 4th first.

Greg
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 13, 2013, 02:45:07 PM
Quote
My only concern with the continuous motion is that the user would have to be certain they have a center cutting endmill,


That's right. I wrote that some postings before. And yes, they normally are concave. More like 2…3°. That would have to be a reground one. If it isn't you will get a roof shaped lobe. That only helps to wear it. It doesn't help in rotating the follower.
If you want to rotate the follower, the procedure is to offset the cam slightly.  Means: If the lobe is say 6 mm thick, the center would be at 3 mm. But you don't have that center over the axis of the follower, but a bit shifted to one side (maybe 0.5 mm). If you need a sketch, let me hear, it is really simple.


That "over the top" method helps a lot in grinding. But currently, you would waste a lot of time. I have thought about the requirements for the GUI to make that effective. It is not that much work. And then, it's usable for milling, then grinding. Usually, you mill, then harden/temper then grind (with a given allowance). That will work when I made the modifications.
But that will require generating code for two separate setups (just one checkbox and a new value). Also, these mods will allow for sparkout. Made up my mind on that.
Also decided, that something like dressing the wheel during grinding is useless. If you need to dress in-between, you are making something quite wrong with your wheel.  With a grinding allowance of say 0.5 mm, you will have 50 rotations of the camshaft and be done. And if the wheel clogs (?) up in that time ... see above.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 15, 2013, 10:15:03 PM
Path of "Over the top" and "Center-aligned" overlaid.
The curve with the bump looks completely wrong. And that's what I thought for a whole day. But it aint.
If you put a transparent drafting triangle over it, one edge aligned with the center of the cam (that's where the vertical red line starts) and and the 90° edge at the point of an arrow, you will see that a cutter with even an infinite radius (I had 200 mm here) will cut at a completely different place than intuition tells you.
I'm only having problems with finding where to switch to the next arc. But I'll find that one too. After I saw how easy it was to get the angles for a grinding disk touching an other radius.
Yes, the contact point is really easy to get with a compass, a ruler, a pen and some paper, but I made a huge mess with the math. Until I realized what curvy path I took. "Senior moments".


I'll verify some points of both methods in the CAD!


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: dieselpilot on December 17, 2013, 06:31:47 PM
I did CAD verification when we had the last thread about CAM software (maybe the other site). I think the hump looks about right if your trace is the cutter edge. Good stuff.  :cheers:
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 18, 2013, 09:36:23 AM
I'm still puzzled by the results I get from "center aligned" machining. That's where the grinding wheel/circular cutter is over the center-line of the rotary axis (without movement in Y or Y = 0 and just going up and down in Z). This has to consider the wheel's diameter.
That is supposed to work with any wheel diameter. But the numbers I get are just almost right. I don't think it is too complicated.
But as it looks, I have to go over the math again. Maybe that will take until the weekend (to find my dumb error).


After that:
Axis substitution (Z -> -Y; X -> Y etc)
Feed and speed to config (with $speed and $feed in the templates)
Feed for over the top and center aligned machining (vectors in Y-Z-plane and radius relative to CL of A add up; a big flank radius would result in too big a feedrate if it would be just given with a general feed, so each move does require its own feed: "G01 Zxx Axx Fxx" with a calculated Fxx)
Rethink how many templates I need. With the different machining methods, that can get confusing. That is more a problem how to organize it and still be transparent to the user.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 22, 2013, 03:30:17 PM
Quote
But as it looks, I have to go over the math again. Maybe that will take until the weekend (to find my dumb error).



Found the bug the day before yesterday. Also filled some code voids and fixed a lot of display/windows-handling issues...


Getting better!


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: stevehuckss396 on December 22, 2013, 04:52:37 PM
awesome!

When will there be a beta ready for testing?
Title: Re: CamCalc. The weird lobe-calculator
Post by: Jo on December 22, 2013, 05:02:45 PM
:lolb: Poor Steve, Nick you keep dangling that so, so tempting calculator in front of him. Maybe you could put your father Xmas hat on at some point  :naughty:

Jo
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 22, 2013, 05:45:52 PM
Quote
[size=78%]When will there be a beta ready for testing?[/size]



In the many years of my professional software-development, I learned one thing: Never give a date when the work will be finished.


Current state is:
The main window (with lift, speed and acceleration) is stable and I no longer get it to hang.
The window with the forces from valve spring and acceleration works.
The window with the lobe sketch works now (again). I simplified the code and the graph now properly centers. I'll add some eye-candy (I guess today).
These three windows interact with each other properly.


G-code generation is the place with lots of detail-work (but essential details) is left:
Some parts only work CW or CCW, some ignore the plateau. Grinding and milling isn't implemented (only milling, but that once was grinding, so I had that code already. The difference is not complicated). That's "only" adding "a bit" of code (without breaking the one that works). The stitcher-part is completely missing. That will require saving all setting. And that works just *very* rudimentary.
Currently, G-code generation is a stand-alone-program. That makes debugging for me much easier. But also makes the program kind of useless.


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: steamer on December 22, 2013, 06:14:44 PM
Hey Nick!.....this is turning into quite the program!.... :praise2:

Have a Merry Christmas!....

Dave
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on December 23, 2013, 03:18:27 PM
Here is something to laugh!
Facets-cutting method with a plateau. I didn't expect it to be **that** wrong.  :ROFL:
Without plateau, it (still) works. CW and CCW.


Merry X-mas!


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on January 04, 2014, 09:21:59 PM
Don't worry! Project goes on, but I took a few days off.
In the meantime, I have improved PrimSim. Now, I can click on any line in the graphics. Then that line flashes a few times and the corresponding line in the G-code is scrolled to and marked. Also, pressing F1 within the G-code listing flashes the line in the graphics.
Both methods show XYZA of the start point and the end point.


I'll be quite occupied the next weeks: Have to make 3 permanent molds for zink-castings and a bunch of Porsche 911 crankshafts ...




Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: stevehuckss396 on January 04, 2014, 09:28:14 PM
Did you show the crank to some people and end up taking orders?
Title: Re: CamCalc. The weird lobe-calculator
Post by: MuellerNick on January 04, 2014, 10:08:37 PM
Quote
[size=78%]Did you show the crank to some people and end up taking orders?[/size]



Can't tell the whole story. But yes, the first batch is "gone". And the next batch will be 40 - X (X being the ones that are rejects).

Edit:
The disk cutter (for milling) is good for about 8 crankshafts. Then it needs regrinding. I hope I find that sheet again where I wrote down the angles. Regrinding is a bit tricky, as every odd tooth is cutting left and the even ones right. They are side-cutting too. A circular saw doesn't work.
I have looked for a carbide cutter, but they start at 400 € (custom made). With inserts, they cost 1000 € and up.  :disappointed:


Nick
Title: Re: CamCalc. The weird lobe-calculator
Post by: dsage on March 06, 2014, 03:57:52 AM
Steve:

While your waiting for this program to be finished you can grind a cam now with Gcam. We developed it several months ago and posted a notice about it here.

http://www.homemodelenginemachinist.com/f26/grinding-cams-cnc-program-beta-test-21127/

 We'd be happy to have some people give it a try. I've ground a couple of dozen cam lobes with it and works very well. We need the feedback.

Sage





SimplePortal 2.3.5 © 2008-2012, SimplePortal