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

Option to skip griffin header validation. #44

Open
wants to merge 3 commits into
base: master/s-line
Choose a base branch
from

Conversation

casperlamboo
Copy link

Files generated by the command line interface of CuraEngine are output in serial mode, meaning the header has to be printed before the print-time and material estimates are known. This will be needed for command-line tools we used to benchmark the engine with in the nightlies.

part of CURA-9495

Files generated by the command line interface of CuraEngine are output in serial mode, meaning the header has to be printed before the print-time and material estimates are known. This will be needed for command-line tools we used to benchmark the engine with in the nightlies.

part ofCURA-9495
rburema and others added 2 commits March 21, 2023 10:38
done as part of CURA-9495

Co-authored-by: Casper Lamboo <casperlamboo@gmail.com>
Copy link
Contributor

@onnodb onnodb left a comment

Choose a reason for hiding this comment

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

Looks fine overall, but some small nitpicks.

More importantly, can we capture your changes in some extra unit tests? (The unit test files seem to already be there, but curiously, I don't see their status being reported here in GitHub. Who owns the CI for this one, is that us?)

Comment on lines +74 to +78
try:
GCodeFile.__validateGriffinHeader(metadata)
except InvalidHeaderException as ex:
if not GCodeFile.SkipHeaderValidation:
raise ex
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not a simple

if not GCodeFile.SkipHeaderValidation:
    GCodeFile.__validateGriffinHeader(metadata)

? Isn't that more straightforward than the whole try..except? Or maybe I'm missing something?

Copy link
Member

Choose a reason for hiding this comment

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

We do this because apparently, the validate function also parses part of the header.

Rewriting it so that it first validates, then parses would be a bit out of the scope of this small change.

This is also why we moved the parts in the validation around.

Copy link
Contributor

Choose a reason for hiding this comment

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

We do this because apparently, the validate function also parses part of the header.

With that, I presume you mean that __validateGriffinHeader() also returns or modifies some kind of state? I'm probably "looking with my nose", as we'd say, but the only thing I see is the function checking things and raising exceptions. It has neither a return value, nor does it modify (global) state.

So I don't think your concern is actually valid? (Otherwise I'd agree that you'd want to limit the scope of these changes)

Copy link
Member

Choose a reason for hiding this comment

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

Yes, that's what I meant when I wrote that :-)

... now that I'm re-checking the function, I can see what you say. Strange, I could've sworn that something was saved in that function. I remember trying it without. -- Perhaps I did something wrong when I originally tried that.

If we're not both wrong, we could indeed try to resolve it the way you originally suggested here.

@@ -22,6 +22,7 @@ class GCodeFile(FileInterface):
mime_type = "text/x-gcode"

MaximumHeaderLength = 100
SkipHeaderValidation = False
Copy link
Contributor

Choose a reason for hiding this comment

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

In general, double negatives are something you may want to avoid. Better to introduce a setting ValidateHeader with a default of True.

Copy link
Member

Choose a reason for hiding this comment

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

I agree with the general sentiment. However, the (extra) negative here is meant to imply that this is not standard behaviour.

I'm perfectly fine with changing it if there are any strong feelings about this though.

Copy link
Contributor

Choose a reason for hiding this comment

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

No particularly strong feelings, if it's something you've considered already. I do see your point :)



# Validate extruder train, part I
for index in range(0, 15):
Copy link
Contributor

Choose a reason for hiding this comment

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

Why the increment from the original 10 to 15? And could you perhaps make this a named constant while you're at it?

Copy link
Member

Choose a reason for hiding this comment

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

What the user sees in the front-end is a max of 8 extruders. In the engine (and some of the frontend code as well) we assume max 16 extruders in code. I'm not sure where '10' came from.

Yes, a constant would be good.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks, that's clear! A named constant with a small comment explaining that bit would indeed be helpful for the future. Thanks 🙏🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants