What does machine_center_is_zero do

[Ocarthon]

From what i understand, the setting _machine_center_iszero translates, if true, all points by half of the width and half of the height. As a result, point (0; 0) would now be (width / 2; height / 2).

But CuraEngine does the opposite. In MeshGroup.cpp the behaviour i described is true when _machine_center_iszero is false. Do i understand that setting wrong or is that a bug?

[BagelOrb]

That could very well be a bug. All our machines don't have the origin in the middle, so we don't really test that setting.

Does it result in a bug for machines which do have their centre at zero? Op 3 jul. 2016 14:17 schreef "Philip Standt" notifications@github.com:

From what i understand, the setting _machine_center_iszero translates, if true, all points by half of the width and half of the height. As a result, point (0; 0) would now be (width / 2; height / 2).

But CuraEngine does the opposite. In MeshGroup.cpp https://github.com/Ultimaker/CuraEngine/blob/master/src/MeshGroup.cpp#L123 the behaviour i described is true when _machine_center_iszero is false. Do i understand that setting wrong or is that a bug?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/367, or mute the thread https://github.com/notifications/unsubscribe/AIe9EVzkUKSnqBMNMmSbCFreGiaBSHgPks5qR6higaJpZM4JD29B .

[Ocarthon]

I am using CuraEngine with a socket connection so slice my objects. For testing purposes i used the default Ultimaker 2 Json-File and the object was always in the center (center_object set to false). Only if i set machine_center_is_zero to true it gets placed at it's 'real' position.

I am using the version of CuraEngine that gets shipped with the newest version of Cura. I got not yet around to compile it myself.

[BagelOrb]

I can't really check the code ATM, but I think it's like this: CuraEngine expects input points to have their origin in the middle of the printer. If then machine_centre_is_zero is true the output will have the same origin.

The frontend is responsible for sending the 3d data such that the origin always correspond with the centre of the printer.

I am using CuraEngine with a socket connection so slice my objects. For testing purposes i used the default Ultimaker 2 Json-File and the object was always in the center (center_object set to false). Only if i set machine_center_is_zero to true it gets placed at it's 'real' position.

I am using the version of CuraEngine that gets shipped with the newest version of Cura. I got not yet around to compile it myself.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/367#issuecomment-230157512, or mute the thread https://github.com/notifications/unsubscribe/AIe9EfbPUk99KgYV3e_sNq2_XVF4CQj_ks5qR83qgaJpZM4JD29B .

[Ocarthon]

Oh, then the behavior is obvious. The problem is that it's not well documented. Same with libArcus, where i had to look at the code to know how the protocol works.

Thanks for you response.

[BagelOrb]

Documentation is indeed not really up to standard. Sorry for that.

What kind of documentation did u need? In-code or some standalone document?

Why did you have to know how the protocol works? Op 3 jul. 2016 17:30 schreef "Philip Standt" notifications@github.com:

Oh, then the behavior is obvious. The problem is that it's not well documented. Same with libArcus, where i had to look at the code to know how the protocol works.

Thanks for you response.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/367#issuecomment-230159115, or mute the thread https://github.com/notifications/unsubscribe/AIe9EREtYTwFgIUN8Ws56-7gNZoPFCwQks5qR9V-gaJpZM4JD29B .

[Ocarthon]

In case of libArcus, the protocol is just roughtly described (header, size, type, message) without saying what header and type are (size and message are obvious).

[BagelOrb]

@awhiemstra Can you maybe explain this a bit?

[Ocarthon]

I now know how it works and i will maybe (if i have time) make a PR to add that to the README

[BagelOrb]

If you are talking about the .proto file: that file is going to change quite drastically on master in the near future. We've already commented quite some stuff there in master and in a separate branch.

Or isn't that what you are talking about?

2016-07-05 11:16 GMT+02:00 Philip Standt notifications@github.com:

