@jengland My guess is you'll need some kind of unchanging reference of a known length. For instance, two switches 'exactly' 500mm apart, and initally measured by some other means. You can then drive the carriage (or tool or, other part of the machine) into one switch, pull the current position from the object model and store it as a variable, do the same for the other switch and then compare the difference in position to your reference. If it differs by some amount, update the Steps/mm for that axis automatically.

Microswitches are cheap but might not be suitable because of their repeatability error. Maybe you'd want to create a switch using two conductive points, like some cncs use for tool offsets:

https://shop.carbide3d.com/collections/accessories/products/bitzero-v2?variant=32936948236349

@markz thanks that solved it

@Stephen6309
So, essentially write an M6.g file and when the gcode file calls M6, this would run the M6.g as a 'macro' then continue where it left off in the gcode once the M6.g code has completed?

Hmm, that's not as complicated as I expected!

Thank you 👍

@miss-rebekah
The sad thing is we move the tool in 4 axis and the "workpiece" is Z moved (like most of 3D printer).
If I had a "trunnion" it would be more simple, I agree but no...
I'm programming 5axis tool path on Fusion 360
It is just for now I am anticipating some work on a machine my firm is designing.
I'm making the postprocess and this issue came to my mind.

"the duet is just playing back the g code it doesn't care how long your tool is"
I'm aware of that and it scares me a lot

@miss-rebekah

i figured it out since I'm using work offsets for tools i wasn't calling a tool number once i did that m3 works

@jay_s_uk Got it, thanks.

@nightowl999

Thanks for the pictures.

Frederick

I think the problem is solved 😄

@steve123
I've connected the PSU to the Duet board with 2.5mm^2 solid core wires, I think that's 14 AWG.

You have a good point about the total amperage though, maybe my PSU isn't quite able to keep the voltage steady. I've set the M906 command to allow max 2A instead of 3A and so far it seems to work much better. I haven't heard the same noise anymore and the "B phase disconnected" error hasn't popped up anymore either.

@sinned6915 How fast would you expect the mechanism to stop if it triggered an endstop? Abrupt stops can cause all sorts of problems. OTOH, nothing is more abrupt than hitting a mechanical stop at the end of an axis.

More importantly, why is your printer missing steps? That really shouldn't happen under normal operating conditions. If it is, you have some mechanical and/or configuration problems that should be fixed.

Of course, bad things can happen- there's no accounting for stray fingers/cats, dropped tools, seized bearings, etc. , but with controlled access to the machine maybe such events are rare enough that they don't require active measures.

@steve123

I suggest the constant reloading might not be intended or desired.

Right, but you provoke this behaviour with three methods:

define a pin which is triggered on both edges (up and down) test for that event immediately after defining it in config.g couple this with a reset of RRF (which presumably leads to a signal change of the pin on reboot)

First thing to note: you should not check the trigger in config.g with M582.

Second, you need a well defined signal to trigger an event: What level do you expect io8.in to represent if your switch is "open", i.e. disconnected? High, low, or something in between?
To overcome this issue, it is good practice to activate the pull-up of the pin and then switch to GND. This has the additional effect that you now only have to check the trigger signal on the falling edge.

Third, I strongly recommend not to trigger such a fundamental event directly. If you invoke a macro (which in turn calls M112), you can take optional measures against repetitive stops (i.e. implement a global variable), in case you encounter a similar behaviour as now.

Put something like this or similar into config.g:

M950 J0 C“^io8.in“ ; define io8.in as input pin 0 (P0), activate pullup (normally high) M581 P0 S0 T3 R0 ; call macro „trigger3.g“ if button pulls P0 to GND

Create the macro "trigger3.g" in the /sys directory:

; trigger3.g - Emergency Stop M112 ; do it

Note of caution: Usage is at your own risk. Untested, my Duet is currently out of reach.

You can, yes, but a lot will depend on what kind of servos they are. In practice it may not end up being feasible. You would need to find a lot more detail about what is in the machine currently.

@tealfixie the M585 command is normally used to probe in the X or Y direction, not Z.

@n7jti I'll need to pick your brains on that, probably. I still haven't quite got my head around how to do that, yet.

@yycsparks said in Homing issue with Dual endstop:

Thank you for sharing the video that is really slick, and my config should result in the same result I assume?

Well if your printer has two Y steppers and three Z steppers you should see much that same.

On a side note what printer is that?

Something I designed myself. I was reading about different types of printers and was intrigued with the "MarkForged" kinematics. So I set out to build one. I also chose to try belt drive for the Z axis - very pleased with the result.

Frederick

headache.jpg 😉

correct, endstops are only active during a homing move. You could repurpose them after homing to act as an emergency stop trigger as well.

And yes the endstops would need to be accurately positioned to use them in combined format. So having a way to physically adjust the trigger point is important. Otherwise, you would need to use the split axis method and reposition them with gcode to account for the offset.

@maxway3000 yes, that would work