Home Position, post operation

[CriticalPoint]

When my machine returns home, it's ignoring $23, which I have set to 1. Any chance it can invert the X so it returns to true HOME?

[Strooom]

Hi,

GRBL's Homing and Post-Processor 'Returning to Home' are two separate things and they don't interact...
I'm going to assume GRBL's homing is working, if not go to GRBL's forum.

After the NC job has completed, the post-processor will include some GCODE to move the spindle to a certain location (also called Home, but could be different from GRBL's HOME). It does this by inserting some G53 (move in absolute machine coordinates) code. It first makes the Z-axis move, then makes the XY axis move (together).

So find out the machine coordinates where you want the spindle after the job, and put these X, Y, Z in the related parameters.

[maumontel]

What soft are generating your G-code?

[biasedlogic]

@Strooom @CriticalPoint

It does this by inserting some G53 (move in absolute machine coordinates) code.

Might also use G28 (safe position). e.g. Fusion 360 built-in postprocessor does. In this case @CriticalPoint needs to update the G28 position to be wherever the spindle shall get parked.
In general AFAIK it's advisable to use G28 for this purpose, as it's machine-specific-configurable.

[Strooom]

@maumontel The Post-Processor is intended for Fusion360. The PostProcessor itself is JavaScript language.

@CriticalPoint I prefer G53 over G28 - it is much more versatile. I'd rather have the intelligence in the CAM-file and not rely on the intelligence of the machine. The problem with G28 it is one command to 'return home' but in fact you always need the spindle to move to a safe height first, and then move XY home. G23 can do this with an 'intermediate' point it needs to pass through.

I think all this is making things complicated for no reason..
Using G53 is much more simple IMHO.
It is also more flexible : eg I can move the spindle to a safe position, while still on, then shut down the spindle and move XY to a safe position. This is not possible with G28.

[biasedlogic]

The problem with G28 it is one command to 'return home' but in fact you always need the spindle to move to a safe height first, and then move XY home. G23 can do this with an 'intermediate' point it needs to pass through.

off the top of my head (will check at home)
G28 G91 Z0
G28

[maumontel]

@Strooom Sorry, of course it is Fusion, my bad

[CriticalPoint]

"I prefer G53 over G28 - it is much more versatile." - I have my work cut out for me as I wasn't aware there was a choice. I've spent this year building an OX (Openbuilds) and familiarising myself with the hardware, the xPRO v3, and how it all works together. Then also software, Fusion360, Solidworks, and GRBL v1.1. I thought I understood the WCS and Offsets, however after today, I have clearly missed something essential to the process.

I started out with UGS, but could never get that to connect to the xPRO, so I went through the motions of ChiliPeppr, bCNC, CamBam, various others, and finally settled on Grbl Panel.

Today was a big push as the end of the year is fast approaching and being dissatisfied with progress, I've taken a few days off work to get a consistent workflow sorted (2 kids, job, all that jazz) so I built myself a spoil board and I was adding hardware buttons for the xPRO. I drew it all up in the F360, setup CAM and processed the job using your Post Processor as F360's (as you're no doubt aware) always paused for an M6 tool change. First thing I noticed was a 'Z -3' very early on in the G Code. Although I've always matched the position of the tool to the WCS stock point in Fusion CAM, so that obviously plunges into my stock. That's the small hole to the bottom left in the image (Later cut all the way through). Anyway, being a spoilboard, it's was a bit annoying, but I'm learning so that's the cost of doing business, as they say.

There were 3 jobs, 1 to cut 4 circles, 1 to clear 3 pockets, and 1 to engrave. As you can see, after each job the tool plunged into the stock, and travelled back to the WCS origin point on the drawing (start point, I guess you'd call it). Leaving some very frustrating trenches, and of course breaking my 1/16" engraver.

Any idea why this happened? I am clearly missing something, I just can't nail it down!

Clearances in F360 are spot on, the tool is set the the WCS origin on the model, and the machine zeroed and, in fact, the first cut (4 holes) this didn't happen, it was perfect, but the holes we're slightly too small, so I amended the sketch and made the holes slightly wider, and then regenerated the Toolpath. There was no REST machining, no contouring, no roughing or smoothing, just straight forward jobs. What's most frustrating, is that simulating the toolpath clearly shows the bit leaving the stock at the end of the job, which I would then expect your Z up, X+Y home to kick in, but it appears that this only comes after the trench has been made. Noted that the travel speed when returning (destroying) itself to the WCS point is quick, so I this tells me that it thinks it's not in the stock.

I know this isn't a forum, and it quite likely isn't an issue with your PP, but do one of you gentlemen have any ideas on where I might be fluffling it?!

[Strooom]

Hi Mike,

I know it's a long learning curve. Can you share the Fusion file with me (look for share link)?
Have you read the Wiki page that explains all parts of the gcode being generated? (Might be helpful and learn a few things more)
Finally, I am also struggling in finding a reliable gcode sender. I currently use UGCS 1.0.9
But first things first: lets check if the design in Fusion is correct.

Pascal

[maumontel]

Hi Mike,

I think my problem was similar, the paths in the wood looks the same.
I changed de machineHomeZ settings in post-processing screen, everthing was -10.
The tools goes down, up, but not at Z=0 and then to xy start then z=0 and starts working fine.
I did my tests with XPS/depron, so I did not broke any tool

[Strooom]

One problem I've noticed is the GCode Sender application..
For some reasons, some of these tools insert line breaks.
On a Machine Coordinates move with G53 this is a fatal error : the G53 is a non-modal command, so it must be on the same line as the G0 / G1 word.

G53 G0 Z-3 moves the spindle up to machine coordinate -3 (in my case 3 mm below the top).

however..

G53
G0 Z-3

... now the first line does nothing : there is no G0 or G1 on the same line
the second line makes the spindle move to Work Coordinates -3 (machine coordinates are no longer used as G53 is non-modal and only valid up to the end of the line). In the usual case where Work Coordinates Z=0 is the top of the stock, you will move the spindle down into the stock...

You can check for this problem by sending the lines manually and check the machine behaviour.

[CriticalPoint]

Guys, I really appreciate the assistance, I can't thank you enough.

With your help I now understand where the G53 G0 Z-3 is generated from; it's the Post-Process property, MachineHomeZ.

I've since set these three values to 0 as I'm unsure that I need them currently. In doing this, I now get a G53 G0 Z0 command, which (after zeroing and aligning the tool with the WCS position) sends the tool all the way up, crashing into the limit switch. (I'll expand on this at the end of this post)

Thankfully in GRBL Panel, I have the ability to execute these commands line for line, which is helping me immensely! From reading the Wiki (I have this bookmarked!) as I understood it, a G53 G0 X0 (and/or) Y0 (and/or) Z0, should send the axis/axes to the actual position where they were zero'd, so (after zeroing and aligning the tool with the WCS position) I would assume then that the G53 G0 Z0 command would essentially do nothing, as zero had previously been established and already achieved.

As an aside, GRBL Panel randomly hits a go-slow, which delays commands and mouse clicks by up to 10 seconds, and sometimes also throws a fatal error, so I've switched PC's for the sake of problem solving.

@Strooom - Here is the Fusion file, I've done nothing to change it since the cuts as this would defeat the purpose. As you've likely already noticed from the image above, GRBL Panel (at least) doesn't insert a line break in the G53 command.

Further explanation;

Here is the process, I might well be overlooking something super simple!

I always home the machine using $23=1 (reverse X axis/rear left of the machine as observed from the front) I have a 2mm pull off value for $27. I then;

1 - Zero G54 in the offsets tab
(2 - Note that the machine position is inverted)
3 - Check that the current offset is G54
4 - Jog the machine to meet the WCS origin I set in F360, once satisfied, I Zero all 3 axes.
5 - (line for line) I execute the G Code until I hit G53 G0 Z0
6 - The Z axis then travels all the way up, crashing into the limit switch, causing an alarm, number 7.

I really hope I'm not being an idiot but at the same time, I'm hoping it's really easy and I'm missing a trick.

Again, further thanks for your help on this @Strooom and @maumontel

[CriticalPoint]

And further to this, once I've got the machine parked at the WCS origin, I can manually execute G53 G0 Z0 and the Z axis will remain in position, as one would expect. I can then manually raise it 10mm and execute it again, and it will return to the WCS origin, right on top of the stock, ready to mill.

I then load the job (exactly as below) and step through to G53 G0 Z0, and the Z runs high and hits the switch. The 'why' has me totally stumped!

Is it me, or should this not be a thing? 😆

I've familiarised myself with lines 1 through 17, and I can't see anything there that would affect the machine position, only plane selection, units, feed rate and various (really helpful, thank you) comments...

[CriticalPoint]

I'm still going strong 🤣

New information which might highlight an issue, I completed a really simple test cut by removing the G53 G0 Z0 string from the G Code;

And when it hit a G53 X0 Y0 at the end of the job, the machine remained parked, the Z axis retracted upwards and crashed into the limit switch again, which is incredible as it doesn't contain a Z0 command. How strange is that, anybody any thoughts on this?

[Strooom]

I've since set these three values to 0 as I'm unsure that I need them currently. In doing this, I now get a G53 G0 Z0 command, which (after zeroing and aligning the tool with the WCS position) sends the tool all the way up, crashing into the limit switch

Let me explain Machine Coordinates versus Workpiece Coordinates (WCS) :
Machine Coordinates are the abolute position of the machine. After power-on the machine doesn't know where the spindle is, because it is an open-loop design : it controls the motors, but it does not receive back the position of the motors.
In order to know where the spindle is, you let the machine perform a 'Homing Cycle'. It then moves all its axis in the 'positive' direction, until it hits the limit switch. This position is then Machine coordinates (0,0,0).
As this is the most 'positive' position, it means all other machine positions are in negative machine coordinates. (This is how GRBL does it and most CNCs do it, you can see this in your GRBL panel).

After hitting the limit switch, GRBL will move the machine a small distance away from the (0,0,0) position, so that the limit switches are not really on the edge any more, preventing that they are not falsely triggering for any small vibration or other reasons. this is your 2mm pull off value (-2,-2,-2) ie. 2 mm away from each limit switch.

Workpiece Coordinates are relative coordinates measured from a reference point on your workpiece. CNCs use Workpiece because it means you can have the same CAM file, no matter where your workpiece is on the machine : You put the stock anywhere on the machine, move/jog the spindle to the reference point (the 'setup' point in Fusion), then you 'Zero' the axis. Because Fusion generated GCode relative to the 'Setup Origin' and you Zeroed the Workpiece Coordinates with the same physical point, they work toegether.

There are 6 (or more) different 'sets' of Workpiece Coordinates (sometimes called G54 G55 G56 etc, referring to the gcode that selects them). I think you will only need one, I suggest G54.

So each point has 2 coordinate values : absolut machine coordinates (measured from hime limit switch, negative) and workpiece coordinates (measured from workpiece origin)

Workpiece Coordinate 0,0,0 most likely maps to some negative Machine Coordinates.
WCS 0,0,0 NEVER maps to Machine 0,0,0
In your work offsets screenshot, they are all 0, which I think indicates you are not using machine and work coordinates in the proper way..

Normally Gcode contains a G54 meaning all the coordinates are to be treated as being Workpiece coordinates

When using G53, you tell the controller (for this line of GCode) to interprete coordinates as Machine Coordinates : so G0 G53 Z0 tells the controller to move the spindle up all the way. Because this Z0 is the position where it tripped the limit switch during the Homing cycle, it will trip the switch again. This is why machineHomeZ should be a small distance before zero, eg -2 (remember machine coordinates are always negative), this will move the spindle all the way up, 2 mm below the upper limit switch.

Now, after all this, here is the proper sequence to do things :

1. design your toolpath in CAM, using a well defined/ known point on your stock as 'Setup Origin' and use WCS set 1 (G54) in your post dialog box.
2. home your machine
3. move the machine (using jogging - not forcing it by hand) to this well/defined point on the stock
4. zero the axis for WCS1 / G54
5. execute the gcode program

Tip : by moving the machine to the well know stock point, then moving it up 20 mm and then Zeroing, your WCS origin is 20mm above the Fusion origin. If you then execute the file, it will do everything, only 20mm above the stock, just milling in the 'air'. This may be a good first test to see if all is going well.
Then you go back to the real origin (this will be 0,0,-20), you zero again and re-execute the same file, this time for real milling.

Good Luck

[CriticalPoint]

@Strooom, thank you. I've since flipped my X to conform to the standard, so now everything is negative, one less thing to factor in.

I followed your '5 Steps to Success' and here is the (almost) finished test I quickly drafted up in F360

Simply adding the negative value of -2 as a variable when Post Processing in F360 has sorted the hitting of the limit switch, turns out it was very simple, I simply lacked understanding.

Your knowledge and advice is invaluable and I am forever grateful. One further question; How do I buy you a beer?