Obey hard limit switches?

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.

maxspongebob

In my travels I have come across M564. Would a M564 H1 S1 at the start of my print, or just after the first layer keep the motion within the end-stops?

A Former User

No, but if you set your maximum travel range the firmware will stay within that regardless of end stops. So if your motion system is dimensioned to not skip steps you'll be fine.

Otherwise add the macro to pause or e-stop if end stops are tripped.

maxspongebob

@dc42 In answer you your question, I believe that a E-Stop signal should just stop all motion. It should not reboot the board as that would clear any of the events or activity that caused the problem and hamper investigation of the cause. On a CNC machine the E-Stop should also turn off the power to the servo's and spindle. That is unless they are equipped with a braking mechanism and in that case the brake should be applied first then power off.

The point is SAFETY. E-Stop is what you press if a problem exists that is going to cause damage to you or the machine. The stop or feed hold button is what you press if you think there may be a problem.

dc42

@maxspongebob said in Obey hard limit switches?:

@dc42 In answer you your question, I believe that a E-Stop signal should just stop all motion. It should not reboot the board as that would clear any of the events or activity that caused the problem and hamper investigation of the cause. On a CNC machine the E-Stop should also turn off the power to the servo's and spindle. That is unless they are equipped with a braking mechanism and in that case the brake should be applied first then power off.

Thanks. I guess we'll need a separate mechanism to reset the E-stop without resetting the board, possibly M999 S0 or else a new M-code.

maxspongebob

@bearer So lets say that a print is dislodged from the bed and gets wedged such that the steppers skip some steps. Then every time the head travels to the opposite side it will bash up against whatever is in the way beyond the end-stop until the job is complete.

Doesn't sound like a good plan to me.

Why not just pay attention to the end-stop signal and stop if it is tripped?

A Former User

Is that a fault of the board or the printer? The board allows you compensate for that by using the macro to pay attention to the end stops and take whatever action you desire, just like it allows you to not configure end stops at all if thats your cup of tea.

The better plan would be to use stall guard to detect the lost steps if you want to get pedantic.

maxspongebob

@bearer You have to remember, we are not just talking about small 3D printers any longer. Not every machine uses stepper motors driven from the board. Stall guard doesn't help if your motors don't stall.

My point was that a basic function of a motion controller is to cause motion based on commands to do so, and to stop based on feedback.

While my Duet 3 is working great at causing motion, it is not so good at paying attention to feedback from the system. In my opinion it should be an out-of-the-box feature to stop the motion of an axis or spindle based on a hardware signal. Virtually every other motion controller that I have used, granted they are mostly for CNC subtractive machines, does this.

Requiring that the customer also create and program macros to achieve basic functionality is a stretch. Most would just move on to another board that provides the features they are looking for.

A Former User

I really don't see the point in getting worked up over something you could easily address by submitting a pull request or issue to the online configurator to include that by default for cnc setups.*

Those who don't use the configurator can probably manage to configure it if the so choose.

*) although its no guarntee the devs would accept, maybe adding a comment to the config is a middle ground?

fcwilt

@maxspongebob said in Obey hard limit switches?:

Requiring that the customer also create and program macros to achieve basic functionality is a stretch.

Really? Given the amount of work that goes into building these machines a few minutes coding a macro is a stretch?

Frederick