Marlin: nozzle.h

[ruggb]

I am not using the nozzle clean feature so I deleted the nozzle.cpp & nozzle.h files - BUT for some reason the nozzle.h file is required. It does not appear like there is anything in that file that is used if there is no enable for nozzle cleaning. What am I missing?

[oysteinkrog]

This is not really a supported thing to do... and I don't really understand why you want to do it at all?

[ruggb]

That isn't really an answer to the question is it? and it really does not matter if you don't understand why I want to do it. Someone was once attempting to modularize this bear and I think he quit because no one is interested in making it easy to troubleshoot, fix, and making it user friendly. I can't understand why you would not make it easier on everyone, but I guess it is a developer thing...........

[psavva]

Marlin has compiler directives which tell it what to include based on your config file.

The binary will exclude anything not needed, based on includes...

You cannot delete any cpp or header file as its referenced in the code, but during compilation, the compiler will exclude bases on those directives...

This is not a developer thing but how most programming languages work.

[oysteinkrog]

@ruggb: If you want to work on modularization that's great :)
I did not answer the question because I don't want to spend time on something when I don't even understand what the goal is?

[ruggb]

@psavva That is true if you say so, as I don't program as a rule. But deleting unused files has no effect on the compiler and it cleans up my build folder. - like I only have 2 language files and 2 pins files.
@oysteinkrog Thx for the answer....the goal as I stated in issue #5913 is to make the config files and config process less daunting for the user. I can't imagine that it won't make it less troublesome for you also. I am not asking "you" to do it. I am just trying to get "you" to buy into it so that I can finish it and have someone validate and implement it. Obviously, I only have one printer, and it works for me. I am not changing any code, only rearranging things so that it becomes easier to work with. So it should work for anybody. Some of the things I have done in terms of separating functions has been done, but more can be and it should be done that way from the get-go instead of placing things in the config files. I separated out the mesh bed level code into a separate file and just noticed that someone did that recently. If the config files had ALL the user config #defines in them and they were all grouped together and all COMMENTS were "//......./" format then //#define wouldn't get lost in the shuffle. In fact, you could have one config file as it wouldn't be as large as just the config..h is now. IF you used other features, you may need to modify those files, but the only thing you would do in the config file would be to enable the include. Just making a file for LCD&SD card makes the config....h much less confusing. Not everyone has an LCD, if you do, you include it and select the unit you have from that file. The same for bed leveling, filament sensing, etc. I am seeing more defines being moved to the config files which is good, but not putting them there in the first place creates issues for ppl trying to help validate your work. I ignore a lot of builds simply because it is too time consuming to configure it.
Does that help you understand where I am with this?

[Bob-the-Kuhn]

@ruggb - we're used to people wanting help on implementing a solution. A lot of the time there are better solutions to the problem/goal. On top of that the implementations can vary depending on what the goal is.

---

@psavva is on the mark. If a feature isn't enabled then the various defines & includes will result in the feature not being included during compilation.

In general there's usually multiple locations within Marlin where a particular file is referenced. We'd have to track them all down before we can delete a file without compile time errors.

---

And the answer to your question is ...

Delete or comment out #include "nozzle.h" in the file Marlin_main.cpp

[ruggb]

@Bob-the-Kuhn thx I don't think you are exactly following me, but I am used to that.

1. I am not suggesting that ppl delete files. I do it because it is easy to do and it cleans up my folder. Obviously, since it works for me, I do my homework to verify it compiles.
2. If a function is not used, would it not be programmatically correct to place the include under an IFDEF statement. That appears to be how most everything else is handled. I brought it up because it appears to me to be an oversight. So it would be more appropriate to tell me why it isn't an oversight or fix it than to tell me I should not be deleting files. Obviously, if the answer is to comment out the include, then if one wants a clean and stable product, one might consider using and IFDEF statement here.
   just saying........

[Bob-the-Kuhn]

@ruggb - you are an ornery cuss. I like working with people that don't pussy foot around.

In that same vein ...

As you pointed out, I'm definitely not perfect.

I think you assumed that I'd seen your third post before I posted mine. I did not. I think what happened is I was composing my post when you hit the comment button. The update would have appeared in the thread/window above where I was working. Sometimes I catch those. Sometimes I don't.

