gcode everywhere... a user friendly approach to config?

biscuitlad

I'm at the end of my tether.

I posted this after failing to get the IR z probe to work properly on my machine, but this is just the last step in what has been many previous failures. I don't know if some of you have similar experiences, or if some of you have hours every night to tweak your machines, or if some of you get lucky and your machines work perfectly first time. I only know my experience, which has been a configuration crapfest, TBH.

I feel the Duet system of gcode configs is like going back to the dark ages of editing machine code. It's a nightmare of 20,000 gcode combinations that no one except the devs can disentangle for you. Each time something doesn't work, it's 'oh, did you miss S1 off the M*** command? You didn't put the M*** before the M*** did you? Did you not read the page on G** where it states you shouldn't combine it with M***?' and so on. The error messages can literally leave you days away from finding any solution: 'Homing failed'. Yes...?? I gathered that much myself!

Each time I come back to my machine that has the Duet Wifi board, I spend days trying to get it to work. I've never succeeded. It's enough to drive a man to drink.

Since I installed the board as an upgrade on the previous RAMS, the printer has not produced a single decent in print in nearly 8 months. I have spent hundreds of hours trying to get it to work. Day after day, week after week. I just move in config.g circles, never getting the problems solved, always moving onto the next problem. Sometimes back to the old problem. Sometimes one problem leads onto the next, or causes the next. But surprisingly often, the problem is caused by the complexity of having to understand so many gcode options that may or may not apply to your printer config, and the fact that many operations and printer types are not clearly described. Sometimes, in an effort to make things better, you make them worse with a foolish config change that can takes days to discover.

It cost me a lot of money trying upgrade instead of just chucking the K8400 in a skip and buying a cheap Chinese i3 clone, but I so wish I had done that and swallowed the guilt of contributing to the destruction of the planet with more plastic crap rather than waste months of my precious time fruitlessly trying to configure the Duet to produce a print.

I had thought it was the right thing to do. But now I realise I'll never get that printer to work again. It's going in the skip, along with the marvellously configurable Duet board inside it.

I've ended up out of pocket, out of time, out of patience. It's not a path I could recommend to anyone.

token47

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.

SnowCrash

I feel your pain, @biscuitlad, and hope you won't give up on your printer despite all the trails and tribulations you've experienced so far.

Like you, I've been having some mighty struggles with the g-code-based approach to config.g. It's undoubtably a steep learning curve for anyone not previously familiar with it.

As you rightly note, the Duet eco-system is very complex and offers multiple configuration possibilities, but to my mind at least, that's actually plus. The problem, of course, is finding the right configuration for the machine at hand...

I don't know if (or how much) you've tried to get help from other members in this forum, but in case you haven't, I'd certainly recommend trying that.

On the other hand, if online requests for assistance didn't produce the desired results, perhaps it might be possible to find an experienced Duet user somewhere in your vicinity who might be willing to drop by and get you going on the right track? There are lots of good people on this forum and I'm sure they'd be happy to help if they can.

One other point I'd make - and I don't know if you'll agree with me on this, but it seems relevant - is that in my view, your case provides yet another example of the need to significantly upgrade the documentation so as to bring it on par with the high level of the Duet's hardware & software. Personally, I think the documentation is lagging way behind atm.

Don't lose hope, @biscuitlad! Sometimes it's good to just take a step back and let things rest for a while before having another go

Jacotheron

The Gcode commands take a while to get used to, and is not very user friendly for most people. What helped me the most, was the Configuration Tool (https://configurator.reprapfirmware.org/ - just note its SSL certificate expired very recently [admins, can you perhaps go take a look]). By simply answering the questions, most of the setup is being generated for you.

After the basic configuration is done, I worked through the Gcode page (https://duet3d.dozuki.com/Wiki/Gcode to custom code the things I wanted). While not required to get a working printer it helps with fine tuning your settings and getting things the way you want it.

The other side of the Gcode is that it is extremely powerful: I have converted a Wanhao D5S Mini with the DuetWifi (E3D Head, Bondtech QR etc). I am waiting for a few additional heads, which will allow me to switch heads (not nozzles, since changing nozzles takes time and requires heat) very easily; very useful when I want to switch between 1.75mm and 3mm filament and even between 0.4mm nozzles and the other sizes (like 0.2mm and 0.8mm); change between PT100 and standard thermistors. Yes, I need to shut the printer down before doing a change like this, but after the change simply run a macro and the printer knows exactly everything it needs to know for the extruder/head/temperature sensor combination, and ready to print.

If you have not lost all hope yet, why not post your config and explain the issues you are having - a lot of users in this forum may be able to help.

Qdeathstar

I think, the good thing about gcode is, once you learn it, what you see is what you get. Some firmwares every time you want to change stepper current or fine tune steps per mm you gotta to recompile and upload. Yuck.

There is a list of g-codes, getting the first layer level and adheared to the bed is more difficult than gcode is....

I’m sorry, but overall, judging from your posts, you have a sloppy bios and inattention to detail. Is it the boards fault or is it the builders fault. Loose connections - builders fault...

fcwilt

Hi,

Sorry to hear you are having troubles.

Perhaps you simply have tried to make too many changes at once.

The basic settings in config.g for a printer are rather straightforward and once done you don't have to change them unless you change some physical aspect of the machine such as installing different stepper motors.

The is a configuration tool that will generate a basic config.g just by filling in some blanks.

Once you have a config.g that allows the printer to perform it's basic functions, moving in the right directions, the right amount, the right speed only then do you need to tweak.

And then it is simply a matter of adjusting each item, one at a time, and then moving on to the next one.

My config.g file is less than 30 lines. There are of course a few lines in the support .g files but these are generally once and done and they tend to be simple.

Perhaps you should give it one more shot but first send us you configuration files and then ask questions about the issues you face.

The Duet system is about as simple and straight forward as it gets.

I tried a number of different 8 bit boards, a couple of smoothies but once I found Duet I updated all four of my printers and have NO regrets whatsoever.

Frederick

Phaedrux

I'm sorry to hear you're at your wits end. I really thought we had made some progress. I hear your frustrations though. There are a lot of moving parts to the config file so to speak. Gcode configuration is powerful and flexible, but with that comes complexity. And the trouble with that is complexity you don't need is a hindrance.

I hope you do decide to give it one more go, I think you'll find quite a bit of help from the forum. Eventually all problems can be troubleshot and solved. That's what I love about DIY 3D printing. Every problem can be overcome eventually. Perhaps that's not your idea of fun, but I think it's going to be inherent in every DIY 3D printer. If reliability and ease of use is what you're after, Ultimaker would be glad to get you sorted. But even an I3 clone on ramps is going to have it's own issues. It's easy to look back at marlin and ramps and see it as simple and easy, but when I started out I remember not having a clue how to compile the firmware, and remember misconfigured end stops and crashed heads, bent lead screws, magic blue smoke, etc etc. For me coming to the Duet and Reprap firmware really was an improvement.

If you do decide you want to give it one more go from scratch please let us know. We'd be glad to help.

biscuitlad

Many thanks for the replies and well wishes. The forum is great. I couldn't have got as far as I did without it, no doubt about that at all, so many thanks to all.

My comments are not meant as a criticism of the Duet board, I'm just wondering if there is a better way to help users who may not have all the technical specs of their machine get a working system up and running.

I feel what might help a lot of users coming to the Duet eco-system is perhaps a repository of template config.g plus homing files for various printers. I totally get that everyone here is likely to have customised the heck out of their printer, but there might still be some common elements that could be of use.

For example, I'm starting to wonder if my z stepper values are correct. The IR z probe returns different z offsets each time I try to calibrate it, I don't know why. I don't know if the mesh bed compensation is correct, it's different each time I run it. The first layer is always wrong and it's hard to know where to start.

Personally, I think it would be a help to me if there were a repository that contained someone else's K8400 config files for a Duet, even if (like me) their printer was a long way from how it was originally built, there might still be something of value in there that could help me debug issues with my printer. Perhaps there could be a repository of K8400 type printers, e.g. Cartesian bowden set ups...

Yes, the RRF config tool is fine. But even that can be daunting - how do you know if your endstop is high or low type? Is your stepper going forward or backwards? What are the right acceleration rates, max speed, etc? If you have a common printer, you'll probably get dig this stuff up pretty easily online.

If you don't, you can be stuck with a mystifying black box of tricks and a thousand ways to misconfigure it!

Phaedrux

I think you have very valid points all around. The experience of a neophyte user can be rather daunting. It's difficult to tailor something as complex as RRF and the Duet to all skill levels. The power and flexibility it offers kind of targets it towards more advanced users, but it's not impossible to pick up.

A repository of configs would be helpful. The documentation tries to go through the general setup of each machine type, cartesian, corexy, delta, etc but it doesn't account for the particular quirks of each individual design. Perhaps you can be the first to contribute for the K8400? I think there was an attempt to gather some example configs at some point, but the trouble with that is they get frozen in time. The firmware is always evolving and a config for a printer 2 years ago will be a bit stale if used with a current firmware. Rapid feature development is a double edged sword.

The configurator is a starting point but not perfect. I was in the same boat as you when I started. I had no idea what motor direction or endstop type to choose, etc. But that just forced me to learn the difference and how the firmware treated each type. Commissioning a printer from scratch on RAMPS and Marlin would have similar pitfalls. At some point you need to know the mechanical and electrical specifics of your printer in order to tell the firmware how to operate. And sometimes that requires trial and error.

dc42

@biscuitlad said in gcode everywhere... a user friendly approach to config?:

The IR z probe returns different z offsets each time I try to calibrate it, I don't know why. I don't know if the mesh bed compensation is correct, it's different each time I run it.

What bed surface are you using? If by "IR sensor" you mean the mini differential one from me or Duet3d, it works well with some surfaces, not so well with others. If you post a screenshot of your height map, I should be able to tell whether compatibility between the sensor and bed surface is likely to be part of the problem.

Jacotheron

For many of the values, I looked at the known values from the Repetier Firmware or Marlin Firmware available for my printer.

Things like the axis steps/mm values, endstop configuration etc can easily be checked manually:

Endstops (2-wire micro-switches): If possible, using a multi-meter check the continuity of the 2 wires and trigger it. If the multi-meter get continuity prior to the trigger, it is Normally Closed (which is better than Normally Open). Connect the endstops between Ground and the Signal and ensure the Endstop is configured for Active HIGH (this way, if the endstop is disconnected, it is read as triggered since the Duet will use a Pull-up Resistor to keep it high; unless it is actively pulled Low by a direct connection to ground, it is triggered). If yours is Normally Open, the same 2 pins is used (Ground and Endstop), but you configure it to be Active LOW - since only when triggered, will the endstop be pulled LOW (to ground). More details at https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches

Steps/mm: For a Belt System, you need the number of teeth on the pulley, the belt pitch (so far I have came across GT2 [2mm] and MXL [0.08" / 2.03mm]; but others also exist and are used). You also need to know the number of full-steps/rotation from your stepper motor (usually found by a Google search for the stepper model number; also possible to use the number of microsteps/mm at a specific microstepping level [usually 16x]). The configuration tool can calculate what you need from this information.

Motor Currents: If you get the motor information, this will be in the datasheet (though it is a good idea to calculate an 80-90% of the rated and use that).

Motor Going Backwards? This is one of the things one should test and then change if needed: 1 got my head in the center of the build volume (around 50% in all axis), then command a single move at a time for a short distance (use the S2 option on these moves, for example "G1 X10 S2" to ensure it will move even though it is not homed). If it moves in the correct direction, it is correctly configured; if it moves in the wrong direction, invert its direction (Drive 0 is X; then Y and Z; finally P3 is E0, and if used, P4 is E1 - on standard Cartesian) by changing the Sn value between 0 and 1 for the M569 (for example "M569 P1 S0" makes the Y motor move inverted). It is also possible to invert the motor by changing the order of the 4 wires leading to it.

Acceleration rates: If you can find them in previous firmware, that is a good starting point; if not, start conservative and build up from there. The heavier the head (like a Direct Extruder), the lower your acceleration needs to be, otherwise it may skip steps on starting and stopping.

Maximum speed, once again a heavier head will need lower speeds, otherwise ringing may be caused. If found in firmware use that as a basis. Your head type also have a limit (MK10 heads, for example can only do about 60mm/s sustained; so limiting the printer a bit higher, like 100mm/s is good). Your voltage plays a role (due to Back EMF) - more information on https://duet3d.dozuki.com/Wiki/Choosing_and_connecting_stepper_motors (How to work out the power supply voltage you need; they have a spreadsheet to calculate an absolute maximum).

Look for "3d printer k8400 firmware" I found a few places that posted firmware, and from there (https://github.com/birkett/Vertex-K8400-Firmware/blob/velleman-official/Marlin/Configuration.h)

Maximum Speed (called XY_TRAVEL_SPEED): 6000 mm/min (or 100mm/s)
Acceleration (called DEFAULT_ACCELERATION): 6000 mm/s^2
Jerks (XY, Z): 10, 0.5
Motor Directions: X and Z is inverted (note that how you connect them to the connectors will also affect this).
Endstops: X and Y is at MAX, and Z is at MIN (unless you changed its locations). I could not find if endstops are Normally Open or Normally Closed.
Steps/mm (possibly 32x due to DRV8825; X, Y, Z, E0): 134.74, 134.74, 4266.66, 200

biscuitlad

@dc42 I'm away on holiday next week, but when I get back I will happily do this. It's the original black buildtak supplied by Velleman.

Phaedrux

@biscuitlad From the buildtak I've seen it seems to have a bit of a reflective shine to it. Perhaps it is scattering the IR light? To test, could you place a sheet of paper on top of the buildtak and try homing and probing again?

Enjoy your holiday!

Alexander Mundy

Sorry you are frustrated, but for me (coming from Smoothie and previously from Marlin) the gcode method was a refreshing breath of fresh air. The forum responses are also a breath of fresh air from what I percieve as arrogance on the Smoothie side. Anyway, I'm sure the fine folks here can help you get your machine going.

T3P3Tony

@jacotheron said in gcode everywhere... a user friendly approach to config?:

What helped me the most, was the Configuration Tool (https://configurator.reprapfirmware.org/ - just note its SSL certificate expired very recently [admins, can you perhaps go take a look]).

Thanks for reporting this, It is renewed now. Odd that Let's Encrypt did not auto renew as it was set to.

Jacotheron

@T3P3Tony Thought it may just have been a simple cause. Thanks.

wilriker

@jacotheron said in gcode everywhere... a user friendly approach to config?:

Endstops: X and Y is at MAX, and Z is at MIN (unless you changed its locations). I could not find if endstops are Normally Open or Normally Closed.

According to the config you linked they are Normally Open:

// The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
const bool X_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Y_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Z_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool X_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Y_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Z_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.

Having these set to false means Normally Closed and true stands for Normally Open. This get's a bit clearer in the original Marlin comment of this part

// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).

How to proceed from here

My personal recommendation on this topic would be to start from scratch regarding your config.g and other files. Create a fresh set using the Configuration Tool using the values you can find in the Marlin config as already posted by @Jacotheron above. If anything is missing or you cannot find a value yourself, just ask here we have kind of 24/7 support here.

It seems to me that somewhere on your - sadly - bumpy way you took a wrong turn and never found back but just found more places to do wrong turns. When something is as wrong as you described your setup it is time to start fresh IMHO.

But as others already stated, we are happy to help here.