Hello again. I've changed my email address. It was [email protected] previously, but that email is no longer in existence as my website is kaput now. I think I may have missed a couple of weeks worth of your posts --- hopefully you didn't say anything important while I was gone. :-)
I've been working on Forth mostly. Here is some of my code: http://www.forth.org/novice.html I almost have the slide-rule program completed. The biggest problem remaining is generating gcode to produce text characters for the labels on the marks (mostly numbers but some symbols such as for pi) and the names of the scales (C, D, S, T, etc.). Would you guys know where I can get gcode for alpha-numeric characters? I need to be able to scale it to different sizes (specifically 0.05 and 0.08 inch squares). Also do you know where I can get a gcode plotter? I have the CNC Handbook (which cost me $70!) which includes NCplot (http://www.ncplot.com/) and this should do the job for me, but I wondered if you had any alternative suggestions. I worked with a guy once who *hand-wrote* gcode for the entire alpha-numeric set! Lots of people have tackled this problem, although I think most try for a more automated solution. I want something that is free, as I'm not spending any more money on the project. The plan with the slide-rule is to make it out of aluminum. The aluminum will be anodized black or royal-blue, and then a milling machine will scratch off the anodization to make the marks and the text. The hope is that people will put these slide-rules in time-capsules. If our civilization does collapse, these time-capsules can be found centuries in the future and people can use the slide-rules to rebuild civilization. They are unlikely to be able to read English. A slide-rule is pretty self-explanatory though. With a little bit of experimentation they will be able to figure out what it does, even if they can't read the instruction manual. If they have the ability to do arithmetic, they can go on from there to reinvent science --- but science can't be recovered otherwise. I never wrote the LaTeX code, as I have been focusing on gcode, but that should be easy. A problem with LaTeX though, is that the text characters can't be scaled to any size; they come in only certain fixed sizes. This is true AFAIK --- I will have to read up on LaTeX more to find out if this limitation can be gotten around. The reason why I wrote the program in Forth rather than Factor is that Factor is too much in flux. Code written for previous versions has to be rewritten for newer versions. With my slide-rule program, I want to send the source-code out into the wild and have people who don't necessarily know very much about programming be able to recompile it. I don't really like the ANS-Forth standard, but at least it is stable. I can foresee switching over to Factor later on though. This would involve writing a GUI that would allow the user to modify the design of the slide-rule (one-sided or two-sided, which scales are included, and where the scales are positioned) without having to delve into modifying the source-code. Right now, these kinds of modifications are done with cut-and-paste modification of the source-code. One good thing about Factor is that I can write a gcode plotter in Factor using its graphical facilities. This can't be done in Forth unless I require the use of a commercial Forth system and its graphics library, but I don't want to force my users to spend money on any commercial system. Plotting would be a huge help as it would provide the user with immediate feedback on what his slide-rule is looking like. Pretty much any kind of CAM program is going to need plotting like this. A slide-rule just requires 2-dimensional plotting. Most machining would require a 3-dimensional representation of some kind, which is much more complicated. If anybody is interested, I can show you my Forth program. The complicated part was the generation of the scales, which is recursive. Each scale consists of sections, and each section consists of sections, and so forth. The sections on the left are wider and have more gradations of marks than the sections on the right, and that is the complicated part. Now that this is done though, I can generate any kind of scale that anybody can think of. For example, I have a scale that is a combination of the LL1 and LL2 scales, and is tied to the A scale rather than the D scale --- I've never seen such a thing on any other slide-rule ever made. It works well for calculating compound interest. So long as your FV (future-value) isn't any more than 2.72 times your principal, it won't overflow (and the FV isn't going to be this large unless you are a loan-shark). To help the user, I labeled the first ten marks as 1%, 2%, ... 10% rather than 1.01, 10.2 ... 1.1. The slide-rule is a lot faster than using a financial calculator. While you are talking to somebody, negotiating a loan, you can very quickly estimate FV for various scenarios. With a slide-rule, you just set the index on the rate %, and you can visually see the FV for any number of periods, without having to move the slide. With a financial calculator, you would have to punch in the numbers for each scenario, which is much more cumbersome. The only problem with the slide-rule is lack of accuracy, but you can always use a financial calculator later to get the 10-digit precision that it provides. I think that CAM is an interesting topic. I have worked as a CNC programmer. It is very tedious to do this by hand, but on the other hand, the CAM programs available are expensive and hard to use, so I see a huge untapped market there. I don't much like the CAM programs available because you have to use a GUI to describe what you want. I think a program written in Factor that included the Factor compiler would be better, as this would allow the user to write Factor functions to describe what he wants. Using a GUI is too limited. You can't describe anything that the CAM designer didn't foresee (there is no CAM on the market for any price that will allow you to describe a slide-rule, for example). A GUI can also be incredibly tedious to work with. On the other hand, a person with even a little bit of programming skill can write a Factor function quickly and easily. Happy New Year!
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