If you're wondering why people are not concisely/immediately addressing your questions/concerns then go back to your original post and look at it as if it came from a stranger. All it says is you deleted two files and were not happy with the result. Armed only with that info then the question is just too vague. Lots of ways it could be interpreted.

Your reply to @oysteinkrog was inappropriate. He made a reasonable request and got flamed for it. You owe him an apology.

It wasn't until your third post that we got a good explanation of the background and what you were really after. Taking three posts to get to the real question/concern isn't unusual. Flaming people in the process is very unusual.

I won't respond if you reply with a flame.

[emartinez167]

On the same topic, we used to have such a type of guy like @ruggb some time ago around here, with a very aggressive attitude, plainly rude and trying to impose his way on everybody else... Do you wonder why we are still here and he is not???? Be polite and treat people with respect, or you will get the boot too.

@thinkyhead, please take note.

Regards,

Ernesto.

On 14 Mar 2017, at 05:14, Bob-the-Kuhn [e-mail] wrote:

@ruggb - you are an ornery cuss. I like working with people that don't pussy foot around.

In that same vein ...

As you pointed out, I'm definitely not perfect.

I think you assumed that I'd seen your third post before I posted mine. I did not. I think what happened is I was composing my post when you hit the comment button. The update would have appeared in the thread/window above where I was working. Sometimes I catch those. Sometimes I don't.

If you're wondering why people are not concisely/immediately addressing your questions/concerns then go back to your original post and look at it as if it came from a stranger. All it says is you deleted two files and were not happy with the result. Armed only with that info then the question is just too vague. Lots of ways it could be interpreted.

Your reply to @oysteinkrog was inappropriate. He made a reasonable request and got flamed for it. You owe him an apology.

It wasn't until your third post that we got a good explanation of the background and what you were really after. Taking three posts to get to the real question/concern isn't unusual. Flaming people in the process is very unusual.

I won't respond if you reply with a flame.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Bob-the-Kuhn]

He does have a valid complaint about the readability of the config files. I've put that on my things-to-do list.

[emartinez167]

I don't argue about that, but it has to be asked nicely. We are all volunteers here.

Regards,

Ernesto.

On 14 Mar 2017, at 06:04, Bob-the-Kuhn [e-mail] wrote:

He does have a valid complaint about the readability of the config files. I've put that on my things-to-do list.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[Bob-the-Kuhn]

@ruggb - since you're interested in making Marlin easier to use I suggest you start by making the changes you proposed to the configuration.h and configuration_adv.h files.

To get your modified files into Marlin you'll need to go through the pull request process. Here's a link to instructions on how to do that. Ignore the certificate problem and continue on to the site.

If you'd rather not do the pull request then I can do it. Just ZIP up the files and drop it onto your reply.

[ruggb]

@Bob-the-Kuhn Thx - I did that for a previous build and asked for someone to take a look at it and got no takers. Since it isn't a "fix" for a code problem - though now I have one and it fits my mods but maybe someone will do it cause it fixes an issue - the next couple of builds changed things so it isn't entirely valid. I also didn't finish it because I was waiting to find out if there was any interest.

Maybe you can suggest how to slide these changes into the builds piecemeal so one new build won't invalidate what I have changed to where I must do it again. This is a moving target right now. And waiting til it is ready to release probably won't work either.

If y'all don't agree to the format, it will just be a lost cause.

A primary goal is to make commented out #defines stand out. They do not when they are surrounded with comment text using // instead of /.../.

Another goal is to place optional functions in there own file and use includes in the config files. If there are things in those files that a user need to adjust, they do it in those files after they include it.

The last goal is to get all the variables for a particular item in the same area instead of spread out in a huge file or even multiple files. Sometimes optional functions require changes to a variable that might be in a config file - I think I found one so far. That may take a little brainstorming to figure out.

But if the developers are not on board, it is not going to be sustainable. It is easy to put a user variable in a code file, never to be seen by the user, and there are a few that I moved. I am not looking to disturb the person that put it where it was - so there needs to be agreement on the format.

If there is an issue with the compiler where an IFNDEF statement doesn't work as anticipated, as in the BOOTSCREEN_TIMEOUT, then that is a mystery that needs understanding and maybe fixing.

Here is one example: The LCD & SD section of the configuration.h file.
It is a lot of stuff that some ppl do not use. If you use it, there is ONE #define you will uncomment for LCD (that is all I need) and a couple of items for SD to modify.
I broke that out, put an include in the config file and it works very nice.

