Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Brainstorming] Warn if any of the objects exceed the printing area #1254

Closed
wants to merge 13 commits into from

Conversation

Javierma
Copy link

@Javierma Javierma commented Mar 4, 2016

After fixing errors and removing non-related files, I try again the pull request. I wasn't able to add only one commit (I don't know why, maybe because previous ones where related with these files) but this time it is much more easy to know the changes that have been done. I believe I solved problems with coding styles (tabs and spaces) but if it is not the case please let me know.

Basically, what it happens is that when you add a gcode file and is analysed, in case that user has logged in and it is detected that a move exceeds the printing area, it will show a warning like the following one:

screenshot from 2016-03-04 12 57 45

Regards,

Javier

@@ -258,8 +260,9 @@ def throttle():

self._gcode = gcodeInterpreter.gcode()
self._gcode.load(self._current.absolute_path, self._current.printer_profile, throttle=throttle_callback)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove that white space :)

@foosel
Copy link
Member

foosel commented Mar 4, 2016

I added a couple of review comments, please take a look at those.

About the number of commits - yes, this is how git works. Every commit references one or more parent commits, you have a full fledged graph. Since PRs are basically just "merge my graph into your graph please" situations, your full graph gets checked against my full graph and everything you added lands in the PR. You could have fixed that before hand by interactively rebasing your branch and changing your commit history to only contain the small number of changes that are actually necessary here, but I can also do that after the fact by just squashing your commits instead of merging, which is probably the easier method now.

But first - see the review comments :)


Unasked for advice follows ;)

I would suggest you take a look into how git works so you understand why this is happening and how to avoid it from happening in the future - it's a bit difficult to grasp when just learning how to use git and confuses a lot of people, but it's actually not that tricky to understand as long as one takes a bit time to wrap the head around the concepts that are at work in git and are actually quite cool :) This is a good resource for really understanding what is going on. I can hear you say "I need to read a BOOK to understand git?" and yes, I know, that sounds intimidating, but a) it's really short and b) the thing with git is that if you only know the handful of commits that most tutorials teach you, you might know how to do something, but not why, and most importantly when to not do it, so I can only really really recommend to tackle the whole git thing by trying to understand how it works, because then all those various commands and what they do behind the scenes and why for example you see the commits in this here PR you see there makes complete sense.

Further interesting resources: this short article on the git data model and this very video about the whole topic (not exactly the one I wanted to link but seems to cover the topic just as well)

@foosel foosel added the needs some work There are some things to do before this PR can be merged label Mar 7, 2016
@Javierma
Copy link
Author

Javierma commented Mar 8, 2016

It took some time but I would say that it is finished or almost. About the different notes:

-Minimum and maximum values are now sent through the metadada to be used in the frontend.

-getWarning(): Removed in this last commit (yes, I wrongly applied Java programming).

-Print origin: In last commit it has been tested for both lowerleft and centre, working for the two cases (maybe for centre origin the message shown can be improved).

-Start and end gcode: I agree that it also should be evaluated, although it can be quite difficult indeed. I may be wrong, but as far as I know G28 command should be used to say which axis do the homing, so in case of extrusion in start gcode(e.g. for skirt) a G0 or G1 command would be used.

-Resources: Before these resources I already did online courses (CodeCademy's and Udacity's) but those are not as complete (especially to repair problems as are pretty basic), so thank you for them.

-Files.js: There where things that I probably changed when I didn't have to, so that's why they appeared as changed. In the last commit you will find some of the things that I had to repair. Now that problems are solved.

-GUI: I also changed the way that the message appears, trying to be clear and avoid absurd repetitions. The following image is an example of the change:

screenshot from 2016-03-08 18 38 08

@foosel foosel added needs review This PR needs a review and removed needs some work There are some things to do before this PR can be merged labels Mar 16, 2016
@@ -262,7 +260,7 @@ def throttle():
self._gcode.load(self._current.absolute_path, self._current.printer_profile, throttle=throttle_callback)

result = dict()
result["warning"]=self._gcode.getWarning()
result["printingArea"]={"minX" : self._gcode.minX, "minY" : self._gcode.minY, "minZ" : self._gcode.minZ, "maxX" : self._gcode.maxX, "maxY" : self._gcode.maxY, "maxZ" : self._gcode.maxZ}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing white space in assignment, and shouldn't all be on one line - line breaks and white space in general are a GOOD thing to have in code ;)

@foosel
Copy link
Member

foosel commented Apr 11, 2016

Sorry that it took me so long to get back to this, I'm having my hands full currently.

I added a couple of comments. Also take a look at those on the "outdated diff" (I realized too late that there were two commits, sorry for that), since they are of general importance.

I realized that this is something you did as part of your coursework for university, and if you do not have the time to look into this anymore, please just say so, I'll try to find the time to pound the PR into shape myself then. Sorry again for the long delays at the moment.

@foosel foosel added the needs some work There are some things to do before this PR can be merged label Apr 11, 2016
@Javierma
Copy link
Author

No need to apologize, I understand that you can be busy. Thanks for your patience indeed.

Indeed this feature is part of my final degree project, so I would like to finish it if possible. During the time I was working in reading the book you recommended me to understand git better as well as working in other features while trying to meet the recommendations (sorry if it took too much time to apply fixes in this one).

@foosel foosel added needs review This PR needs a review and removed needs some work There are some things to do before this PR can be merged labels May 9, 2016
@foosel
Copy link
Member

