Obey hard limit switches?

Gerrard

Ok... that's a good point, and its linked to another problem I haven't yet solved. - That of using multiple work coordinate systems (G54, G55 etc).

I have changed my working envelope to be -80 to +80 in the Z axis so that when I set the top of my work piece as Z=0 I can still move up and down. If I set them as 0 to +80, then I couldn't move down.

For now, I'm setting my home at the front left corner, top of the job as zero using G92 X0 Y0 Z0. With the previous control board, I would have used G10 L2 P2 X0 Y0 Z0. With the Duet I can't see any evidence that the G54, G55 etc work offsets have any effect.

I'm going to try using the Ooznest web control, and see if that helps with this problem...

Any other suggestions are welcomed.

Phaedrux

I'm not a CNC user, but I think G54, etc should work.

https://duet3d.dozuki.com/Wiki/Gcode#Section_G53_Use_machine_coordinates

Jacotheron

According to your description for home limit locations, mine is setup very similar (X min, Y min, Z max - stall detected). Z is also allowed to go below 0.

When I set the origin of the stock, I have a macro that simply runs G10 L20 P2 X0 Y0. I run this when I am happy with the current XY as being on top where the cutting should be, and it will show as XY 0 after running (also a good idea to set G54 so that you switch to the first work offset - mine is set in my config, so I am always in it).

Right after the probe, to determine the top of the stock, I run G10 L20 P1 Z24.25 - The Z24.25 is my measured height of the probe block.

The idea of the Work coordinates is that while the machine knows exactly where the spindle is, it can run relative commands related to an origin. As long as the stock does not cross to the outside of the limit switches, it should work as expected.

Gerrard

Hi Jacotheron,

I think you've highlighted my problem without realising it... I was using G10 L2 instead of G10 L20... I was working off memory which clearly isn't as reliable as I would like.

I'll try that and report back.

Regards

Gerrard

Hi All,

I'm back on this problem after smashing another 2 Z limit switches on the weekend, while hooking up a tool height probe.

