GCODE question about 4th axis

chucktilbury

chucktilbury
I have a little problem running the 4th axis under MASSO. The speed of it is slow compared to the other axes. I am doing engraving on tubing and I am pretty sure that the 4th is set up in a reasonable way, but since it moves slower cuts along the A axis are much deeper than ones along the X axis. There does not seem to be a way to contrive a solution in the MASSO setup.

Here is a snipet from the gcode file.
G1 X 0.3861 A 25.839 F 10.00
G1 X 0.3843 A 25.888
G1 X 0.3824 A 25.909

I am looking for a way to get the A and X axes to move at the same speed. I want to programmatically change the GCODE so that the tool moves over the surface at a consistent speed based on the relative speeds of the A and X axes.

As I understand it, a line like
G1 X 0.123 F 10.00 A 25.123 F 12.00
would be a syntax error. Isn't that correct?

What I am looking for is the correct syntax so I can make my post-post-processor do what I want.

Can anyone help with this?
 

chucktilbury

chucktilbury
I use QCAD/CAM to generate the gcode from a DXF file. Then I use gcode-ripper (see here: https://www.scorchworks.com/Gcoderipper/gcoderipper.html) to wrap it around the cylinder. I wrap it around the Y axis, so ripper is translating the Y axis into angles. Now, I am fairly sure that the ripper is not doing right. I have been digging into the code and it looks like it is not using the correct diameter to calculate the new angle when it generates the gcode.

I suppose I could just go and buy better software...... <<<sigh>>> I do have to say that for the simple things I need to do, like making holes and cutting outlines, QCAD is perfect. I can set up a job like that is 5 minutes flat.

I will try and post a pic of my setup tomorrow. It's very simple....
 

evermech

evermech
You have probably answered your own question. If it isn't calculating the circumference of the tube properly then how can it turn the part the correct amount? Also if the y axis that is set up to be a linear axis is not translating over to degrees accurately then you have 2 issues to deal with.

Guy
 

masso-support

MASSO Support
Staff member
Hi @chucktilbury

In the example you posted above have you tried increasing the Feedrate. Since the 2 axis move together they will move at the speed of the slowest axis. You have a rate of 10 degrees per minute so it will be at the rate of 0.02RPM so 1 RPM every 36 minutes.

There is a program called rapid rotary which does conversion of Gcode for rotary and uses inverse time mode for the rotary axis. See the video below.

I haven't tried it myself but it is on the to do list.

https://www.ganotechnologies.com/cnc/rapidrotary/


Cheers

Peter
 

chucktilbury

chucktilbury
I have been playing with rapid rotary quite a bit today. It took a little effort to get it to actually digest the input that I have for it. It's pretty picky about the input. For example, it does not like spaces after an "X" and requires them before one. It also requires the G90 G94 sequence before any movement is seen.

It seems to do what the author says it will do, but I am having one significant problem. It seems like some of the G0 commands are being ignored. I have attached the gcode. The effect is that the tool does not lift when changing paths. For example, on lines N1050 - N1090 (16-19 in the file) the tool plunges to Z=0 and then begins instead of stepping down to 0.5 and then plunging. The same thing happens for all of the other lifts. Then at the end, moving back to the origin is ignored as well. Do you see any syntax issues?

I suspect that the G93 is interfering with the G0 commands.
 

Attachments

  • logo1a_wrap_G93.nc
    665.9 KB · Views: 14

masso-support

MASSO Support
Staff member
Hi @chucktilbury

Thanks for the test file. I ran it on my setup and can see that it was ignoring the G0 as you described.

I did some more testing and found that the cause is the lack of a feedrate in the command. (Yes I know it shouldn't have a feedrate :)

Further testing showed that a G1 command without a feedrate is also ignored.

I have now made out a software bug report for this to be investigated.

Fortunately it looks like all of your G1 commands have a feed rate at the end of them and you have very few G0's (10 of them). To make it work for you in the short term do a search using a text editor for G0 and add a feedrate at the end of each of these lines. It doesn't matter what feedrate you enter it will use rapid speed so just use F1. So long as it has the feedrate in the line it will rapid. In the meantime we will investigate why it isn't working.

Thanks for letting us know.

Cheers

Peter
 

chucktilbury

chucktilbury
I have verified that the work-around you described works. Thanks for taking a look.

I also have a couple of observations about the "rapid rotary" software.
  1. It does indeed work.
  2. It's picky about the input. That's not unexpected. There are lots of variations in gcode, but the errors that it shows are not helpful.
  3. On small features, (see the pics I have attached) it still moves very slow. That's not a bad thing, but it means that I cannot use it with a rotating engraving tool without digging holes in the part.

About the pictures.
  1. The complete product. My web site is https://whistlemaker.com/
  2. The actual engraving that I am doing. I am using a diamond drag tool at about 25 IPM.
  3. The setup. It's a el cheapo rotary head set in a minimill conversion. The motors are all 425 oz/in steppers running at 3A.

About how I arrived at these NC files.
  1. I used QCAD/CAM (which I like very much) to get the flat gcode.
  2. Then, I used gcode-ripper (https://www.scorchworks.com/Gcoderipper/gcoderipper.html) to "wrap" the flat gcode around a cylinder.
  3. I used a short python script to fix up the gcode so that "Rapid Rotary" (https://www.ganotechnologies.com/cnc/rapidrotary/) would accept it. Plus some hand editing was required to take out the M3/M5 commands. If anyone is interested in the script, let me know. I tried to post it, but the spam filters would not let me.
  4. Use Rapid Rotary to adjust the feeds to a reasonable A axis feed rate. Plus some hand editing to add F commands to lines that did not have any.

Note that the output of gcode-ripper does work, but the A axis moves very slowly. Use the "feed adjust = None" option. If you let it adjust the feeds, then the output is unusable. Some of the A axis commands literally take days to complete, even after filtering with rapid rotary.

Also, if you want to use QCAD/CAM, (https://www.ribbonsoft.com/en/) you can get my post-processor on my github (https://github.com/chucktilbury/masso-pp) The python script is there as well. Only the professional version has CAM and it is pretty simple and basic. For example, it will not do pockets unless you put them in the drawing, but that's why I like it. What do you expect for $99 US? :)

Anyhow, I am looking forward to a fix for the problems with the G93 code.
 

Attachments

  • 20191025_103817.jpg
    20191025_103817.jpg
    1.2 MB · Views: 10
  • 20191025_103748.jpg
    20191025_103748.jpg
    969.8 KB · Views: 10
  • 20191024_102438.jpg
    20191024_102438.jpg
    1.2 MB · Views: 12

masso-support

MASSO Support
Staff member
Thanks for the photo's Chuck.

I was wondering what it was doing when I was running your file. They look really good.

Cheers

Peter
 

chucktilbury

chucktilbury
Thanks! This is a new era for me. My instruments are going to even better than before. I am planning some changes that will make a big difference in the sound as well as the cosmetics of my instruments. Very exciting!
 
Top