Best posts made by token47

When you adjust the speed (or even the flow) you have no idea where to click to get a specific percentage. It will show you after you clicked, but sometimes you have to click a bunch of times until getting where you want. It would be nice to be able to see the value before clicking or to (also) have discrete buttons for values.
Thank you!

As I understand, the set of lcd connectors on the Duet2 Wifi/Ethernet were thought for connecting a 2004 LCD, which will never get support so they are of no use (except for using the pins for I/O and maybe for motors 9 and 10).

On the Duet Maestro, there are also RAMPS-like connectors but they are designed to plug a ReprapDiscount-like graphics LCD with rottary encoder and buzzer. And the last firmware have gone forward with supporting it, as is described here:

https://duet3d.dozuki.com/Wiki/Duet_2_Maestro_12864_display_menu_system

Now, I have a DuetWifi and I would like to fit a 12864+encoder on it. Now that the worst part is done (firmware support), I guess I can manage to make a daughter board that adapts the display to the right pins on the duet.

Questions:

• will the firmware just work, once the hardware is fitted, or will it know that it's not a maestro and disable support for it?
• can anyone (@dc42?) give some advice about it?

I'm comfortable with the electronics, just new to the duet itself.

Thank you!

Coming from marlin, I did not like some of the duet characteristics at first. I do not mind using GCODE to do all the configs, it seems daunting at first but you quickly get used to it. But the fact that the config is scattered all over the place bothered me. Also, the fact that I could not use the same values in many places and change them easily.

So I made a templating system for it, maybe you could give a try:

https://github.com/token47/duetcfgen

Hope it helps to easy part of the config work for you.

Hello!

I wonder why G0 and G1 are not affected differently by the feedrate. AFAIK G0 and G1 both exists exactly to tell the firmware the type of move, so it knows when a move is just a travel and when it is for real (effectively using the tool).

That way, I would expect the feedrate to affect only the move, not the rapid move. Makes sense? If I'm printing at 70mm/s and the travel is 150mm/s (because that is the faster the printer can move without troubles), and I decide to up the print speed to 100mm/s using the feedrate (142% in this case), I would expect the travel to STAY THE SAME, not being increased to 213mm/s along with the print speed.

But, Marlin did not do that and the RRF also does not do that. From the Duet G-Codes documentation:

RepRapFirmware treats G0 and G1 as the same command, since it's just as efficient as not doing so. [3]

Efficient, maybe.... but does not seem right, and yet most firmwares do. Why is that, when it seems so easy to make this distinction?

Thank you very much for the insights. I will try to put together the hardware part and maybe come back for a little more help

Is it possible to lock the top bar when scrolling? Like scroll the rest of the page but keep it on top always. Sometimes you need to scroll back to reach the EMERGENCY STOP button and it takes time if you are in an emergency...
Thank you!

Hello

I just made a config generator to make my life easier and though someone else might like it too, so I'm posting here.

https://github.com/token47/duetcfgen

Comments are apreciated. Thanks.

There is already stop.g that will be run at the end of the print if the sliced gcode sends an M0. I prefer to just put "M0" at the end script so I will keep the gcode at only one place, since stop.g will also be called in other circunstancies.

You can use start.g and stop.g to turn on/off specific pins on the board (configuring the pin as a GPIO using M950 and turning it on/off using M42) and wire a led or even an SSR to that pin to control something external. You can use any of the unused pins like endstops or unused pins in the expansion header.

Well, it indeed does that. I went to the console and run "M119" and "M122", and when I typed "M" again at that box it showed:

It seems that the "Default G-Codes" on the Configs "List Items" will always appear first and then the remembered ones from the console.

I miss the possibility to open the history drop down list by clicking instead of by typing.

Very very nice approach. I helped writing the marlin test generator, and I think it is useful here also, but that test generates a bunch of side-by-side lines, and the visual results are not as pleasing as this one.

Just for reference, the marlin test is this one:

http://marlinfw.org/tools/lin_advance/k-factor.html

I have this problem also. Something is not right.

The documentation at

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

says that: "The A and S parameters control multiple probing. Probing is repeated until two consecutive probe attempts produce results that differ by no more than the S parameter; then the average of those two results is used. However, if the number of attempts specified by the A parameter is reached without getting two consecutive results within tolerance of each other, no further probe attempts are made and the average result of all the attempts is used."

But, what happens actually is that an error is raised and the G29 stops completely. This happens even when G29 comes inside a gcode from a slicer. So it will probe a few points and abort, then start printing without completing the mesh.. This is wrong and is not predictable behavior. I would expect at least the whole print to abort, if not doing what the documentation says (which would be way better).

I just forced an error turning the S parameter of M558 to S0.00 as @fcwilt suggested. It spits

12:47:58 AMError: Z probe readings not consistent

on the logs and abort. It should do as the doc says and continue. Shouldn't it?

I just noticed this when I saw a G29 failing and the print starting anyway.

Thank you!

@deckingman they are compiled to raw gcode doing variable substitutions and sent by ftp to the duet, automatically. For the case in question, just imagine the substituted command. They are below for easier reading, this is what is actually on the config.g file:

M307 H0 B0 A102.1 C36.8 D0.4 S0.75 V12.3
M307 H1 B0 A674.5 C185.7 D4.8 S1.00 V12.3

For the record, the config generator is at https://github.com/token47/duetcfgen

thanks

Yes! D8.0 was perfect for my bed. I was afraid of going too high compared to the original 0.4 value and wouldn't go past 1.0. Thank you for the information that 5 to 10 were more usual values!