another example is the two (or three) new special stepper sections. Those come out very easy.

Another is the bed leveling stuff: I think the auto version is already pulled out - nice.

Getting all the extruder, temp, stepper, etc. variable in the same area of a config file is a little harder, but I have mostly done that and it works fine - for me. Since there is no code changes it "should" work for anyone - except if that BOOTSCREEN_TIMEOUT issue somehow affects placement of other variables, but that seems to only be if the same variable is defined in more than one place with a different value.

I will attempt to learn how to do a pull request, but I need some buyin b4 I try it. I don't want to spin my wheels. I haven't got much rubber left.

a volunteer, Bill

[Bob-the-Kuhn]

Yes, getting the changes into Marlin is an "interesting" process. I don't mind doing that part.

Getting buy in is hit & miss. Before doing a lot of work I suggest you do some before & after samples of what you want to do and open an issue to get feedback.

I don't envy anyone working on a document and trying to make it easy to use for both a novice and an expert. That's a daunting task which is sure to make some people unhappy no matter what you do.

My suggestion is not try keeping up with all the changes to the two config files. I suggest:

• Take a snapshot of the files
• Make copies to work on
• Do your work
• When ready to submit, compare the snapshot against the current versions and fold the new stuff into your work.

To make it even nastier there are about 20 example configuration files that also need to be updated.

[oysteinkrog]

To be quite frank, your proposal of having users comment out individual files is not a very good one.
The compiler will take care of this whole job, there is no need to do it. It will only cause headache for users, in fact this very issue started as such!
Disabling functionality that is not needed is generally speaking a great idea, but Marlin does this through the use of defines.
Regarding the splitting of functions into separate files I like it, but the problem is that when you do that it makes it very hard for other forks to keep in sync, so the cost of doing it is really much higher than what you think.
I think you are very arrogant to assume that you know better than all other developers on the project.

[ruggb]

@Bob-the-Kuhn have you looked at #5913 ? Should I start another issue and post pieces there? I guess a fork would be better if I can figure it out. I just don't want to overwhelm people with a lot of "stuff". OK, I started #6024 for this.

@oysteinkrog My proposal is not a very good one, but you like it. That's a start! The process is to INCLUDE optional functionality that one needs, not to comment the files out. Unfortunately, the compiler can't take care of the human confusion having all this code/text inline causes. The defines work well for their intended purpose. How many are missed because they are buried in text that is commented out the same way? The point is to make them easy to find and manipulate. Putting defines for a stepper, for example, into multiple locations or multiple files is a user nightmare, and probably causes you to lose sleep also. PLEASE NOTE, I am talking about items that operate together and not items that operate if you are using an optional stepper. Putting those defines and text instructions in an operational config file creates a bloated file, difficult to navigate.

As far as keeping forks in sync - I have no clue how that works. That is one thing I have never done. But my question would be, How do we make it work? Because, ultimately, Marlin is for users, not developers.

When you start thinking like that you will become a great developer.

And you are correct, I am very arrogant, especially when someone tells me/implies after 60 years of working with all kinds of people - hardware & software engineers, technical writers, sales people, application & manufacturing engineers all over the world, AND functioning in ALL those capacities, that I don't know anything. Would you like me to post my resume? You might be surprised.

[ruggb]

@Bob-the-Kuhn On a previous note--"All it says is you deleted two files and were not happy with the result."
"I deleted the nozzle.cpp & nozzle.h files - BUT for some reason the nozzle.h file is required. It does not appear like there is anything in that file that is used if there is no enable for nozzle cleaning. What am I missing?"
As it turns out, I wasn't missing anything. The #include in Marlin_main would probably be better wrapped with an IFNDEF statement to make the code clean. right?

[Bob-the-Kuhn]

There are lots of instances of the wrapping you mentioned being used. Sometimes that saves a considerable amount of FLASH and RAM space.

[ruggb]

Should I take that to mean it may get cleaned up?
seems pretty simple.

[Bob-the-Kuhn]

How about using it to make your first pull request?

It's not urgent so there's no time pressure.

[ruggb]

You are really trying to stress my brain - right?
OK, simple enough for a shot.

[ruggb]