I now know how it works and i will maybe (if i have time) make a PR to add that to the README

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/367#issuecomment-230427677, or mute the thread https://github.com/notifications/unsubscribe/AIe9EZyB5NSBYhUwv8b_GKUW2_s0_HdUks5qSiDggaJpZM4JD29B .

Kind regards,

Tim Kuipers

Ultimaker BV

www.ultimaker.com

[Ocarthon]

If you want to communicate with CuraEngine over a socket connection in a language other than C++ or Python you have to recreate libArcus. For that you need to know the protocol libArcus uses, which is only roughly described. It is nowhere documented what header and type in the protocol are.

Header: 0x2BAD (SIGNATURE), 0x01 (MAJOR), 0x00 (MINOR) Type: (fnv) hash of the full proto typename

With thos information i was able to recreate libArcus in Java and to communicate with CuraEngine.

[BagelOrb]

I'm not really an expert on libArcus, but shouldn't you add code to libArcus, rather than replacing it?

libArcus is meant for the communication between different programs and programming languages.

If you add to libArcus and submit a pull request, we might improve on your code the moment we improve on our side of libArcus.

What do you think, @awhiemstra? Op 5 jul. 2016 18:00 schreef "Philip Standt" notifications@github.com:

If you want to communicate with CuraEngine over a socket connection in a language other than C++ or Python you have to recreate libArcus. For that you need to know the protocol libArcus uses, which is only roughly described. It is nowhere documented what header and type in the protocol are.

Header: 0x2BAD (SIGNATURE), 0x01 (MAJOR), 0x00 (MINOR) Type: (fnv) hash of the full proto typename

With thos information i was able to recreate libArcus in Java and to communicate with CuraEngine.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/367#issuecomment-230522216, or mute the thread https://github.com/notifications/unsubscribe/AIe9EXi8VomxTq4pLW_fG6-SsehGZl-Iks5qSn-ugaJpZM4JD29B .

[Ocarthon]

You understood me wrong. I ported libArcus to another programming language (Java), because i wanted to communicate with the CuraEngine via Java. Because of the differences in Protobuf it was not easily possible to create bindings like it is done with Python.

I don't how it is with other languages, but (atleast in Java) it's easier to just port it (only around 250 lines) than to call the library natively.

[Ghostkeeper]

With thos information i was able to recreate libArcus in Java and to communicate with CuraEngine.

Whoa, quite impressive!

[nallath]

Do you happen to have the source code for this? I think this is the kind of stuff that should be shared with the world.

[Ocarthon]

It's almost finished. I will make it public when i have finished and documented it.

[BagelOrb]

I'm curious; why are you making a new frontend?

[Ocarthon]

Supported by my school, I take part in a competition with a 3d printing related project. I won't go into detail until the end, because you never know if someone steals the idea and then makes it public.

This project will also be graded as my last computer science exam.

[BagelOrb]

Sounds cool!

Which school? What is the competition called?

[Ocarthon]

It's a competition that takes place in Germany called "Jugend Forscht". I attend the Paul Gerhardt Gymnasium in Gräfenhainichen. My school already had two projects that took place at the Intel ISEF an got 1. and 2. place.

[Ocarthon]

I finally finished my Java port and published it here: libArcus-Java

[BagelOrb]

Awesome!

[BagelOrb]

How did the project work out? Did you get the Java frontend to work?

Are you willing to share your code with the world?

[Ocarthon]

I did not have a lot of time because of school and the time i had was put into the other part of the project. Today i started again working on the CuraEngine part and directly had a questions that i forgot to ask: Is there a list of all possible settings? Or what is at the moment more important to me: What settings can i set per extruder. I want to configure everything over the socket connection without the need of a printer-specific configuration file.

[BagelOrb]

https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json contains nearly all setting definitions. (Together with: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmextruder.def.json https://github.com/Ultimaker/CuraEngine/blob/master/resources/command_line_settings.def.json )

Note that (nearly) all settings which have child settings aren't actually used by the engine, but may be handy for the frontend only.

You can see which settings you can set per extruder by seeing whether the setting definition has "settable_per_extruder": true

[Ocarthon]

Would you mind if i extend the documentation by all the possible settings? I would make 3 tables: machine settings, extruder settings and mesh settings (meshgroup settings seem to not exist?). Each table would have 5 columns: setting key, label, description, type, default value.

Since i have to do that for my project anyways, i could also publish that.

[BagelOrb]

The documentation is automatically generated from the code, but you can include extra stuff in there.

Do you know how to work with doxygen?

The thing is that the settings often change, so if you have the basic table I should write a script to automatically generate the table from cura/resources/definitions/fdmprinter.def.json and the like.

Note that the default value is often not used because it's overwritten by machine defaults, profiles, material settings and quality settings.

I also suggest you only make a single table. Some settings are both mesh settings and global settings, but shouldn't be edited per extruder. Note that all mesh settings can also be provided per extruder or globally. The settings bases inherit from each other. Your tables would have quite a bit of overlapping content.

Op 10 okt. 2016 18:56 schreef "Philip Standt" notifications@github.com:

Would you mind if i extend the documentation https://github.com/Ultimaker/CuraEngine/tree/master/documentation by all the possible settings? I would make 3 tables: machine settings, extruder settings and mesh settings (meshgroup settings seem to not exist?). Each table would have 5 columns: setting key, label, description, type, default value.

Since i have to do that for my project anyways, i could also publish that.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/367#issuecomment-252678346, or mute the thread https://github.com/notifications/unsubscribe-auth/AIe9EXbsSSHCsQC8X7nBLu39ZvYLzrXmks5qym4ygaJpZM4JD29B .

[Ocarthon]

Okay, i did not know that the settings often change. If the fdmprinter.def.json file changes i would just incorporate those changes. To fix the problem with the overlapping setting "groups" i could add "Settable per extruder / mesh" to the description.

Regarding the documentation: doesn't the documentation directory just contain .md files (and images) that are then used by Doxygen to generate the complete documentation? I would just add a settings.md file with the table, link to it from mainpage.md and maybe remove the dead reference to the code conventions.

[Ocarthon]

I quickly wrote a script and this is the result: Link

It recursively reads the settings and outputs them as a table in markdown. The three tables correspond to the three def files. Also all enums are stored and prepended.

[BagelOrb]

I think it would be good to add the information of whether a setting is editable per mesh, per extruder and/or per meshgroup/globally.

Yeah, it's simple markdown.

Dead reference to the code conventions? Just fixed that.

I would add the enums inside the normal table though. Perhaps just add it to the type column?

Looking good!

[Ocarthon]

My version now includes how the settings are settable (Globally, Mesh, Extruder).

If the enums were directly in the table, it would (atleast here on Github) look squeezed. For that reason i also put line breaks on some setting keys, so that this column takes up less space. I also generated the documentation with Doxygen and there, i think, would be enough space. What do you think?

[BagelOrb]

The Extruder settings seem to be wrong. Every setting which has "settable_per_extruder": true or which doesn't have that property should be tagged with Extruder...

For example magic_mesh_surface_mode doesn't have the Extruder tab.

[Ocarthon]

Does this also apply for "settable_per_mesh" and "settable_per_meshgroup"? This can be easily fixed, i just didn't know the default values of they are not set. There are no meshgroup settings set to true, so i suspect they are true by default.

Also one important aspect: in what language would you prefer the script to be. Mine is written in PHP and outputs markdown. You can see the output here.

One thing missing yet is to automatically add line breaks on the key column. This would be needed if it has to look good on Github. Otherwise it can be ignored since the table generated by Doxygen has a bigger width.

[BagelOrb]

settable_per_meshgroup is something you can / should ignore for the moment. It's only used for one-at-a-time printing and the frontend doesn't use it correctly anyway.

Moveover, nearly all settings which are settable_globally are also settable_per_meshgroup, so there's no real value in distinguishing between them.

Oh I guess we'd prefer python3, but let's not make a big deal out of this little script.