[quote author="t0mpr1c3"]I got an email saying commission has been waived this month, by way of apology for the botched rollout. And the forum seems to have been down the last few days. The good ship Tindie is lurching a bit...[/quote] Got that one too.
I think that Tindie has lost a lot of goodwill. I am still not very optimistic since the discussion and handling of the whole affair has been under par. Waiving a month worth of fees is merely a gesture and not solving the problem(s).
I fully agree, there are too many employees at Tindie. You are right that most of the work can be easily "outsourced" for standard processing. The main application of Tindie is a website with a set of interactions. That should not cost $45k per month. Even if each transaction would effectively cost $1, then it is still a far cry from the costs they are running up.
I too am a bit discouraged with the (very large) increase. I do know that running costs are expensive, but it seems to me that Tindie is trying a get-big-fast(er) approach. I have not yet decided what to do in the long run.
Getting the hackerspace's laser room in order. OSAA moved last month and we need to do a lot of work to get everything in order again. Cleaning the laser room was the next in line. Images of the work done during the last couple of days: http://media.vagrearg.org/laserrum/
I've been incrementally improving gcmc to support more functionality and generalizations. Gcmc is now capable of generating G-code, SVG and DXF output as of version 1.4.0. The multiple backends allow gcmc to be used not only for mills and lathes, but also for laser cutters and things I have not thought of yet.
Yes, it is possible to convert to gcmc script form, execute a program and then convert to any output you'd like.
The backend is currently geared towards G-code, but there are, in principle, many more flexible backends possible. Replacing the built-in function table with a new set of function implementations would accomplish that.
However, I do not see me implementing this without some more concrete problem to solve. Just creating a backend for the sake of creating it is not something I would want to do right now. If you have a concrete problem, then we could maybe discuss options.
[quote author="Baldor"]Also, remember G-code is the language that the CNC understand.... Think of it as some kind of machine code. Usually, anithing more complex than a series of holes is done with a CAM program. (In the las workshop where I worked, none of the machinists touched a single line of Gcode, or Heindenhain, all was done via CAM).[/quote] G-code is the assembly of machining. Gcmc is an abstraction level above. The "old" machinist may never have written a line of code, but the modern hacker builds his own mill nowadays. CNC machining is no longer an exclusive domain of the mechanical engineers and gcmc is an attempt to bridge a gap.
Quote
This preprocesor seems interesting for doing some procedural stuff, like what you can do with some modern Heidenhain CNCs. It could be interesting the ability to import toolpaths from a dxf file, or some "standard" vectorial graphics file, and apply some transformations to it (repetitions, offsets, etc...). This could replace CAM programs for some "simple" tasks, like PCB machining. Lookong forward to see how this development ends... And dreaming of my own CNC mill in my workshop.
Gcmc is not meant to be an import-/export-facility for CAD/CAM conversion as such. I cannot see the value of gcmc reading DXF files, where there are many other conversion scripts/programs already available. It could be interesting to have the CAD packages export a gcmc compatible script; that would be a different world.
[quote author="Sleepwalker3"]Not knocking it, obviously a lot of work has been put into it and it looks good, it's simply that I'm not sure that I have a need for it, though no doubt plenty would benefit from a meta-language like this - especially those coming from a C background.[/quote] Don't get me wrong, all comments are welcome. However, not all will like or require a new language or see the need for it, whereas I was simply trying to solve my own frustration, which became a bit more.
Quote
Where I do like this is the simplicity in mixing Imperial and Metric, I can see that it would come in *really* handy for that sort of thing.
That was one of the design parameters of the language because I regularly deal with both in one project. Parts are PCBs, in mils and the case/rest is in mm. It is a hell to keep track. Now I can just specify all values as is and I know it will fit.
Quote
Is it flexible for different 'flavours' of G-Code or are you going for one particular flavour, as 'standard' ISO G-code is nothing like 'standard' in the real world, as you probably know.
Yes, that was a thought that struck me when the first version was done. It is possible to create a flexible backend to generate the codes that are supported for a specific target. Especially the arcs in YZ and XZ planes are badly supported, which could be created in gcmc. However, my test-target is LinuxCNC at the moment and has many features implemented. More fine grained backend features will be something to implement when I get a request for it.
Quote
I brought up the 'Rapid' and 'Feed' (or Linear) points because I get a lot of people thinking G0 (G-Zero) is actually GO (G-Oh) as in "GO to this point", when really it's not about getting to any specific point, that particular part of the code is simply about the way it feeds and the rate at which it does it. It's an important distinction also in that in G1 the toolpath will be a straight line to a point, however G0 may not follow that and can just get to the final point in any given axis at whatever maximum rate it can, with no regard for the other axis - so they may not all arrive at the finishing point at the same time - I've seen that result in a few crashes!
You still need to know some basics and knowing CNC machining principles. Knowing basic gcode is a good thing before attempting to make anything (just like you should know assembly even though you program in C). I do know the difference between G0/G1 and any user should also know that or learn the hard way, like you ;-)
Quote
It's quite an adventurous sort of project, how far do you think you'll take it? For example, do you expect you'll get into things like having adjustable plains for Circular Interpolation, etc? There are many types of things that could get tricky with the many different versions of G-Code out there.
The current version supports setting the active plane (XY/XZ/YZ) and simply assumes that the target machine also understands these. But that will be a future feature to do interpolations in gcmc on demand. For example in the UVW planes. One of the difficult issues are the ABC axes, where there is no consensus how they are mounted and therefore not possible to make a generic mathematical model. Then there also is supporting polar coordinates in general. Those will be of future consideration.
As for adventurous, well, I like a challenge :-) Gcmc is an attempt to bring an archaic CNC language into the modern age with an easy and clear interface. All feedback I get flows back into its development. As for "how far do I take it" is funny because I got a similar question on the LinuxCNC mailing list. Well, as far as it takes to make gcode programming obsolete.
[quote author="Sleepwalker3"]I guess it depends on what flavour you're dealing with, but I don't have any real issues with G-Code, though some controls are easier than others.[/quote] Well, gcode is archaic. It hurts my brain and makes my eyes bleed ;-)
The point being, nobody is forced to use anything. Gcmc was started because I wanted to write things easier. If you love gcode, you should certainly continue to use it directly.
Quote
A couple of minor correction to the code above - G0 isn't 'go to', it's 'Rapid' - i.e. move at Rapid velocity. G1 isn't 'move' to, it's 'Feed to' - i.e. move at the commanded Feed velocity
That is a matter of perspective. You are right in the sense of machining, but gcmc is on top of that. G0 simply moves at the highest speed to the point you want and G1 moves at the specified speed or feedrate to the specified point. If you don't like them to be called goto/move, the you can make a couple of functions:
function rapid(v) { goto(v); } function feed_to(v) { move(v); }
Quote
It looks a little odd compared to the G-Code I'm used to, I'm also not use to seeing what appear to be placeholders for the other axes - e.g. move([-,-,-10]); that's usually just G1Z-10.
They are not placeholders, but "undefined" values. The reason is quite simple. The argument is a vector. The vector entries correspond to XYZABCUVW. Undefined entries are there to enable selective moves and still being able to to vector-mathematics.
If you look at the examples, then you can see that the vector math is what is so valuable. Vector math combined with the vector lists is a powerful way to do calculations.
Quote
I don't really have an issue with swapping between Metric and Imperial, though generally you try to avoid it if you can, so that you don't accidentally get caught out. Of course there are exceptions like the PCB related stuff you mention. What I usually try to do in those cases is do all the metric stuff in one section, then the imperial in another section or another program. On the controls I deal with it's just a simple selection of G70 or G71 to swap, so I don't really see it as messy, though plenty of people who try to convert a lot of precise numbers to metric and then it can get messy.
The problem is not that big if you can redefine the units on the fly. The problem is when you have to do math on the values. Then you get into the mess of conversion. Gcode is not very readable when you start to do many calculations on the lines. It also gets messy quick when you need to know where/when/what just happened and "what is my state now again"... Better to let the language handle the conversions and you can concentrate on the actual pattern designs.
I have been improving the gcmc compiler for a while and I think it is very powerful now. The grammar is done and a very rich set of built-in functions support easy creation of very complex designs. Gcmc's syntax and built-in functions are now also documented at gcmc's home page http://http://www.vagrearg.org/content/gcmc, which links to syntax and function reference.
Next up is to start working on a standard library of script-space functions to do high-level common operations. However, this will take some more time. In the meantime, I hope some of you find gcmc useful for CNC milling or other uses I have not yet though about.
Some examples: [attachment=3] [attachment=1] [attachment=2] [attachment=0]
[quote author="OhmArchitect"]I wonder why it isn't used more often. I guess it is 4-wire instead of 2. But still, that's pretty impressive.[/quote] To name a few:
The hardware is not cheap because you need galvanic separation on a real '485 bus.
It is half-duplex and there is no defined protocol layer, apart from the addressing byte, which some implementations ignore completely. Addressing and data-flow are up to the implementation.
Speed and distance are generally mutually exclusive (this goes for many HW comm-channels). Running 1km of wire has huge ramification on cable capacitance and therefore needs a lot of energy to swing. That means speed must go down when distance increases. RS485 drivers are not powerful enough to do both high speed and long distance. Besides, you will have propagation delay problems detecting bus collisions.
[quote author="nickjohnson"][quote author="Bertho"]Maybe this is the opportunity to finish my Brainfuck CPU design :-)[/quote] Sounds like it. Have you seen the other design(s) along those lines from a previous 7400 contest?[/quote] Actually, I haven't seen one in pure 7400 logic. CPLD and FPGA, yes, but not discrete.
With the counter timer running at Fosc at 8MHz, I see about 200..250 counts change through 2.55mm acrylic with the finger covering the pad. With only a fingertip it ranges at 100..150.
The count when no finger is there ranges from 1500..2100, depending which pad is measured and it is highly unoptimized and not calibrated in any way at this moment.
These measurements are with 4.7nF holding cap and 1M slope discharge.
When doing it at 5V and 16MHz, then the count values nearly double.
Open Source Hardware