Since vector lists are just matrices (assuming the vectors are all the same size) any chance you'll include basic matrix arithmetic? I suppose just multiplication and the transpose is really all that would be needed.
It would be nice, given an transformation matrix A to operate on a vector list V to produce a repositioned tool path with just V*A[sup:]t[/sup:]. Easy enough to implement with a function but would be cool if it was native!
The established (assembly) language is g-code. The high-level language is gcmc-code. If you compile gcmc constructs into g-code, that is you write a gcmc interpreter in g-code, then you can interact with the CNC-machine at the gcmc level.
Ok I think I get it. You want to be able to post g-code on the fly, via real-time interpreter (not compiler) to LinuxCNC? I thought the intent was to compile a gcmc file into g-code, then import that g-code in LinuxCNC (or Mach3 or whatever.) However, you want to be able to have a gcmc interpreter running inside LinuxCNC, and control the machine using real-time gcmc-generated g-code rather than g-code directly?
I guess the only way to do that using some other language would be to open up a sockets connection to LinuxCNC (or whatever messaging protocol it allowed, if any - it seems there is a linuxcncrsh that allows you to talk to LinuxCNC via telnet) and communicate via another process, or even another machine . But I suppose that would not be incorporated into the LinuxCNC GUI.
Quote
For example, g-code allows for measuring of points on the object you are creating.
I think you underestimate the complexity of a g-code interpreter and how many primitives there are. Surely, I could import the linuxCNC g-code interpreter, but I'd rather spend the time creating a symbolic compiler.
You are absolutely right. I spent last night looking into it, and G code has become a rather complete - if not ugly - language (though I'm not sure if it's turing complete.) To do what I wanted to do (properly) would require a full robust interpreter, and then some very intelligent processing, if the G code program was anything more than just a connect-the-dots sequence of absolute coordinates (e.g. function calls.)
So much for that idea.
But I am still curious, why not implement the meta-language in another, already established language rather than making a new symbolic compiler from scratch? Maybe I'm missing something, but it seems like you could just write a class library that does everything you want it to do using any decent OO language (or even non-OO language) such as Schema, Ruby, Python, C++ (if you happen to be a masochist) Java (if you happen to be a sadist) or anything, really. The obvious advantage being, you have not only a powerful language at your disposal already complete and tested, but with it the multitudes of freely availably libraries as well.
In fact, I'm toying with one in Ruby. I'll post progress if I get anywhere interesting.
That is true and I completely see your point, which was why I was considering creating a high-level way of generating G code until I came upon gcmc.
However, one instance in which the ability to deal with raw G code would be cool is if, for instance, you had a widget designed with CAD, whose tool paths are not easily described using a scripting language (nor would it be good use of time to do so; it is, for instance, quite complex with weird angles in all planes.) In the normal course of fabrication, one imports the 3D model into CAM software to generate tool paths. It would be cool to then use a scripting language (like gcmc) to import the toolpaths generated by the CAM software for one such widget, and be able to duplicate those toolpaths - scale, transposed, rotate, etc - so that one could blanket a work piece with multitude of this widgets for the purposes of production. I could always use the CAM software to do this for me, but there are many instances where I'd prefer to great tool paths for just one part, then be able to duplicate and manipulate it at will using a few lines of code. That way I can easily adapt my production tool paths for differing work piece geometries and quantities without having to totally rework the CAM software (which can be a time consuming pita.)
e.g. do something fancy like this (in a more Ruby-ish dialect):
// Make a group of two, one rotated and below the other, as this is an efficient use of the workpiece due to the geometry of the part (e.g. it is wedge shaped):
I'm not sure if I'm describing the scenario well, or if I'm just not doing something the right way, but this was my principle motivation in seeking out a high level language to generate/manipulate G code in the first place.
Quote
I have considered symbolic compilation, but that requires a statically typed language and a g-code interpreter that has many more memory locations than 5000 (LinuxCNC has a define that controls this). In principle, you implement a virtual machine in g-code to run compiled intermediate gcmc code. The advantage is that there can be better integration with some machine interactions (reading back values), but it turns out to be quite hard to implement.
I'm not quite following the limitation imposed by LinuxCNC and how it fits into the inner workings of gcmc, but I assume there's something going on that I just don't understand.
I was wondering, however, why not just make a library extension using some other language? For instance, a 'ToolPath' object that handles all the vector primitives and G code functions contained in gcmc (and additionally a G code parser for good measure!) while not having to reinvent the base language and compiler? Just curious if there was some reason I'm not considering.
That would be a hard thing to do because it requires a full G-code interpreter. That is not part of the goal(s) fot gcmc. G-code is the assembly of the machine and you want gcmc to de-compile the assembly into a high-level program. That is very hard to do.
Really I'd only like to have the ability to read lines from a file and put them into a string, and then have some some basic string tokenizing ability (there's got to be open source string and/or even regex libraries out there?) and I would write the G-code interpreter in gcmc. It's not a huge deal, since I could always write a "G-code to gcmc vector" script in some other language and just include the vector in the g-code, but it would be cool to do it in gcmc!
Awesome! Thanks for doing this! Was considering developing something similar (though more likely a library extension of an existing language, like Ruby) but now I don't have to :)
A few thoughts, if you don't mind:
It would be really nice to be able to access the vector components with '.' accessors, e.g. V[0] ==> V.x, V[1] ==> V.y, V[2] ==> V.z etc. do make the readability clearer.
Also, any hope of file read/write capability and string (parsing/tokenizing) functions? It would be nice to read a pre-existing G-code program (some tool path output by cam software for instance) and parse it into a vector list, which can then be manipulated (scaled, rotated, repeated in a matrix, etc.) by gcmc.
Also, a few things I noticed:
The 'if' statement requires {} around single statement execution blocks, e.g.:
as it complains that it doesn't do anything (e.g. no assignment.) I'm not sure if the above was intentional, but it would be nice if this worked more like as expected in C.
