flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > MenuetOS > mathlib and CNC

Author
Thread Post new topic Reply to topic
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona
mathlib and CNC
As I mentioned previously, I am writing a 64-bit Forth compiler. I have a data type I call "real" which is a 64-bit integer with unity set at 2^32. This is actually fixed-point, but it acts like a floating-point so long as the user can stay within the range of about negative 2.1 billion to positive 2.1 billion. My "killer app" is CAM (generating gcode for CNC machines), so this restrictive range is not a problem for me at all --- I really doubt that it is a problem for most applications (except astronomy!).

I read that Menuet has a mathlib that uses "packed" numbers rather than the FPU. Are you guys doing something similar to what I'm doing? Can you describe what you have going or point me to some documentation?

Right now, I am converting my numbers into floats and using the FPU for calculating the transcendental functions --- but I plan on eventually writing the transcendentals myself and sticking with integer code. If you have already done this however, then I would like to make use of your code if that is okay.

Right now, my compiler is for Windows. It is written in FASM though, so it could be ported over to Menuet fairly easily. If you guys are going in the same direction that I am in regard to numerical stuff, then that would make Menuet a better fit for my compiler than I had previously supposed.

I wonder if Menuet might be a good choice for a CNC machine. It would provide a user-interface for developing gcode --- a big step up from those crude text monitors that most CNC machines have! Has anybody ever thought about this before? Do any of you Menuet guys have experience as machinists?

Anyway --- I haven't delved into Menuet yet, but it is something I'm interested in. Smile
Post 05 Jan 2014, 03:27
View user's profile Send private message Send e-mail Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 199
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.
Post 11 Jan 2014, 11:01
View user's profile Send private message Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona

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 Smile

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").
Post 12 Jan 2014, 01:19
View user's profile Send private message Send e-mail Reply with quote
x3k30c



Joined: 14 Aug 2013
Posts: 13
Location: Hungary
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.
Post 13 Jan 2014, 01:12
View user's profile Send private message Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona

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).
...
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


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.
Post 15 Jan 2014, 04:04
View user's profile Send private message Send e-mail Reply with quote
x3k30c



Joined: 14 Aug 2013
Posts: 13
Location: Hungary
It was indicated here:

http://www.menuetos.net/sc151.html

"math functions operate on single/double precision floats using SSE/SSE2"

Rolling Eyes

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
Post 15 Jan 2014, 06:07
View user's profile Send private message Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona

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.).
Post 17 Jan 2014, 03:43
View user's profile Send private message Send e-mail Reply with quote
x3k30c



Joined: 14 Aug 2013
Posts: 13
Location: Hungary
"if ever"

Smile

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
Post 17 Jan 2014, 05:45
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14673
Location: Origae-6
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.
Post 17 Jan 2014, 06:11
View user's profile Send private message Visit poster's website Reply with quote
x3k30c



Joined: 14 Aug 2013
Posts: 13
Location: Hungary
and i should learn the language finally
Post 17 Jan 2014, 12:54
View user's profile Send private message Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona

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).
Post 19 Jan 2014, 05:21
View user's profile Send private message Send e-mail Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona

revolution wrote:
Slow?

Have you measured it?


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.
Post 19 Jan 2014, 07:31
View user's profile Send private message Send e-mail Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona

x3k30c wrote:
and i should learn the language finally


Do you mean gcode or Forth?
Post 19 Jan 2014, 07:32
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14673
Location: Origae-6

Hugh Aguilar wrote:

revolution wrote:
Slow?

Have you measured it?


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.

All I get with that link is this: "To use Google Groups Discussions, please enable JavaScript in your browser settings and then refresh this page". But regardless of what others are saying all this thinking time you are expending on such a small matter is delaying you getting it actually working.

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.

Now there is a proper reason to be using FMUL (or whatever).

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.

It might have an effect, it might not. If your program does these conversions one billion times per second every second and almost nothing else then perhaps you will see a difference. But in reality a CNC machine is a mechanical device. 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.
Post 19 Jan 2014, 07:46
View user's profile Send private message Visit poster's website Reply with quote
x3k30c



Joined: 14 Aug 2013
Posts: 13
Location: Hungary
The 5-axis laser cutter is a pretty nice stuff Smile

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 KCool 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
Post 19 Jan 2014, 10:05
View user's profile Send private message Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona

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?
Post 24 Jan 2014, 05:37
View user's profile Send private message Send e-mail Reply with quote
x3k30c



Joined: 14 Aug 2013
Posts: 13
Location: Hungary
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.
Post 24 Jan 2014, 10:20
View user's profile Send private message Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona

x3k30c wrote:
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.


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. Wink 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.
Post 31 Jan 2014, 07:02
View user's profile Send private message Send e-mail Reply with quote
x3k30c



Joined: 14 Aug 2013
Posts: 13
Location: Hungary
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 Wink
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:



Post 31 Jan 2014, 15:25
View user's profile Send private message Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 199
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.
Post 31 Jan 2014, 18:34
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.