[MMarz]

Hi there,

I am in the process of writing my own CNC firmware. For the most part, it is going well. The only problem is that I can't seem to find software that produces g-code with true 3D profiling. I would like to test arcs moves using G18 & G19, but the software I have come across so far only uses linear moves ,G1, or uses G17 arcs and increments the Z-axis. Can anyone recommend open source and/or free g-code compiler that uses true 3D profiling and not just 2.5D profiling?

Thanks!

[KOC62]

Does your firmware replace Mach3 or its equivalent?
If so;
a) does it use the LPT port?
b) what is the fastest pulse rate for stepper motors?

[MMarz]

It uses serial over usb. It accepts raw gcode commands and interprets them on the fly. It has a 20 move queue buffer, does automatic acceleration, and backlash compensation. Right now it relies on an L297 to do the voltage chopping so the pulse rate would be limited by the L297's capabilities. Otherwise it can output 100kHz.

I have built an interface for it, so yes, you wouldn't need Mach3 or any other software to communicate with it. The interface is pretty basic at the moment. It allows jogging, setting an origin, sending commands individually, and of course, sending a gcode file.

It supports Gcode commands:
0-4, 17-21, 28,30, 73, 80-83, 90-92, 98, 99.
Mcode:
0-6.

I haven't added coolant, fan and other commands just yet because my system doesn't have them, but that is just trivial.

I'm still testing it but so far the machine has produced its own circuit boards. I need some gcode files to test the arcs in the XZ and YZ plane to make sure the math is correct. Would anyone with capable software be able to produce one for me?

Scanning the surface of a hemisphere 1in in diameter. Going from X = 2in, to X = 1in with any resolution you would like.

[KOC62]

Interesting.
I have a Gecko G540, but have no computer with low latency. Therefore I'm looking for a few economical alternatives that can drive the G540 at 300KHZ. Hence my interest in your project and those similar to it.

[MMarz]

Interesting.
I have a Gecko G540, but have no computer with low latency. Therefore I'm looking for a few economical alternatives that can drive the G540 at 300KHZ. Hence my interest in your project and those similar to it.

With a small hardware upgrade, I could go up to 1MHz, but honestly which motors could handle that?

[KOC62]

Yes, I agree.
I also realize that 1MHZ wouldn't work for me.
The G540 does 10 micro-stepping and is limited to 300KHZ.

Experimentally, the Keling 425oz-in can be made to run at 4000RPM, no load. Hence I would need at least 133KHZ pulse rate to test the no-load speed. I'm not aware that a PC can diliver that pulse rate with EMC2, or Mach3 - well at least not any PC I own.

[MMarz]

That is what is great about my micro-controller solution. It takes care of the pulses. Your computer simply provides text commands over serial. I'm working on an upgrade to the system so that you can simply push an entire gcode file to its internal storage. Again, I still need to perfect its gcode movement before I pile too much onto myself.

[Ron Dunn]

Hi MMarz,

I'm another guy doing a similar project.

Mine is Arduino based (for now), takes g-code from a USB key or through a serial interface, and is designed to implement the set of g-codes required by Vectric's products. I'm trying to create a turnkey solution for Vectric users that doesn't require a PC in the mix.

My current challenge is to change my code from command-by-command movement interpretation, as I found I was getting dwell marks from the slight pause between commands. Where it stood out was the cutting of tabs on otherwise straight lines. I'm currently working on a balancing act between the memory requirements of a queue and the issues of interrupt timing.

I use an LCD screen and some buttons for homing, jogging, menu selection, etc. At one stage I was writing g-code to this screen as processed, but this aggravated the dwell issue. I might go back to that idea if I can get enough cycles between interrupts.

Circular interpolation was another challenge, I tried quite a few algorithms before settling on one that gave me an acceptable level of precision.

What have been your biggest issues to date?

Ron.

[MMarz]

Hey Ron,

By far the biggest issue has been queue management. You have one routine that is trying to insert commands into the queue. Another routine trying to execute them. Then there is the issue of pausing the machine if need be. Handling G4 commands, tool changes and other M codes, and peck drilling with pauses. There is also the acceleration to deal with.

I think I have most of the bugs worked out though. I ended up using a scalable circular queue. Right now it is maxed out at 20 moves due to memory limitations, but I'm hoping to bump it up in my final implementation. What made everything run smoothly was to convert all units into steps as they arrive from the serial connection, and doing all calculations without floating point values.

I was also thinking of adding capabilities to remove the computer from the mix. I was hoping to make it as an optional add-on, having its own micro-controller and storage. With the cost of chips these days, it really makes sense. There is no reason to burden the main controller with file management if you have a large enough move queue. What format is your USB key? To transfer files onto it, does it require any special management to make sure the file is positioned correctly in memory? Is there any reason you went with a USB key drive instead of an SD card?

[Ron Dunn]

Hi MMarz,

The USB interface I use is the VDrive2 (Application Modules). It provides a serial interface to a USB key. Not sure I'd recommend it, though, as the firmware API is a little brain damaged, and it has the common restriction of 8.3 file names.

I've also got a uDRIVE from 4D Systems (µDRIVE-uSD-G1 - µDRIVE - Embedded DOS Drive). Better firmware, for sure. Its only problems are that it is a microSD card, and again, 8.3 names.

The firmware on each card gives you a serial API that allows you to read directories and browse, open, read and write files. They've abstracted all the hard stuff.

There are two significant problems with SD cards. They're fiddly, and they don't mount well. The problem of fiddly little cards is especially bad with microSD. Can you imagine a greasy, sausage-fingered machinist trying to handle a microSD card in a workshop? *grin* ... OK, I'm being facetious about machinists, but SD cards are definitely not the most finger-friendly device. The mounting problem is worse. How do you adequately mount an SD card socket in a typical instrument case?

That's why I'd prefer a USB solution, but I'm having trouble finding a reliable, wallet-friendly product around which to base the controller's file system.

The version I'm currently developing also uses a circular queue. Luckily I based my controller on the Arduino Mega2560 device, and I've got LOTS of spare memory. Currently my code occupies around 17k and just over 1k of data. By the time I add a very large queue I should still be well under 25% of the machine's capacity

Ron.

[MMarz]

Nice. Thank for the info. I'm sure I'm going to be spending a lot of time trying to understand it.

I'll have to take a closer look at the mega. On first glance, the I/O and memory are pretty impressive for the price.