Is there a way to hook up the limit switch - either to the switch pins or to other IO pins whereby I can prevent further travel in that direction of that axis only, without interfering with the program running (i.e. I don't want to hook it up to an E-stop).
There's no good reason why the machine should crash and for CNC machines there's no reliable way to define the working envelope without using end stops.
What are other people doing? I can't be the only person with this problem...

Cheers

fcwilt

@Gerrard said in Obey hard limit switches?:

Is there a way to hook up the limit switch - either to the switch pins or to other IO pins whereby I can prevent further travel in that direction of that axis only, without interfering with the program running (i.e. I don't want to hook it up to an E-stop).

Hi,

I'm not sure why you don't want to use an e-stop input. Can you explain?

And when you mention interfering with the program running what do you mean? How can you stop movement without interfering in some way?

Thanks.

Frederick

Gerrard

@fcwilt

I don't wan't to E-stop on a travel limit for a few reasons - Keeping in mind this is a CNC application:

Z up travel limit can easily be trivial - i.e. user has defined a tool lift of 20mm between moves, which works fine on some jobs, but others (different Z=0 height) it might be too much - and I would need to adjust my programming to compensate - whereas if the Z limit switch just stopped FURTHER travel it would continue the program without error. Soft limits (work boundary) already has this effect.
E-stop causes the home (G10) position to be lost.

What I expect is either:

Replicate the effect of the soft limits - i.e. continue with program, no further movement in that axis until coordinates come back within limits. (This also has negative effects, but it's a lesser impact).
Pause program completely (stop in place - do not use pause.g) wait for operator input

Ignoring the endstop (current practice) is the worst possible action.

fcwilt

Hi,

Thanks for the feedback. I think I understand.

A couple of thoughts.

End stop inputs don't do anything special unless they are configured to do so.
Inputs can be configured to run specific chunks of code called triggers. Have you investigated them?

Frederick

Gerrard

@fcwilt

Thanks for the reply.

How can I configure end stops to do what I want? What are my options for configuring?
I haven't looked into triggers, but I will.

fcwilt

@Gerrard

Regards triggers: You use M581 to configures triggers.

Frederick

Phaedrux

https://duet3d.dozuki.com/Wiki/Gcode#Section_M581_Configure_external_trigger

Because RRF is configured on the fly you can define a piece of hardware at the time of usage. So in your homing files you can define the endstops as endstops, and then your G1 H1 moves will trigger the endstop and set the axis position limits. Then you can configure the endstops as triggers at the start of the job. The trigger could be an e stop, or it could execute whatever gcode you want to put in the trigger file. You could pause the job, for instance.

Gerrard

OK, thanks for that, I think we're getting somewhere... If I'm reading this right, there are 32 available triggers on the Duet3, the event that occurs is defined in a gcode file - triggerX.g (X for trigger number) and it's called by the T parameter of M581.

So that takes care of the triggers during jobs, but what about other Macros or manual movement (jogging etc)? Is there an overriding default behaviour? Should it be defined as a trigger in config.g, then configured as an endstop for the homing operations and a trigger again after homing?

Phaedrux

@Gerrard said in Obey hard limit switches?:

So that takes care of the triggers during jobs, but what about other Macros or manual movement (jogging etc)? Is there an overriding default behaviour? Should it be defined as a trigger in config.g, then configured as an endstop for the homing operations and a trigger again after homing?

Since it's configure on the fly, the last configuration will stand, so it's probably best to have the endstops defined in config.g as you normally would. Then in your homing files define them again as endstops for homing, since you don't know exactly what state might be in place before homing. Then if you want it defined as triggers before a job, you can use the macro file start.g which gets run before a job starts.

psychotik2k3

personnally here is what i do and i use G54 and G55

I have an end stop to the max Z height, i use it to home Z
i also have a simple probe
i use it with G31 so when the prob is done i have the z position of the tip of my endmill from the spoil board.

after that what i do is a G0 Z67 F400 H3 (z67 is my maximum z height)
so the z carriage will go up trigger the zstop and replace the actual z value as z limit

and about the G54 G55, what i do is i always configure my origine point as teh bottom left down point of either my stock or my object in fusion 360

then on my cnc i go in X and Y to what i want to be the 0,0 position (d'ont care about the Z as i allways know my hieght from the spoil board) then i do
G10 L20 P2 X0 Y0
G54
go to my tool change position perform the tool change it's a manual one) then do the z probe as explained earlier
do a G55 and go to 0,0
and start the milling operations

the only thing i have to do is to reset the z limit height at 67 at the end and do a zhome and a G54.

psychotik2k3

i knwo there is a lot oof redundancy with G54 G55 then G54 without doing anything but my code is generated by a post processor.

G90
G21
M84 S0
M451
;Switching to G54 workspace
G54
M291  P"using current X and Y coordinates as X0 and Y0 for G55 workspace" R"XY origins" S3 X1 Y1 Z1
G54
;Saving machine coordinates to slot 0, use G0 R0 X0 Y0 to return
G60 S0
;using current X and Y coordinates as X0 and Y0 for G55 workspace
G10 L20 P2 X0 Y0
;Switching to G55 workspace
G55
G54
G28 Z10
G0 Z67 F400
G0 X550 Y30 F10000
M291  P"Tool 24 D=2 CR=0 " R"Tool change" S3 X1 Y1 Z1
; COMMAND_TOOL_MEASURE
M291  P"Attach ZProbe" R"Probe" S3
;Switching to G54 workspace
G54
;Z probe at current position
G30
;Switching to G55 workspace
G55
G0 Z67 F400 H3
M400
M291  P"Detach ZProbe" R"Probe" S3
;Returning to S0 position
G0 R0 X0 Y0 F10000
M114
;Switching to G55 workspace
; *** START end ***

maxspongebob

@Phaedrux
For the life of me I can't understand why end-stops would be ignored EVER.

On a 3D printer reaching an endstop simply means that maybe some steps were skipped and you get a bad print. Not a big problem. On a CNC subtractive machine when you reach an endstop things break. Heaven forbid that you have a carbide tool running an 24000 RPM and it goes past an endstop. When that happens stuff goes flying at projectile speeds. Someone is going to get seriously hurt.

Honestly, telling a customer that they need to write their own macros to make end-stops function the way that every other CNC motion controller works already is not right. I think you should REALLY think about limiting your liability and include the capability to use hardware end-stops ALL THE TIME. As your product is applied more and more in the CNC realm your solution needs to keep up.

kazolar

@maxspongebob I made a small tweak to the firmware to add a support for my own M113 command -- I tested it and using a trigger option when an endstop is triggered, the command runs and the duet stops immediately and reboots -- exactly how mach3 handles this condition. Yes I don't understand why there is no such similar behavior in duet by default, and I totally don't understand why have have hard limit switches if the machine is allowed to blow past them, CNC or 3D printer, but my solution is 4 lines of code in the firmware and a few lines in gcode scripts.
To be honest -- I thought this was baked in by default. I was sorta confused when I started doing my mill cnc conversion using duet 3 to find that there is no way to even do it. There is actually no way. If you setup a eStop trigger you have to reset or powercycle the board, no good. My custom M113 does exactly what eStop button in the webui / panel due does-- stop the world (immediately) and reboot. Works perfectly

Phaedrux

@maxspongebob I'm not saying this is how it should be, I'm simply explaining how it is currently. Having the option to obey endstops at all times when in CNC mode may be possible and is a valid firmware request. I'll raise that.

You can also make a thread in the firmware wishlist forum explaining how and why you think it should work if you want.

dc42

@Gerrard said in Obey hard limit switches?:

So that takes care of the triggers during jobs, but what about other Macros or manual movement (jogging etc)? Is there an overriding default behaviour? Should it be defined as a trigger in config.g, then configured as an endstop for the homing operations and a trigger again after homing?

You can configure a trigger to be active only when running a job from SD card.

dc42

@kazolar said in Obey hard limit switches?:

There is actually no way. If you setup a eStop trigger you have to reset or powercycle the board, no good. My custom M113 does exactly what eStop button in the webui / panel due does-- stop the world (immediately) and reboot.

Would it be better if emergency stop (M112) rebooted the board automatically?

The disadvantage i can see with doing that is that if the board is being fed GCodes via USB or from an attached SBC, it may start executing commands again immediately. I think that's why M122 was defined originally to require a manual reset. Similar how a proper Emergency Stop switch has be reset before you can run the machine again.