@ZipZap , your post gave me the information I needed to figure out, on my own, along with @OwenD help... basically what David handed me on a silver platter.

Thanks to everyone for their help! This forum has always been excellent.

This looks like a worthwhile project. I have a few duets in use that could have used this board instead.

If you want to target a larger spectrum of users, make the motor power supply accept up to 48v; this, too, is very common in industrial use, but will provide better performance, especially with larger motors.

@jay_s_uk
Except the only kit seller no longer sells kits...

I set up a duet, and it works great with the touchscreen, for setup. But it's a repetitive task that does not need a fragile touchscreen in this environment. Especially when I'd like to put that screen to use elsewhere.

I tried to configure the endstops as a Start button to run a macro (and to trigger a homing sequence), but it's not working. I'm thinking it's in my config, since neither work, or perhaps it can't work when the control is idle.
Is this possible at all? (Setting up a mechanical "Start" button and mechanical "HomeAll" button?)
Here's my code segment in config.g:

; Triggers, for initiating a "FIND HOME" Command and Start a Cycle
;	First, configure the inputs:
M950 J1 C"!^xstop" ; Input 1 uses e1Stop pin, inverted, pullup enabled
M950 J2 C"!^ystop" ; Input 1 uses e0Stop pin, inverted, pullup enabled
;	Second, configure the triggers:
M581 T2 X S0			; Home the Z, on X limit		NOTE:  T{N} = runs the macro "sys/trigger{N}.g"
M581 T3 Y S0			; Start a cycle, on Y limit

My Trigger macros are simple:

; Trigger2.g MACRO
; Disable START button:
M581 T3 P-1 ; don't invoke trigger 3 (cycle start) on any input change while running
M106 P1 S0				; TURN OFF GREEN LIGHT connected to Fan
; Call the Homing macro:
M98 P"HomeAll.g"
M106 P1 S255				; TURN ON GREEN LIGHT
; Resume checking the input:
M581 T3 Y S1				; START a cycle on Y limit

Trigger3:

; Trigger3.g MACRO
; Triggered on START button

; M581 T2 X S1			; Home the Z, on X limit		NOTE:  T{N} = runs the macro "sys/trigger{N}.g"
M581 T2 P-1 ; do not invoke trigger 2 on any input change any more
M106 P1 S0			; TURN OFF GREEN LIGHT
M106 P0 S255			; Turn ON fan
M98 P"MainGCode.g"
M106 P1 S255			; TURN ON GREEN LIGHT
M106 P0 S0			; Turn OFF fan
M581 T2 X S1			; turn it back on

Any suggestions would be welcome. Thanks in advance.

@tenaja said in Move Extruder motor with Feedrate?:

G1 E1 F5

Thanks, but I already knew what you had posted--that is why I mentioned the F50 for the "e-only" move. (Literally, the comment "; even f50 does not help")

To reiterate, why does this:

G1 E1 F50

Go at the same speed as this:

G1 E1 F5

I would expect the first to go 10x faster than with an F5. My max speed is set to E3200, and that should be moot anyway if it will go faster when the Z axis is moving.

Thanks again!

@yngndrw if you are only using external drivers, you might also consider setting it up for opto-22 i-o modules & boards. Then the control is a mere ribbon cable, and every port is configurable for in or out, optically isolated, and configurable via the module selection for the appropriate voltage & load. The boards come with screw terminals. This is a random photo:
http://oakbluffclassifieds.com/Funny-Listings/Opto-22-G4PB16HC-board-with-qty-4-G4-IDC5-modules-picture.jpg

The boards come in many sizes, from 4 sockets (maybe less) to dozens. There's also a handful of module sizes, so people can pick what works for them.

It's not a super cheap system, but it's very flexible and customizable, and also robust. (Generic modules are a couple bucks each.)

If you wanted tight control of a few inputs, you could hardwire those on your board.

@yngndrw sorry, I overlooked where you said you were omitting the on-board drivers; I think that is a great decision. That will make it much better for bigger projects.

This looks like a worthwhile project. I have a few duets in use that could have used this board instead.

If you want to target a larger spectrum of users, make the motor power supply accept up to 48v; this, too, is very common in industrial use, but will provide better performance, especially with larger motors.

@fcwilt said in Bug: Gcode within trigger is interleaved with later build gcode?:

@tenaja said in Ways to ensure gcode within trigger is uninturupted?:

You will note that at the "top", I disable the triggers, then run another program, then re-enable the triggers.

From the M581 docs:

