Firmware wishlist and priorities for Duet WiFi and Duet Ethernet

gavatron3000

My wishlist:
Move axis till endstop or input reached. If not made by "X"mm then pause
Also be able to invert the endstop or input depending on desired condition

fotomas

end.g

An optional system file, run at end of each print, instead of adding end code in slicer. I would use it to lift the print head and move the table to a position for removing the printed part.

I think those moves are more of a system setting than a print move. There fore it would be nice to have it set in the printer instead of a slicer setting.

SJI

@fotomas said in Firmware wishlist and priorities for Duet WiFi and Duet Ethernet:

end.g

An optional system file, run at end of each print, instead of adding end code in slicer. I would use it to lift the print head and move the table to a position for removing the printed part.

I think those moves are more of a system setting than a print move. There fore it would be nice to have it set in the printer instead of a slicer setting.

In the end tab of the slicer i would add M98 Pend.g

Phaedrux

@fotomas This already exists in the form of M0 and stop.g

; stop.g
; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)
; Also called by slicer end gcode by M0

https://duet3d.dozuki.com/Wiki/Macros#Section_Pause_stop_and_power_fail

https://duet3d.dozuki.com/Wiki/GCode#Section_M0_Stop_or_Unconditional_stop

In my stop.g file I do all the end of print things like moving the head away from the print, maxing the part fan, turning off the heaters, etc. Then i the slicer end gcode I just have M0. That way whichever slicer I'm using stog.g gets used and I only have to make changes in one place. I do the same with start.g which gets run before a print starts.

David Green

No. 2 5 14. I would like to keep the G32 auto bed level as a fast check on anything moving when removing a stuck print. I have a CoreXY and it can slip the 2 motors out of position.

mwinterm

7, 10, 12, 14, 18,

would be my my wish list. However didn't put 4, 8, 19, 20 on my list as a think that is already working:

4 -> assigning 2 motors to one axis, separating them for homing and re-assembling them again with M584
8 -> M906 ..... I30 for current reduction
19 -> M80/M81 to turn ATX off
20 -> someting like M106 P2 T45:65 H100:101:102 .....

Regarding better CNC support (12) my specific priorities would be:

Safe tool-offsets and WCS so that they are still in place after restarting (similar to bed compensation)
Modify M584 for tool measurement as I already proposed (implemented in my personal branch)
Extend G30 with an S-3 option to allow for WCS probing (implemented in my personal branch)
Allow macros to ask for input like position, tool-number, WCS-number....
More frequent update of the position in the PanelDue / Webinterface (something like 10 HZ update frequency)
Support for conditions, loops and parameters in Gcode
Support canned cycles like G73-G89 in the form that they can be defined in e.g. G73.g ... files like for homing, cancel, resuming....

deckingman

Ability to assign end stops to axes (especially useful for machines with "more than the norm" number of axes). Or more precisely the ability to assign end stops other than the default assignments.

Talking to Tony some time back when I was trying to get CoreXYUVnn (where nn could be AW) working, I'm fairly sure this is on the road map but it doesn't appear in this thread so I thought I'd mention it here so it doesn't get overlooked.

3DOeste

I don't know if it would be possible, but I would like to have Fanuc compatible gcode when in CNC mode. That would enable to use the vast majorities of CAM softwares available since all of them have a Fanuc post processor.

dc42

I thought Fanuc machines were rotary CNC machines - am I wrong?

3DOeste

@dc42 Fanuc is the standard in high quality CNC machine controllers, the are others, but Fanuc is the most used one.
They make controllers for mills and lathes, and also for all kinds of CNC machines (robots, press, EDM, wire EDM, etc...)

dc42

@3doeste, can you list the most important Fanuc GCode commands that RRF doesn't yet support?

3DOeste

@dc42 I think the major difference is how G0 and G1 commands are used, since on industrial controllers you only used G0 and G1 once, and all the following blocks asume the last parameter until a G0 or G1 command is issue again. That allows for less data transfer (wich industrial controllers are the worst in this matter, specially older ones) and to separately tune rapid feed rates and cutting feed rates on the fly.
Canned cicles are useful but you can write all the cicle from the CAM itself, so no problem there.

I attached a simple offset flat strategy, without arcs, so you can see how a Fanuc post looks like. In this case it has the block numbers, but they can be removed to decrease data transfer rates .

0_1544481928987_Fanuc-test.gcode

dc42

@3doeste said in Firmware wishlist and priorities for Duet WiFi and Duet Ethernet:

I think the major difference is how G0 and G1 commands are used, since on industrial controllers you only used G0 and G1 once, and all the following blocks asume the last parameter until a G0 or G1 command is issue again.

What you are saying is that you can just repeat the X and/or Y coordinates without repeating the G0 or G1 command. I'll add that to the firmware wishlist.

3DOeste

@dc42 That's right! After a G0 or G1, all the following coordinates use the last parameter, you can even change the feed without changing the G1 or G0 status (well, on industrial CNCs the G0 has no feed value, since it's given by the machine, and all you do is lower it by 50%, 25%, and to feed values).

gavatron3000

@gavatron3000 said in Firmware wishlist and priorities for Duet WiFi and Duet Ethernet:

My wishlist:
Move axis till endstop or input reached. If not made by "X"mm then pause
Also be able to invert the endstop or input depending on desired condition

Forgot to add this request is to help with making the MMU2 work as intended with respect to detecting loading and unloading issues. This way I run it with the duet electronics and not use the prusa Arduino.
Cheers
Gav

dc42

@3doeste said in Firmware wishlist and priorities for Duet WiFi and Duet Ethernet:

@dc42 I think the major difference is how G0 and G1 commands are used, since on industrial controllers you only used G0 and G1 once, and all the following blocks asume the last parameter until a G0 or G1 command is issue again.

That is now supported in firmware 2.02RC7.

daveidmx

With the RTOS port I assume it's now easier to add additional background tasks to the firmware. When a print starts, could the firmware also start running a simulation in the background, and when complete that simulation time could be fed back to DWC/PanelDue for an additional (and presumably more accurate) print time estimate?

patakopecek

@daveidmx good idea, but the duet could run out of resources

dc42

@patakopecek said in Firmware wishlist and priorities for Duet WiFi and Duet Ethernet:

@daveidmx good idea, but the duet could run out of resources

That's the likely problem. The Duet 2 doesn't have enough RAM to run two instances of the Move subsystem. So we'd have to run the simulation while the Duet is sitting idle. Then we would have to either abandon the simulation if you send any commands to the Duet, or save enough state to be able to resume it later.

When a simulation completes, the simulated time is stored at the end of the file. PanelDue displays that time when you select the file.

A Former User

@dc42

late to the party:

6-10