foosel commented May 9, 2016

Again sorry for the delay, some tricky problems are keeping my hands awfully full.

I just took another look at the code, and there are still some comments unaddressed:

Could you take another look at those? If not, please tell me, I'll then try to find the time (... somewhere ...) to tackle that myself.

@foosel foosel added needs some work There are some things to do before this PR can be merged and removed needs review This PR needs a review labels May 9, 2016
@gddeen
Copy link

gddeen commented May 10, 2016

I have dual extruders. The X/Y offsets of the 2nd extruder is given to the Marlin firmware. The settings
for Cura are then to have each extruder at 0,0.

This makes things kinda complicated. I can't print from X=0 to 27 with the 2nd nozzle. I can't get to MaxX + 27 with the 1st nozzle...

Just in case this handles the dual extruders...

@Javierma
Copy link
Author

@foosel If I'm not wrong, in the last commit (b0cfa28) the overly complicated if structure was changed to your suggestion as it was a much better approach. The other issue wasn't a merge error. It was indeed a line or part of it that I accidentally removed so I had to put it again to solve the problem.

@gddeen Good question. The printers that I use have a single extruder and by mistake didn't thought about having two. Could you send me a gcode file to martinezarrietajavier@gmail.com to check if it would work or not?

@foosel
Copy link
Member

foosel commented May 12, 2016

@Javierma sorry, I got confused by Github's presentation of the diff there, you are right.

@foosel foosel added needs review This PR needs a review and removed needs some work There are some things to do before this PR can be merged labels May 12, 2016
@foosel
Copy link
Member

foosel commented May 12, 2016

About the dual extrusion, if the offset is handled by the firmware there's nothing you can do to properly do an out-of-bounds check from within OctoPrint since there's no way for OctoPrint to know if an extruder is stepping off the bed without knowing its offset from the head origin.

Dual extruders are however something that the min/max calculation in the gcode interpreter in this PR currently doesn't take care of and that needs to be fixed, so big thanks @gddeen for the heads-up, I managed to completely lose sight of that one too.

It can be easily achieved however by moving the min/max calculation for the x and y coordinates a bit further below after pos gets fully updated based on the current G0/G1 command and using pos instead of the coordinate values from the command.

That should actually be done in any case, since it also takes care of absolute vs. relative positioning, absolute vs. relative extrusion and metric vs. imperial coordinates.

So, in a nutshell: Move the min/max block to the end of the G0/G1 if instead of the beginning and modify it to use the pos data, like this:

# If move includes extrusion, calculate new min/max coordinates of model
if e > 0.0:
    self.minX = pos[0] if self.minX is None or pos[0] < self.minX else self.minX
    self.maxX = pos[0] if self.maxX is None or pos[0] > self.maxX else self.maxX
    self.minY = pos[1] if self.minY is None or pos[1] < self.minY else self.minY
    self.maxY = pos[1] if self.maxY is None or pos[1] > self.maxY else self.maxY
    self.minZ = pos[2] if self.minZ is None or pos[2] < self.minZ else self.minZ
    self.maxZ = pos[2] if self.maxZ is None or pos[2] > self.maxZ else self.maxZ

Note that e at that point will have been converted to relative coordinates or set to 0.0 if it was None so a simple check if it's greater than 0 is sufficient to find an actual extruding (and not retracting) move*. Using that post-processed e value will also have the extra benefit that it takes multiple extruders and their previous E value into account. The previousE variable hence isn't necessary anymore and can be removed.

  • That might have to be adjusted for retract-and-lift slicer settings, but let's ignore that for now.

@foosel foosel added needs some work There are some things to do before this PR can be merged and removed needs review This PR needs a review labels May 12, 2016
@Javierma
Copy link
Author

Analyzing the gcode sent by @gddeen (thanks for your help by the way), it will partially work for dual extruders. What I mean is that if any of them is going to print outside the bed or general printing area (not extruder printing area) it will warn the user. Problem is that it will not be known which extruder does it without thorough research by the user, and in case of extruder change it may warn when it should not.

@Javierma
Copy link
Author

@foosel Change done

@foosel
Copy link
Member

foosel commented May 12, 2016

There's still a left-over reference to previousE :)

@Javierma
Copy link
Author

@foosel Sorry, forgot to remove that one

@foosel foosel added needs review This PR needs a review and removed needs some work There are some things to do before this PR can be merged labels May 12, 2016
@foosel
Copy link
Member

foosel commented May 12, 2016

@Javierma ok, I'll take another look and see if I can get that squashed and merged. Will probably not get around to do this until monday or so though, just so you know. Thank you for your patience with my nitpicking :)

@foosel
Copy link
Member

foosel commented May 19, 2016

@Javierma squashed, slightly adjusted and merged to the devel branch.

I had to change the behaviour slightly. What I didn't realize during review but once I went through the squashing was that it would have triggered a message for each file not fitting the current print volume on each reload. That's not that great of a user experience. I now adjusted it in such a way that it triggers the message when you try to select or select&print such a file. I also added the model dimensions to the additional data output.

Thank you again for the contribution and sorry that it took so long to get it integrated. And good luck with your coursework! :)

@foosel foosel closed this May 19, 2016
@Javierma
Copy link
Author

Great, and thanks a lot for your help

@Javierma Javierma deleted the area_warning branch May 28, 2016 17:37
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs review This PR needs a review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants