Is there anybody else seriously using VB to program the G code they need?

[cncgcg]

Hi,

After looking at numerous CAD/CAM and easy this and simple that programs, I started writing VB routines to generate G code, mostly outputted to the immediate window and copy pasted it where I wanted it, most of these routines never made it out of the debugger.

I'm not knocking the CAD/CAM programs, they are incredible, but what they offer is way above what I would need as a hobbyist (I'm too old to write an obbyist, sorry. Where'd my aitch went?) so I took to writing what I needed myself.

I'm doing bowl shapes at the moment and once I have finished the X,Y scaled bowl I want to to concentrate more on fractal patterns and mathematical patterns. The material I love to use is plexiglass, especially combined with LED RGB lighting (I have examples of RGB LED plant lighting on my site).

So if you are like minded and willing to share your routines and experiences I'd love to hear about them.
I reckon I've nearly cracked bowl, and whether it's accurate or not I just love writing it.

Gareth

[Rogue]

Moved away from VB some time ago, except when I need to do something in Excel, but I must say that is quite impressive! I would imagine that the basic geometrical shapes (sphere in this case) are easier to code through loops and checks against a simple rule set. Have you tried handling irregular shapes, or converting pointclouds into GCode?

[cncgcg]

Hi Rogue
The basic rule set here is that the decreasing circle diameter is determined by Sin and the increasing depth of cut is given by Cos (90 down to 0 or a multiple of). Since both use the same numerical value for each pass they stay mathemetically "in sync" (my terminology will probably cause a few comments, but I'm not a mathematician or a machinist).
I think I've probably covered irregular shapes with the program by combining standard geometric shapes , rotations and scaling as a series of jobs.
Point clouds are created by 3D scanners I believe, and are way beyond my capabilities and those of my machine so I'll leave that to CAD/CAM although many don't seem to support it yet.
Gareth

[black5f]

Hi.
You've been busy? cracking stuff!
Not sure where to post this but here seems as good as any. So to set my stall out so to speak, having already shared some vector geometry (maths is definately NOT subject to copyright!). You may be interested in this as well Jonathan? This is not a show off, you asked to share routines and it seems my place is to pass this on to whoever has the attention span to listen. I have dug this out. A lot of modern CAD owes it's roots to efforts by several people to produce ways of representing shoe making tooling, patterns and lasts (the foot form tool) on a computer. This was done by the application of pure maths and checking the dates on the files I last edited these in 1989. I never junk source and this has been copied religiously from 720k beer mats to modern day servers. It runs in dos and after a little work, not only ran in dosbox on an XP machine but I even found the compiler! It compiles to an exe file of only 645k! Written in pascal, a very readable langage, all pure maths, no third party dlls, we had to do it scratch then. The lasts are made form manually digitised point clouds, points interpolated to give a network of csplines ( cubic, degree 3 equations). These form the boundaries of parametric bicubic patches, their bounderies constrained to be smooth with adjacent patches in tangent and curvature. The shading was done by reprogramming the pallete (only 256 colours in those days and VGA was advanced graphics) and colours assigned based on the angle of the normal to the surface vs the angle of the light source (very relevant to tool paths). The crossections are equations in themselves, the intersection of the surface and a plane. So not individual points as such, like a wire frame, but mathematical equations. Maybe one day I'll recode it in Delphi 7, my standard stable 21st centurary tool of choice. Right now I'm too busy on other stuff, steam engines etc. Anyway, food for thought.

[jonnie]

Hi Gareth

Congratulations for taking this independent route.

I am just itching to write some code probably to generate *.obj files as I anticipate simply importing *.obj parts into Vectric aspire and then letting it get on with the cutter paths.

I was pleased to note that Microsoft Studio free version includes so much of the paid version so I have installed that and anticipate thinking up some kind of a project in C++ or C# - long time since I used VB and its not my favourite language.

Other low cost programming routes include PHP if you have a website or care to run a server simulation on your PC. Its a tad strange but I often find it easier to knock up a webpage ( so quick and easy for simple interface and graphic feedback ) and then dump the output to a file on the server that I can download at leisure. PHP is not blindingly fast but its pretty close to "C" and is easy to use.

As soon as I have indentified a project where it will be easier to define the mathematical form than work in my CADCAM packages I will be doing something similar to yourself.

*.obj specifics: There are all kinds of mesh and triangulation libraries out there so it is not necessary to re-invent the wheel, the *.obj format is very straightforward as it represents a mesh of cartesian points ( optionally more ) I like this root as the OBJ format is universal. The downside of course is that you are working on the basis of a facetted rep so it will not be precise as your Gcode example where you do not suffer the small errors involved in representing a mathematically defined surface by a piecewise planar/linear approximation.

Anyway its great to hear of someone getting their head under the hood - it gets more interesting when you see how it all fits together.

Jon

[GEOFFREY]

Hi Gareth, sadly I'm not with the maths, but lets hear (or see) more about your steam engines. G.

[irving2008]

Holy ancient thread resurrection Batman!

This thread died in 2011 and the OP hasn't posted since!

It was black5f talking about steam engines and he's not posted for over 18m!

[GEOFFREY]

Holy ancient thread resurrection Batman!

This thread died in 2011 and the OP hasn't posted since!

It was black5f talking about steam engines and he's not posted for over 18m!

What goes round comes round and nothing goes round better than when accompanied by the hiss of steam IMHO. G.

[Robin Hewitt]

Confidence is that feeling you get just before you understand the problem

I did it in C#. You stitch everything together, separate bulges from pockets, identify islands and you have an outline. Then you offset those outlines to create a tool path. Everything goes swimmingly until the tool size becomes relatively large to the shapes. Suddenly pockets divide in to sub-pockets, parts of the outline disappear all together, different parts depending on where you start. Outlines completed you hit waste removal

[jonnie]

Hi Robin

Thats interesting - ok so there were some clash detection issues but it would still be very interesting to hear more details.
What type of curve geometry was your starting point - did you begin with linear segments?

As mentioned I am kind of interested in writing OBJ files because then I can let vectric aspire worry about tool paths but even
though you ran into problems this sounds like a lot of fun.

I doubt homebrewed code is ever going to deal with general cases without a lot of work but specific applications might be interesting.