XYZ dependency

[rasciodc]

Hello,

Nice work! I haven't tried it yet but i'm planning on doing it this weekend.

I too have a hotwire cutter and had the letartare 8c2 code changed to work on a RAMPS 1.4 board.

But you got me worried when you said that XYZ are dependent when it comes to feedrate calculations. Does it mean that it can't be used as is for a hotwire cutter? How would the final piece dimensions be affected because of that?

Thanks!

[skwee]

Hi, just picked up this project again... I changed the code from letartare to get a correct feed rate calculation in planner.c He made his changes for 4 axes but not specifically for the 2.5 dimensions of a hotwire cutter with it's two independant xy-planes. I was not able to correct the acceleration computation also in planner.c but with the slow speeds of my machine that seemed not to be a problem. I must admit that I had problems to get reproducable results with tapered wings when the longer (faster) side was on uv instead of xy but I was able to solve this problem by cutting the other wing bottom up.

I have cut some SuperGeeII Wings with this software and they are flying, so it's working... Have a look at my machine and some results here images and two forum entries here rc-network and here fpv-community

I am thinking about starting again with grbl-1.1 or at least 0.9 as they promise a much better stepping algorithm.

[rasciodc]

Hello!

I´m a bit worried about not getting reproducible results. My intention is to design wings and foils using XFoil and perhaps some CFD (I`m an aerospace engineer so I enjoy designing and building a little bit more than actually flying) so my intention with the CNC is to get as close as possible to CAD design.

I don`t think it would be to hard to start fresh from grbl 1.1, since a hotwire does not need all the peripherals a 3 axis machine requires, not to mention the add-ons like coolants, spindle control and etc. We would just get rid off those things and end up with 2 bidimensional CNC machines to work at the same time, right?

There are other programs out there capable of doing this already but I like the efficiency GRBL is presenting as it matures and adapting it to be hotwire compatible would be the way to go. Not to mention the compatibility with all sorts of controlling softwares out there that already supports it.

What do you think the first step would be? I would be willing to go down that road and help you out the way I can to accomplish that! I have experience programming although not 100% familiar with arduino language...

[skwee]

I already have ported the code to grbl-1.1 but actually I have no resources to test on hardware. I have tried simavr for simulation, but have problems with grbl-0.9 and grbl-1.1. grbl-0.8 based grbl-xyuv works fine with simavr and I think about refining that one first. With the simulator I can actually count the motor pulses and their length and distance in the waveforms generated by the simulator and thus I have a very accurate view on everything. As I read from one of the maintainers for grbl he is testing with read hardware and logic analyser or osczilloscope.

I read that you are using Ramps 1.4 with a mega 2560 right ? grbl-xyuv has a bit of advantage over the letartare code because the feed computation is already decoupled for two independent xy / uv planes, while letartare is still for xyz + v. And consistent speed is very critical for a hotwire foamcutter. The critical code is at the end of planner.c.

If you would provide a diff of your code against the letartare code we could merge it into grbl-xyuv. It's a bit tricky, because the code in stepper.c is optimised at register level and very dependent on the pinout. I would be very happy to have someone else with hardware for testing. If you like you can mail me direct at steve.kwee gmail.com.

[rasciodc]

Yes, indeed I have a Ramps1.4 on a Mega 2560 board and a full hotwire cutting hardware available for any testings. Just send me the code and gcode and I can run it and provide final measurements of the cut.

All I did in Letartare's code was to change the pinout to be compatible with the board and I guess it would be no difficult to do the same with your coding. If you already have the new version of GRBL decoupled for XY / UV, I think I could adapt it to be used on the Mega/Ramps setup. Were you able to calculate the correct feed rate and acceleration?

Also, my email is rasciodc gmail.com

[skwee]

The latest commit was the correction of acceleration computation for both planes (xy and uv). The feedrate was ok before and had been testet on real hardware. I did some tests in simavr (AVR-Simulator) and they look very promising. I did no tests with real hardware so far. There is now a single wiki page documenting theses simulator tests. Under sim/gcode you can find the gcodes used. You have to adjust the grbl-settings to your machine and maybe adjust the feedrate to your setup. I also did a kind of gcode generator from javascript with visualisation in svg / browser but that one is still waiting to be published. If you can provide the pins used for your ramps setup I can implement a compile switch.

[rasciodc]

Nice work! I intend to give it a real test next weekend.

The way the code is adapted to RAMPS is just the way it was done here: https://github.com/CarlosGS/grblForCyclone

It adds fastio.h which contains pin mapping; It adds ramps.h which contains all enabling, writing and output coding for the ramps board; Changes stepper.c to overwrite all step commands to those declared in ramps.h

The pins on ramps are as follows:

And here is a view of the board:

Besides having 5 axis to work with (you can use Extruders 0 and 1 as axis, like I did in my milling cnc), it is also possible to control the hotwire temperature through PWM on pins D8, D9 and D10 (which already have mosfets on them) or through D6 (also PWM) with a 0-5V signal on external mosfet circuit attached to the wire's power supply.

[rasciodc]

Hello Steve! It´s been a while since my last post.

I´ve been messing around a little bit with another approach to the hotwire cutter using https://github.com/MarginallyClever/GcodeCNCDemo/tree/master/GcodeCNCDemo4AxisRAMPS but it steps the motors using digitalwrite and delays, so it is not accurate I think...also the feedrate must be optimized. Have you ever crossed with this code?

Did you manage to implement the compile switch for the ramps board? I am intending to develop a little VB application to control jogging, load gcode and report positions, since every grbl controller in the web are not capable of handling the extra axis.

[dsbeach]

skwee and rasciodc,

This seems like the best place for me to jump in. Like rasciodc, I have the Mega / Ramps hardware and am in the process of building a hot wire cutter. I'll be in a position to test and/or contribute soon.

David