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

[FR]: Report height/layer info in OctoPrint UI #50

Open
jcostom opened this issue Sep 28, 2024 · 3 comments
Open

[FR]: Report height/layer info in OctoPrint UI #50

jcostom opened this issue Sep 28, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@jcostom
Copy link

jcostom commented Sep 28, 2024

Is your feature request related to a problem? Please describe.

First, let me say this plugin is fantastic. I had some disconnect troubles a few versions ago, but it's been amazingly stable for the past few releases. Great work! Not sure I'd classify this as a "problem", but more of an enhancement request. OctoPrint's status box has fields for current height and layer progress. These are currently blank, as shown in the screenshot attached.

Screenshot 2024-09-28 at 17 14 38

Describe the solution you'd like

I'd like to see those stats displayed if possible.

Describe alternatives you've considered

Not sure there are alternatives available in this case.

Additional context

I think pybambu (that's what you're using under the hood, right?) can report layer info. Not sure if it reports current job's layer height. If so, it's just a little multiplication, naturally.

Thanks again for your work on this plugin!

@jneilliii jneilliii added the enhancement New feature or request label Sep 28, 2024
@jneilliii
Copy link
Owner

I think this might be a limitation of the OctoPrint's job info while printing from SD. Those fields I believe are only populated when printing from local file storage and since the plugin is acting as a virtual SD card it might not be possible to populate without some tricky monkey patching of the code. Will look into it as time permits.

@jcostom
Copy link
Author

jcostom commented Sep 30, 2024

Thanks! Clearly not a high priority, just a nice to have.

@disconn3ct
Copy link

I've been pondering opening this same FR honestly. It might belong upstream instead, but since this plugin 'fakes' so much of a connection it might be doable here.
In a situation where Octo has an identical file (name, size) it should be possible to read the local file and make more assumptions about the print state. (It should also probably have a disable button somewhere in case of mismatches.) This could even allow the live-view gcode viewer to mostly work.

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

No branches or pull requests

3 participants