Issue with Machine Observing Origin (Marlin, Estlcam, Pronterface)

Thuban · June 20, 2023, 1:33am

Continuing the discussion from Z Endstops Ignored - Megatronics 3.0 - Homing Dual Endstop LowRider2:

It has been a while since my last post due to some unfortunate events. Sadly, I haven’t had the opportunity to use my CNC machine, apart from the initial tests I conducted in January 2021. As a heads up my brain is still adjusting from 3D printer logic.

Recently, I decided to bring my machine out of hibernation and began with a crown test. However, I encountered an issue with the machine not seeming to recognize the origin points I set using G92 compared to the origin set in ESTLCAM. I recall experiencing a similar problem when drawing crowns after completing the build.

When standing in front of the machine on the side that homes, I can confirm that my machine squares itself at 0,0,0 in the back left corner (as mentioned in my previous post). For the crown test, I placed the file in ESTLCAM and set the origin to the bottom left of the crown (default position). I am using Pronterface on a Linux PC to send the gcode to the control board; I’m not using an LCD screen.

To prepare for plotting the gcode, I followed this procedure:

Home All (to square the machine)
Zero X and Y to the intended origin of the workpiece area using G92
Conduct a test movement (G1) to confirm the positioning
Zero Z using G92
Move Z up
Conduct a test movement (G1) to confirm the new G92 origin positioning
Make necessary adjustments and run the code.

However, when I execute these steps, the pen moves away from the manually set origin on the X-axis and goes to an ‘unknown’ origin point in the X+ direction (indicated by the red arrow in the picture / to the right side of my machine from operator’s perspective). I assume it’s moving to the origin set in ESTLCAM and then begins attempting to draw in an area that is not on the workpiece; to avoid dramas I’ve been setting Z 5mm above the bed for testing. For all intensive purposes it’s behaving as if it has three reference points: home, G92 manually set origin, and the one in ESTLCAM that’s failing to match the one set by G92.

The crown is drawn in the correct orientation, with the bottom facing the back of the machine and the cross towards the front of the work area.

I attempted to manually move the machine back towards the home position after setting the origin with G92, but it triggered a clamping error (I have clamping enabled to prevent axis crashes, should that be disabled?).

Thoughts:
Could it be that I am homing the X-axis in the wrong direction, similar to the issue discussed in this thread? (https://forum.v1e.com/t/mpcnc-primo-orientation-endstops-and-mirrored-project/31461)

I superimposed the drawing from the aforementioned thread on top of the crown test and matched it with the orientation of my machine and ESTLCAM. This suggests that I need to home the X-axis to the other side of the machine requiring me to move my endstop switch and re-flash the firmware, right? Seems like I may have screwed up ?

I intended to set the G92 origin at the same place as the origin in ESTLCAM. I looked into possibilities that I screwed up a setting in ESTLCAM and found the following: (https://www.estlcam.de/e2_nullpunkt.php) “…Tip: some CNC controllers always shift the origin e.g. to the left, lower edge no matter what you specify in Estlcam. However most controllers also have an option do disable this behaviour.”

Is it possible that I made a mistake in ESTLCAM, firmware, or the issue specific to using a Megatronics Control Board?

I know Pronteface is is generally used for 3D printing, should I abandon it for Repetier?

Has anyone encountered this issue and or can confirm my thinking above?

All the Best,
Josh

Thuban · June 20, 2023, 9:52pm

Updated the post above to be more clear. Sorry for the edits, trying to navigate posting again as well

These are my current settings in marlin for homing and machine

// @section homing

#define NO_MOTION_BEFORE_HOMING // Inhibit movement until all axes have been homed // Britboard-Simon (enable/disable as seen fit)

//#define UNKNOWN_Z_NO_RAISE // Don’t raise Z (lower the bed) if Z is “unknown.” For beds that fall when Z is powered off.

#define Z_HOMING_HEIGHT 25 // (mm) Minimal Z height before homing (G28) for Z clearance above the bed, clamps, … // Britboard-Simon
// Be sure to have this much clearance over your Z_MAX_POS to prevent grinding.

//#define Z_AFTER_HOMING 10 // (mm) Height to move to after homing Z

// Direction of endstops when homing; 1=MAX, -1=MIN
// :[-1,1]
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR 1 // JOSH / @jeffeb3 Z axis designed to home ‘up’ on my machine, reverse stepper wires to correct motion in RL.

// @section machine

// The size of the print bed
#define X_BED_SIZE 1330
#define Y_BED_SIZE 1250

// Travel limits (mm) after homing, corresponding to endstop positions.
#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS X_BED_SIZE
#define Y_MAX_POS Y_BED_SIZE
#define Z_MAX_POS 100 // JOSH don’t go over 120 from Z0 home (top of Y to X plate)

jono035 · June 20, 2023, 10:09pm

It should be pretty quick to get set up with Repetier, so that’s probably an easy test.

I would also try starting the job somewhere in the middle of the bed and just letting it run. That will show you if there’s something else weird going on like it’s trying to draw a truly massive crown or the entire workpiece is offset massively.

I would also take a look in the output gcode and see what coordinates it’s trying to spit out and see if they make sense.

Thuban · June 25, 2023, 2:40am

I finally got Repetier to talk to Megatronics 3.0 this afternoon; port access struggles in Manjaro linux for about two hours.

I think what’s wrong is my X-axis logic is inverted because the movements seem mirrored. My machine currently homes to the back left, not the back right. I didn’t know that was important

I flashed the firmware, instead of flipping the stepper wire, but I haven’t physically moved the end stop switch to the other side yet. I did experiment a bit, but kept getting hit with kill() halts in Pronterface after homing and trying to move the x axis away from the new home position.

I checked Ryan’s config.h vs the one I had to make for Megatronics 3.0, but I still don’t see my error; my Marlin skills are feeling rusty after COVID. What have I overlooked? Some setting with the direction it moves away from endstop?

jeffeb3 · June 25, 2023, 3:08am

It should hone to the close left, not far right.

+X should go right
+Y should go away from you
+Z should go up

If you can stand somewhere and see that, then the endstops should be at -x, -y, or close left.

Thuban · June 25, 2023, 3:12pm

@jeffeb3 Long time since we had a chat; I hope you’re well out there and glad you’re still in the community. I drew a diagram of my table to help figure out what I’ve done wrong.

I have a parking area at the back of my table where it’s currently homing; the Y end stop switches are there and cannot be moved to the front without major reconfiguration. End stop for X is currently on the left side of the gantry. I marked my standing position. I did a bit of research and it seems that most CNC home/square up to the back right OR front left corner of the table.

Post-build configuration:
+X moved right
+Y moved toward me
+Z moves (up, we inverted it in my build and it’s working great so far)

“+X should go right
+Y should go away from you
+Z should go up
If you can stand somewhere and see that, then the endstops should be at -x, -y, or close left.”

So, in the above from where I stand: +X goes right, +Y moves toward me, Z moves as configured previously); endstops are -x, -y (back of bed). Thus, Y would then be in conflict, which is interesting!

Problem:
I home/square the machine, G92 X0 Y0 Z0, and ask it to draw the bottom arc of the crown it ‘seems’ to ignore the G92 origin (behaves like that’s ‘home’) and instead moves right in the +X direction to the origin set in ESTLCAM then draws back toward the left of the machine. Hope that’s a more clear explanation

What I thought should happen:
It should use the G92 origin, that should match the one in ESTLCAM, and cause the crown to be drawn to the left (currently the -X direction).

Current Efforts To Fix It:
Last night, I flashed marlin (only inverting the logic for X stepper), so that it homes to the ALT position and planned to move the X end stop to the right side after reading SupraGuy’s response here (https://forum.v1e.com/t/mirrored-x-axis/28533/7) as it’s easier to just flip the axis and move the switch.

If I do that the machine should observe ALT as home, so
+X is moves left
+Y is moves to the front
Z axis is still sorted from our previous efforts

My quick test last night resulted in getting a kill() halt for trying to move the x axis away from home; gave up for the day.

Both setups are hilariously in conflict with the logic above in your post @jeffeb3 and the information I found here (https://docs.carbide3d.com/tutorials/tutorial-homing/).

As a result, it seems my entire Cartesian system seems to be flipped with -XY near home and +XY away from home in the workspace; EG: my machine is trying to operate in a positive coordinate plane when it moves from home, not a negative one.

**I think I either don’t understand something super important (my brain is wired for 3D printing still) AND I screwed up the orientation of my axes.

CNC machines operate in the negative coordinate plane from, while 3D printers operate in the positive coordinate plane?

How does that play out with hitting + / - / home buttons in Pronterface/Repetier?

I know you can invert the axis logic in Repetier. I don’t think you can do that in Ponter as it homes toward zero and only moves in the positive coordinate plane, which might have caused my kill() last night.

My configuration files if you need them.
Configuration.h
Configuration_adv

jeffeb3 · June 25, 2023, 7:52pm

Coordinates can’t just be whatever you want. They have to be a right handed coordinate system and if 0,0,0 isn’t where I said to put it, then you will have to do mental backflips when in your CAM.

Never do this. That will just get confusing and when you hit “print”, it will still be wrong.

This is at least a right handed coordinate system. But you need to imagine yourself standing on the other end of the CNC when setting up CAM and your workpiece.

Instead of looking at carbide, look at our docs:

docs.v1e.com/learn/coordinates/

Coordinates can get very confusing. It will constantly seem like you are one small change away from correct, and you will find a step that looks better, but it will just hide the problem a little more. Then you think you are still one small bit away, but really, you have walked 3 steps further away.

I would strongly suggest you undo any flipping in marlin or repetier and follow my advice to make the coordinates go the way I suggested and X,Y home to 0,0. You can always home and then explicitly jog to the max,max coordinate to move the gantry there. If you really can’t handle having the home position on the lower left corner, you can use the upper right, but flip your work by 180 in CAM.

Thuban · June 25, 2023, 8:59pm

Thanks for the reply @jeffeb3

Yes, I realize that and I understand that mental back flips in CAM can get sketchy! Definitely, feel like I’m chasing my tail and that xyz changes are going to theoretically cause the issues you’re talking about.

So, I’m humped into taking the machine off the table. Spin the table around, so the parking area is at the front near where I stand. Re-mount the machine, reposition the Y end stops to face the other way, flash the firmware with Ryan’s defaults, and run through basic setup and testing again.

I’ll be back and let you know how it goes

Thuban · June 29, 2023, 1:47am

@jeffeb3 Thanks mate. I did what you recommended and reviewed the coordinates section of Ryan’s page (didn’t find that until later); response marked as solution.

It took a minute to pull the machine off and make the changes required. Crown, logo, sketch test, and a 3D down cut test (making sure Z moves down) all checked out!

ttraband · June 30, 2023, 4:19pm

Seems like you’ve got your situation solved, but for anyone else looking at this later on, there’s no reason the “homing” limit switches need to be on the same physical corner where the origin is located. Default configurations assume that they are, but you can include offsets.

On my home-built 3D printer, the X limit switch is a the minimum travel for the axis, and triggers when the nozzle is about 5 mm outside of the print area. My Y limit is at the maximum Y travel for that axis, about 8 mm outside the print area. My Z axis IR sensor triggers about 1.5mm above the build plate. Even with all these different locations, once I home the machine, the origin (0,0,0 point) gets set to the front left edge of the print area with the nozzle just touching the bed. You just need to put in the right offset measurements for the machine.
In addition, most of the software I’ve used allows the designation of a “parking location” that the machine can return to with a single command. My 3D printer raises the nozzle an additional 5 mm then moves X to minimum and Y to the maximum, putting the build platform as far forward as possible. My MPCNC parks the tool to the back right corner (my vacuum hose comes in from the right side) so that inserting and removing work pieces is as easy as possible.

jeffeb3 · June 30, 2023, 4:46pm

Reversing the homing direction in Marlin gets hard when you are using dual endstops. Grbl may make this easier, or adding an offset is not a big deal, but changing the home dir is tricky, at least.