Polling for further trigger conditions is suspended until the trigger macro file has been completed.

Did you verify that your trigger could be re-triggered while is was executing?

Frederick

I am not sure if you got your answer to this, but the word "suspended" in the sentence above could be rewritten "queued for later execution". That is why I disabled them--if you press the button several times during a macro execution, it stores up the number of button presses, and runs them upon completion. This was catastrophic in my application.

@markz, the d3 can put out 6 amps, which is more than most motors for a mill that size can handle.

Be aware that the duet firmware has no backlash compensation, which is helpful in a mini mill like the taig--and required for any precision work. It also is missing tool offsets (extremely helpful), and uses nonstandard implementations of some codes. (They "meet" the technical "standards" specs, but not the traditional way standard cnc machines work.) For instance, iirc, "optional stops" are ignored, and this can be catastrophic on a cnc.

There is, however, a post processor (python?) on this forum that can add backlash comp to your gcode for you; do a search and it should be easy to find. You might be able to retrofit it to other missing features, too.

I haven't used a taig, or the d3, but between my experience with duet 2's, numerous Sherline cnc's, numerous other "nema 23" applications, and evaluating the d3 specs, it should work fine for a low budget setup.

It will take a lot of setup, since some things are counter-intuitive on cnc applications, being entirely printer-focused. My experience with Linux CNC on a few cnc machines was much faster than using a Duet on a "cnc" application. However, this forum is filled with very helpful people, so if you aren't in a rush, I'd say go for it, of you cannot afford a Linuxcnc (or BBB Machinekit) setup. A taig is small enough that many of these shortcomings may be moot, and a small control board is a definite advantage.

@jens55 I would argue against powder coating on most 3d printer parts, vs anodizing. Powder coating cannot handle heat the same, it chips, and can have highly inconsistent thickness, depending on the deposition method.

Most lower volume powder coated parts are done by hand, so the thickness at one end can be twice that of the other end. On a cosmetic part, this is moot. But on a part that mounts a hot end, this can effect the output quality, as the nozzle will no longer be perpendicular to the bed.

Contrast that with anodizing, which is always the same (usually insignificant) thickness. Very very thick anodizing is a fraction of the thickness of the thinnest powder coating.

Then again, on an Ender, most of this is moot. The rest of the components are made with such loose tolerances that you will have a tough time seeing a change. Sure, you might have to grab your hot end and tweak it to make it square to your build plate, but you might have to do that with a stock Ender anyway.

I recently had some parts made at FirstCut (aka protolabs, protomold), and I had them made from 7075, mostly because it was cheaper than 6061. (It machines very nice, whereas 6061 is gummy.) I had to drill an extra pair of holes in that aluminum, and it was super difficult to drill. I did it by hand, and I was wishing I had my drill press and a vise!

Point is, 6061 is quite easy, compared to steel, but 7075 is almost as hard as soft steel. There's more to the question than just Fe vs Al, because you never just buy one element in your metal stock.

For an Ender, there are very few parts that would benefit from steel. (Heat breaks are one.) The weight is always a negative, especially if it is on a moving part.

This is my entire Trigger2.g file:

; Trigger2.g file in SYS folder--used to HOME the machine when HOME button is pressed.
; Functional as of 1/11/21

; This trigger calls the HomeAll macro.


; Disable START & HOME button:
M581 T3 P-1					; don't invoke trigger 3 (cycle start) on any input change any more
M581 T2 P-1					; don't invoke trigger 2 (Home start) on any input change any more

M98 P"/Macros/HomeAll.g" 	; Call the HomeZ.g macro:

; Resume checking the inputs:
M581 T3 Y S1				; START a cycle on Y limit
M581 T2 X S1				; Home Z axis

I have two triggers, a Start button, and a Home button. They are tied to my X&Y limit inputs, which are not used elsewhere.

You will note that at the "top", I disable the triggers, then run another program, then re-enable the triggers.

I am not sure if this is exactly what you wanted, but it fits the topic title.

@dc42 ...for future readers, that gpIn is case sensitive! I tested it just to be sure, and sure enough, it fails with lower case.

Wherever I was reading about it, I could not tell if it was an i or an l, but it was neither... it turned out to be a capital I (capital i, not L). I had to do a ctrl-f search, and even then it was unclear.

@alankilian Thanks!

But shouldn't we be able to delete the .bin files?

And if we do not use pause, resume or cancel, there is there a reason to keep those?

I guess I should just start deleting, and see what happens...