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

Feature Request: Add object/model/mesh name comments to gcode blocks #801

Closed
paukstelis opened this Issue Jun 28, 2018 · 12 comments

Comments

Projects
None yet
4 participants
@paukstelis
Contributor

paukstelis commented Jun 28, 2018

This is a request to place a comment with object names at the beginning of each gcode block associated with an object. This would something along the lines of: ;OBJECT:<name or meshgroup index> . This feature would allow streaming servers for printing (e.g. octoprint) to have control over individual objects during printing. Specifically, this feature would allow use of the Octoprint-Cancelobject plugin, which currently is limited to use with Simplify3D and Slic3r. If a text name is not doable, I would think even the mesh's meshgroup index would work to demarcate objects in the gcode.

@paukstelis

This comment has been minimized.

Contributor

paukstelis commented Jun 29, 2018

Just saw the feature_mark_models_in_gcode branch. Will check it out.

@paukstelis

This comment has been minimized.

Contributor

paukstelis commented Jun 30, 2018

Both branches that add the Mesh comments work nicely. How difficult would it be to pass the mesh's filename from the frontend to provide a slightly more descriptive comment? I mean, I know what ;MESH:75092768 means, but others might not :)

@alekseisasin

This comment has been minimized.

Contributor

alekseisasin commented Jul 13, 2018

@hi @paukstelis , the MESH:75092768 is a memory address of this object, which is generated by a system. For now, we did not define the constraint for manually ( via a front end) defining the object names. At this moment it is not in our plan, but we get requests for it.

@paukstelis

This comment has been minimized.

Contributor

paukstelis commented Jul 13, 2018

@alekseisasin, thank you for the reply. Forgive me for not fully understanding how this is all laid out, but how are meshes passed from the front end to CuraEngine? I see in the console that it passes the object/mesh indexes with the l flag, though it looks to me like the mesh has actually already been assembled with uranium as a UM.Mesh.MeshData? That data already has a filename variable associated with it if I am looking at this correctly. Would it be possible to simply add that filename to the mesh object in CuraEngine so it could replace the memory address? Again, sorry if I am missing something here.

@alekseisasin

This comment has been minimized.

Contributor

alekseisasin commented Jul 16, 2018

There is a difference between running CuraEngine in console and Cura. In Cura we are creating a message and then passing it to the CuraEngine. Check libArcus and libSavitar.
One of the disadvantages of sending just a name, what if we have a few models with the same name, then we still need to distinguish them.
It is not difficult to add a clear name into G-code instead of a memory address. At this moment I cannot promise when it will be added/adjusted, but I will keep in mind your proposal.

@paukstelis

This comment has been minimized.

Contributor

paukstelis commented Jul 26, 2018

One of the disadvantages of sending just a name, what if we have a few models with the same name, then we still need to distinguish them.

This was handled in Slic3r by just including copy followed by copy/index number. I think just appending the index number of the object should be sufficient.
I do think moving forward that including this information will be quite beneficial for real-time control of the printing processing.

@alekseisasin

This comment has been minimized.

Contributor

alekseisasin commented Jul 26, 2018

Adding a name to the mesh will give many benefits, especially for developers.

@BagelOrb

This comment has been minimized.

Member

BagelOrb commented Jul 26, 2018

It would be safer to add the mesh index rather than the memory address. I'm not a real hacker tho

@paukstelis

This comment has been minimized.

Contributor

paukstelis commented Aug 20, 2018

I've managed to get this working without too much effort, but I'm sure it can be improved by those that actually know what they are doing.

CuraEngine modifications:
https://github.com/paukstelis/CuraEngine/tree/feature_mesh_names

Cura modifications:
https://github.com/paukstelis/Cura/tree/feature_mesh_names

@BagelOrb

This comment has been minimized.

Member

BagelOrb commented Aug 20, 2018

The code doesn't look all that bad.

Please make a pull request. The Cura team might review it after a couple of weeks and request some changes, which will make you learn about CuraEngine and programming in general.

@paukstelis

This comment has been minimized.

Contributor

paukstelis commented Aug 21, 2018

Pull request made. #828
As a non-programmer, I can say I have already learned a lot getting this far, though nearly all of these changes are just converting the memory address to a string.

@Ghostkeeper

This comment has been minimized.

Member

Ghostkeeper commented Oct 24, 2018

I don't know why Github doesn't show #828 as being merged, but it is merged. This issue should be fixed for Cura 3.6.

@Ghostkeeper Ghostkeeper added the fixed label Oct 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment