@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.

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!

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

The industry standard for VFD's is 0-10v for the full range of speeds. However, you may need to poke around in the menu of that one to see what it is set for, because some can permit setting other signal requirements.

I really like the Duet, and have purchased a handful for tabletop units that are not printers. However, a machine that large is going to have backlash, and Duet requires a g-code modifying script...and that script is going to modify destination values rather than desired locations, so it is a little more consfusing if you need to stop mid-part and make an adjustment.

My preference is to use LinuxCNC for larger machines. It is very proven, and setup is highly documented for these types of applications...and backlash compensation is built-in. In addition, the variety of screen layouts available are specifically designed for CNC control, rather than tiny printer adaptations.

Without doing something to compensate for that backlash, you will not be getting the best the machine is capable of.

@Generic-Default, this looks like an interesting project. As somebody who has owned a CNC machine shop, I'm curious... Are your encoders on the motors, or are they linear encoders? If the former, how do you handle backlash adjustment?

Can you do g-code modifications on the machine?
Did you fix the pause (m0 &m1) so they function like real cnc machines?

I've used the duet boards on a few little jigs, but for more complicated machines, I stuck with Linux CNC... Primarily, to avoid bringing the duet up to industry standard. Kudos to you for making it happen!

@dc42 said in Duet3 as hardware for LinuxCNC?:

@tenaja said in Duet3 as hardware for LinuxCNC?:

@joergs5
In a normal cnc machine, with a normal cnc controller, if you need to make an adjustment in the middle of the program, without restarting, these are the steps:

• Hit pause
• Navigate to the offset page
• Make the adjustment
• Navigate to the program page
• Hit start (to continue the gcode where you left off)

The program continues from where it was, using the new offset.

How would that workflow be on duet?

Hit pause, send the command to change the offset, hit resume.

But then when you turn it on the next day to make another, is that number retained, for every tool?

@joergs5
In a normal cnc machine, with a normal cnc controller, if you need to make an adjustment in the middle of the program, without restarting, these are the steps:

• Hit pause
• Navigate to the offset page
• Make the adjustment
• Navigate to the program page
• Hit start (to continue the gcode where you left off)

The program continues from where it was, using the new offset.

How would that workflow be on duet?

I, too, vote to get rid of the specialty kinematics for duet 2. I have around 6, and none need more than simple xyz or corexy.

@joergs5
I've purchased numerous used industrial items on ebay. Often you can get the expensive item at a cheap price... But sure, sometimes they operate at cheap performance.

But at that savings, you can get two or three and have a backup... And still be under half price. As long as the eBay item isn't removed due to wear, and it's the same part number.

@hebigt
The printers vary so greatly that any generic comparisons can't be better than fifty percent accurate.

Check out all3dp.com for some decent msla printed parts photos. They have comparisons that are generally driven by affiliate links, but they seem to at least actually test most of the printers they "review".

@arnold_r_clark said in Duet3 as hardware for LinuxCNC?:

... the base/core offsets would be contained within the config.g

And this is the reason "offsets do not exist" from a CNC users perspective. You cannot very well rerun your config file in the middle of making a part, to make an adjustment, and then resume the part.

Now, if you could run an immediate command to adjust the offset, that would be an inconvenient workaround, but if it wouldn't mess with your gcode file position, it could work.

And my experience with cnc and 3d printers is that the former is far more accurate and repeatable. However, the precision required is also often far more demanding... But tools regularly need replacing, and the tools vary. Every time a tool is replaced, the offsets typically require adjustment... But you can't know the adjustment amount until you've cut chips. And you don't want to discard that cutting progress just because an offset needed adjustment. It's often not like filament, where it's so cheap it doesn't matter.

@rjenkinsgb
Steppers can do just fine in a milling machine. If you size them properly and know their capabilities, and stick to those capabilities you will have no issues.

You have to plan ahead not to overload them, especially if you are pushing the limits of weak steppers. Sure, you also have to do that in servo cnc gcode, too, and at least those machines will stop in an error. OTOH, with LinuxCNC, you could add encoders, and have the same feedback and error faults. (This is a "why LinuxCNC" thread, afterall.

I have found the gwizard feeds & speeds tool invaluable in ensuring you don't take more of a cut than a machine is capable of.

@arnold_r_clark said in Duet3 as hardware for LinuxCNC?:

@tenaja said in Duet3 as hardware for LinuxCNC?:

@dc42 LinuxCNC lets you set up a chart of offsets. This lets you set up a list of workspace offsets (i.e. for your vise corner--or several vises, if you have multiple setups at once) and also a list of tool offsets (to set tool diameter and length, in a mill) for numerous tools. It also lets you edit any offset in the middle of a cut so you can adjust for tool wear, etc, and have immediate corrections.

How do we do those things with RRF?

Having a cursory glance at the duet g-code dictionary it that shows that

G10: Set workplace coordinate offset or tool offset

Is what you want, and I would surmise that with macro's you could create a "chart" of differing offsets contained within those different macro's and call that macro to set the differing offset as required.

Yes, I saw that, too...so how would you set up a chart of those so they were not littered around your code, unfindable and uneditable on a whim?
Having the feature in a 3d printer config file where you are controlling the extruded quantity and having it on a mill where you swap out tools many times in a setup and have the need to compensate for tool wear regularly (and instantly) are two different things.
From a CNC operators viewpoint, a one-time code buried in the gcode file does not encompass tool offset that a real cnc machine control does.

@dc42 LinuxCNC lets you set up a chart of offsets. This lets you set up a list of workspace offsets (i.e. for your vise corner--or several vises, if you have multiple setups at once) and also a list of tool offsets (to set tool diameter and length, in a mill) for numerous tools. It also lets you edit any offset in the middle of a cut so you can adjust for tool wear, etc, and have immediate corrections.

How do we do those things with RRF?