Yeah, "simple enough" - somehow I feel like I am answering this again, I got too many issues going.
I think I did it, but I don't think I created a pull request yet, but I may have.
In reviewing it, the value of the change seems to be overwhelmed by lots of inconsistencies in the files that should also be fixed. I may have also created my own fork that I can upload my changes to but I am not sure and afraid I might inadvertently cause a mod to something I don't wish to. I also haven't figure out how to get my files to my fork. but I think I do have a copy of RC8bf on my computer. I am not even sure of that.

[Bob-the-Kuhn]

There's no pull request yet.

Don't be afraid of inadvertently changing the main stream Marlin code. That can only be done via the pull request (at least for mere mortals).

Don't be afraid of screwing up code in your fork. There's ways to fix it.

You're already keeping backup copies so even if you do screw up your GitHub copy you can easily recover.

Don't be afraid of playing with GitHub. Worst that can happen is you get confused. Anything you create by mistake can be deleted.

I use the GitHub desktop application. Much friendlier than the web based tools. Eventually you'll have to drop down to a command window/shell and issue low level commands but that's a long way off.

[ghost]

I deleted my fork completely several times before I was sure what was happening was on purpose. Lol

[ghost]

@ruggb, I would start out slow. Pull request the comment structure change first.

Get that accepted and merged.

Then submit you next phase. And so on...

[ruggb]

@Tannoo finding issues is easy, fixing them is labor intensive, fixing them in Git is totally unfamiliar to me.
BUT, YEAH, I have totally rearranged the CONFIGURATION.H, eliminated the CONFIGURATION_ADV.H file, and created 12 optional includable files in config and it compiled in virgin form.
It resulted in the elimination of a few redundant if statements and (on a first take) all the items for a thing like extruder, stepper, etc are in those sections. Some of the include files may be able to be combined, like there is 2or 3 for special steppers, and two for bed leveling.
Now I just have to find someone to by into this and tell me how much I may have messed up.
Next step is to configure it for me and see if it runs my printer. I did it with a previous commit, but not to this extent and had no issues.

After reviewing the change I made, I realized there are a number of other things somewhat associated that needs to be done to call it clean. It does, however, work. It is just that these other items overshadow what I hoped to make look clean. As soon as you look at these other things you say - big deal, how about this. So I will do the whole thing as part of my whole thing.

2 questions if you know:

1. I am modding the files on my computer, how do I get them onto my fork on git. This time I don't need to keep any history as the build I forked from is in RC8BugFix. Do I just copy them to my Git folder on my system and they upload???????????????????????????????? or can I copy them into the online folder.

1. how do I do it so it keeps its history when I need to???

[Bob-the-Kuhn]

@ruggb - here is my first pass at updating a PR.
updating the PR.zip

My goal is to add it to the new Wiki so feedback is encouraged.

---

Have you been able to create a PR yet? I don't see it in this repository.

[ruggb]

@Bob-the-Kuhn read above. the change is under kill at this point. I want to try to get the complete work on line. There is just too many things I see that could be better - given the fact that I have done little independent C programming, I must convince someone to look at my work of art and find holes in it. All I can do is to insure it compiles as a virgin work and that I can configure it and run it on my machine - I have done that with my previous effort. There are no code changes per se, but I have rearranged a lot more this time and eliminated a couple if statements adding one #else. I am now down to 9 include files and eliminated the config_adv file.
As I was going thru it this time, I am liking it more and more. I think the reorg makes it flow a lot better. I have one section labeled "Above Your Pay Grade Settings" in the config file because it seems to me like code a user should not touch, but it was in the adv file. I may create a few more in some sections. I hope someone with an open mind will seriously look at it. There are a few things in there that are either not or poorly documented so someone needs to explain to me. Because of that they may be in the wrong place.

Now I need to load it to my fork.

[Bob-the-Kuhn]

Yes, do the PR when you're comfortable and want feedback. A PR is a good way to get people to look at it.

---

Sounds like you've forked RCBugFix to your own private repository. Good.

Git will keep a history of your changes. The steps to do that are:

• open Desktop - it'll default to the last repository & branch you used
• click on Changes and then open this repository
• this'll open up a Windows Explorer window with the Git files in a subdirectory
• copy your changed code into this subdirectory
• fill out the summary & description
• click on Commit
• click on Sync

Git has now captured your code changes along with the summary & description. They're available via Desktop or on the web. You can select any commit and look at it's contents and even revert it if you want.

The doc I attached earlier and the Wiki page I pointed to earlier have pretty pictures and much more detailed descriptions/steps.