Index
> MenuetOS > mathlib and CNC |
| Author |
|
|
Ville 11 Jan 2014, 11:01
Akos added mathematical functions as system call 151. An example file mathlib.asm is included to zipped applications at download section. http://www.menuetos.net/syscall.txt And I agree that Menuet would be a good os/app combination for controlling external machines.
|
|||
11 Jan 2014, 11:01 |
|
|
Hugh Aguilar 12 Jan 2014, 01:19
Ville wrote: Akos added mathematical functions as system call 151. An example file mathlib.asm is included to zipped applications at download section. http://www.menuetos.net/syscall.txt I'm still not clear if your "packed double" is the same as my "real" --- that is, a 64-bit fixed-point with unity set at 2^32. I'll delve into your package though, to find out what your data type is. BTW: I also have these data types: dreal --- a 128-bit fixed-point with unity set at 2^64 --- primarily used to hold intermediate values during real calculations ratio --- two 64-bit integers, a numerator and a denominator utf8 --- text Any correspondence here? Ville wrote: And I agree that Menuet would be a good os/app combination for controlling external machines. When I wrote MFX (MiniForth cross-compiler) for the MiniForth processor (used to control a laser etcher), the x86 was a terrible choice for controlling machines because of the huge interrupt latency --- the 80186 and NEC V30 were available, but were only used for very light-weight applications --- most real-time stuff was done with the Dallas 80c320. The motion-control program had previously run on the 80c320, and it was ported over to the MiniForth to get better performance. Maybe there are modern versions of the x86 that can be used for real-time control. Most real-time stuff is done with the ARM nowadays. I've never heard of anybody using the x86. If Menuet could be used for controlling machines though, then I would be a lot more interested 
I was only expecting the x86 to be used as a front-end for the CNC machine. A fast micro-controller would still be used to control the machine's real-time operation, but the x86 would provide a user-interface for developing gcode. A hard-disk wouldn't be needed, because there isn't more than a few MB of non-volatile memory needed --- there are plenty of inexpensive ways to provide that kind of memory, most of which Menuet could access without any difficulty. Currently a laptop is used to develop gcode with some CAM software, and then the gcode program is uploaded to the CNC machine via a serial cable. Having the laptop integral would be a lot more convenient. Also, the CNC machine could be on the internet and people could communicate with it from home --- although that would allow for a lot of "Big Brother" spying on the employees by the boss, which I don't think is a good idea (my only experience is in being the employee, not in being the boss, so I definitely hate "performance metrics"). |
|||
|
12 Jan 2014, 01:19 |
|
|
x3k30c 13 Jan 2014, 01:12
mathlib uses packed numbers but it's working on double and single precision floats which are very different from 1.31.32 bit integer floats (and integer floats in general).
If you want to know what's going on exactly, take a look at the original author Shibata's source codes. If you're converting the numbers - you work with - from your own representation to IEEE 754, you definitely can use mathlib! you can do different operations on the sse registers, then converting back to your representation (if I understand it correctly) - this wouldn't be hard I think I don't know if anybody thought about it but it seems to be a good idea, i'm interested in CNC anyway! ps. mathlib does not just evaluate math operations, it also parallelizes (vectorize) it! "A fast micro-controller would still be used to control the machine's real-time operation, but the x86 would provide a user-interface for developing gcode." well that's right, I'll take a look at gcode and the basics. Currently I don't really know anything about CAM/CNC but it would be useful for me for sure. |
|||
|
13 Jan 2014, 01:12 |
|
|
Hugh Aguilar 15 Jan 2014, 04:04
x3k30c wrote: mathlib uses packed numbers but it's working on double and single precision floats which are very different from 1.31.32 bit integer floats (and integer floats in general). Well, this is the first I heard that the SSE registers and instructions were what mathlib was based on. I just didn't know what "packed double" meant. Anyway, this kills mathlib as something that would be useful to me --- at least, at this time --- I will keep it in mind for future programs. |
|||
|
15 Jan 2014, 04:04 |
|
|
x3k30c 15 Jan 2014, 06:07
It was indicated here:
http://www.menuetos.net/sc151.html "math functions operate on single/double precision floats using SSE/SSE2" 
wikip: "SSE introduced both scalar and packed floating point instructions." You don't really have to use/work with packed sse numbers. You can use mathlib for scalar operations too (it's still fast). I don't exactly know what are you doing, but a simple wrapper that converts your numbers/representation to IEEE wouldn't be hard. I won't be forceful, but writing the taylor series (or anything else) that evaluates trigonometric (etc..) functions needs way more time than using a mathlib. rgds, Akos |
|||
|
15 Jan 2014, 06:07 |
|
|
Hugh Aguilar 17 Jan 2014, 03:43
x3k30c wrote: I don't exactly know what are you doing, but a simple wrapper that converts your numbers/representation to IEEE wouldn't be hard. I won't be forceful, but writing the taylor series (or anything else) that evaluates trigonometric (etc..) functions needs way more time than using a mathlib. I have a wrapper that converts to and from my fixed-point to the FPU stack --- this is done for calculating transcendentals. The wrapper may be somewhat slow. I was told on CLAX that FSCALE is very slow (don't know why) and so I use FMUL instead, but that's pretty slow too. In some cases, it may be faster to stick with fixed-point and do the calculation myself --- I will experiment with that later --- optimization like that is something to worry about at the very end of the project, if ever. For the most part, I don't like to learn OPC (other people's code), such as mathlib, unless it is doing something that I can't easily do myself --- so far, my language is all my own code, although I will have to use OPC for the user-interface (GTK+ etc.). |
|||
|
17 Jan 2014, 03:43 |
|
|
x3k30c 17 Jan 2014, 05:45
"if ever"
One problem that x87 is deprecated almost a decade ago.. It's supported, but you can't rely on it anymore I can't believe FSCALE beeing slow, it's also depend on the arch. itself (i don't have anything about the newest cpus, but on the older system it has a latency far more below FSIN..) Anyway, in theory it's possible to do mathlib on integers (even vectorized) but I can't say anything about accuracy.. "my language is all my own code" 64-bit forth compiler? respect! Are you talking about CNC machines like CNC lathe? The reason why I'm interested in CNC machining because I'll need some highly precise and complex metal parts. The chinese would do that but CAM software/(and gcode somewhere) is required. Most of the high-end CAD programs aren't free, and the ones like FREECAD doesn't really support this as far as I know. However, FREECAD is still not the best option because the complexity is very high and the surface is approximated by math functions.. I dunno how to solve that. rgds, Akos |
|||
|
17 Jan 2014, 05:45 |
|
|
revolution 17 Jan 2014, 06:11
Slow?
Have you measured it? If you can't measure it then you don't know if it is slow or not. Did it run really-a-lot-uber-faster(TM) when you changed to FMUL? Or was it not noticeable? Have you got a working product yet? If not, then fast or slow makes no difference because without a working product you have nothing yet. |
|||
|
17 Jan 2014, 06:11 |
|
|
x3k30c 17 Jan 2014, 12:54
and i should learn the language finally
|
|||
|
17 Jan 2014, 12:54 |
|
|
Hugh Aguilar 19 Jan 2014, 05:21
x3k30c wrote: Are you talking about CNC machines like CNC lathe? Yes. I've worked on lathes and milling machines and 5-axis laser cutters. Pretty much everything in a machine shop uses gcode. x3k30c wrote: The reason why I'm interested in CNC machining because I'll need some highly precise and complex metal parts. The chinese would do that but CAM software/(and gcode somewhere) is required. Most of the high-end CAD programs aren't free, and the ones like FREECAD doesn't really support this as far as I know. However, FREECAD is still not the best option because the complexity is very high and the surface is approximated by math functions.. I dunno how to solve that. What are you trying to build? Or is this top-secret proprietary? It may not be as difficult as you suppose, in which case I'll do it or at least suggest some approaches for you to take. My language isn't running yet, so by Revolution's standards I have "nothing." Any other language can be used to generate gcode though (not FASM, but any high-level language). I recently used ANS-Forth to generate gcode for my slide-rule program, and when I was employed as a Forth programmer I used UR/Forth to convert AutoCAD dxf files into gcode. When you mention the Chinese, I take it that you don't have access to a machine shop but are expecting to get it done over the internet --- that is pretty ambitious. I would really recommend that you find a local machine shop and hire them. Don't even think about working with somebody remotely unless you have high volume, and you have already got a prototype built --- gcode is like any other kind of programming, in that it has to be debugged, which means that you have to work shoulder-to-shoulder with the machinist (there are simulators for gcode, but they only help find the gross mistakes, and there is still no guarantee that your part is going to work). |
|||
|
19 Jan 2014, 05:21 |
|
|
Hugh Aguilar 19 Jan 2014, 07:31
revolution wrote: Slow? This was discussed on CLAX: https://groups.google.com/forum/#!/PNM0mHiOpt0 Several people (Bob Masta, Robert Wessel, Bruce Evans) described FSCALE as being "too slow to use" (about 20 times slower than FMUL) --- the cause seems to be a mystery though, as it is doing something simple. Anyway, I took their word for it. FMUL actually works better, because sometimes I want to change units at the same time, so I need to do an FMUL anyway. This is actually pretty common, because my language uses degrees but the FPU uses radians. It will also likely have some effect on the program speed, as CAM tends to be pretty heavy on trig calculations --- but we won't know for sure until I get the thing running, as you said. |
|||
|
19 Jan 2014, 07:31 |
|
|
Hugh Aguilar 19 Jan 2014, 07:32
x3k30c wrote: and i should learn the language finally Do you mean gcode or Forth? |
|||
|
19 Jan 2014, 07:32 |
|
|
revolution 19 Jan 2014, 07:46
Hugh Aguilar wrote:
Hugh Aguilar wrote: FMUL actually works better, because sometimes I want to change units at the same time, so I need to do an FMUL anyway. This is actually pretty common, because my language uses degrees but the FPU uses radians. Hugh Aguilar wrote: It will also likely have some effect on the program speed, as CAM tends to be pretty heavy on trig calculations --- but we won't know for sure until I get the thing running, as you said. |
|||
|
19 Jan 2014, 07:46 |
|
|
x3k30c 19 Jan 2014, 10:05
The 5-axis laser cutter is a pretty nice stuff
generally, I need metal parts for loudspeaker drivers high complexity comes with phase plug/basket like AL parts http://www.alibaba.com/product-gs/242664312/RCF_18_t_yoke_speaker_parts.html http://image.ec21.com/image/rita68/oimg_GC08376974_CA08457368/Speaker_Phase_Plug.jpg http://feitech.en.alibaba.com/product/614545586-214116672/8_18_ALUMINUM_SPEAKER_PART_BASKET.html http://www.jands.com.au/__data/assets/image/0019/47206/JBL-D2.jpg These aren't proprietary of course, altough I'll do some proprietary modifications to them (that wouldn't be easy to do on existing ones) the problem here in Hungary, is that it's impossible to get low carbon steel like 1010 and 1016 (not even talking about pure iron) Ordering from US seems to be possible but they're shipping at a high price (it's possible to get these from China, I simply don't need 200 pieces though) Here is a cad drawing: http://www.tiikoni.com/tis/view/?id=9fd0421 but freecad doesn't really support dxf/gcode conversions. It would be better to learn the language, and programm it manually A simple lathe is not enough. CNC is a must (for plugs, baskets, etc..) (English. I still do grammar mistakes) In respect to fmul etc.. It really depends on the architecture itself. I've read a lot about the older (like K  cpus and they'd strongly adviced to abandon the fpu as much as possible. for your needs, fixed point might be enough (especially on 64-bit) and taylor series etc.. still can be done on it. however, I'd advice you to abandon the fpu for the same reasons..
rgds, Akos |
|||
|
19 Jan 2014, 10:05 |
|
|
Hugh Aguilar 24 Jan 2014, 05:37
revolution wrote: The silicon based electronic device will likely run virtual rings around any moving part device. I think you are worrying too much about a non-issue. Actually, the x86 program is "compile-time" in the sense that it is generating the gcode, which then controls the machine in real-time. Speed is not really an issue at compile-time, so you are right that I'm worrying too much about a non-issue --- although speed is an issue in the motion-control program (running on some kind of micro-controller inside of the machine) --- which is the opposite of what you are saying. Anyway, forget about all of that numerical stuff --- I don't think mathlib will help me because it uses a different data type than I'm using --- I'll just stick with my code as I have written it so far. Moving on to other matters --- does Menuet have any UTF8 support? My language has UTF8. Even if I don't port my whole language over to Menuet, I might consider porting parts of it. For example, I could port the UTF8 code over as a library of FASM functions that Menuet FASM applications could use. Any interest? |
|||
|
24 Jan 2014, 05:37 |
|
|
x3k30c 24 Jan 2014, 10:20
Hi Aguilar,
Have you read my post? Maybe a short aswer or a 'suggest to take some approaches' would have been enough. First, if Menuet would (or does) support UTF8 in some kind of form, maybe you were come up with an issue, as you did with mathlib. Next, just don't force others to get your answers without a real helpful reason. |
|||
|
24 Jan 2014, 10:20 |
|
|
Hugh Aguilar 31 Jan 2014, 07:02
x3k30c wrote: Hi Aguilar, The reason why I didn't offer any suggestions for approaches, is because I don't have any. Stereos are mass-produced items. There is no way that you are going to make anything yourself that isn't 2 or 3 orders of magnitude more expensive. Just buy your stereo at the department store like everybody else.  If you want to get into machining, find something that isn't already being mass-produced. If I had any money, I would build aluminum slide-rules and use my software that generates images to photo-lithograph them over an anodized surface --- nobody is mass-producing anything like that! --- of course, the reason is that there is no market.
Most likely the reason why the Menuet guys didn't answer my question about UTF8 is because they aren't interested. If Menuet isn't already able to display UTF8, then a library of UTF8 functions isn't going to be very useful. I am unclear as to what Menuet is for, which makes it difficult for me to make any kind of meaningful contribution. |
|||
|
31 Jan 2014, 07:02 |
|
|
x3k30c 31 Jan 2014, 15:25
Hi Hugh,
Thanks. I don't think that the Menuet guys didn't answer because they are not interested, Menuet is approaching 1.0 so they might just have important things to do. (I'm a kind of 'Menuet guy' anyway) Personally, I think (regardless of my project) it would be a good idea. Have you taken a look at system calls? Why don't you ask the authors directly and mention the details to them? Thanks for your suggestions. It's the same as i read it somewhere on the forth-forums. Why are you interested in a forth compiler? Forget about it and use an existing one! like everybody else
Sounds interesting isn't it? Don't give me that I'm unable to do my own speakers. I'm just asking about some low carbon rings and al rings with machined surfaces. (isn't for a business anyway) You're right there may be no reason (financial) to do something that there is no market for. What about hobby projects? Back to utf8. I don't know for sure. If you are into porting you app to Menuet, it could be done I suppose. Quote: |
|||
|
31 Jan 2014, 15:25 |
|
|
Ville 31 Jan 2014, 18:34
Eventually utf8 support needs to be included to the kernel, so it can be used directly with system calls. But if you write a utf8 library, I'll add it to the download area.
|
|||
|
31 Jan 2014, 18:34 |
|
< Last Thread | Next Thread > |
Forum Rules:
|