FullControlXYZ / fullcontrol

Python version of FullControl for toolpath design (and more) - the readme below is best source of information
GNU General Public License v3.0
672 stars 78 forks source link

[FEATURE REQUEST] Motion-aligned mesh visualisation #89

Open ES-Alexander opened 5 months ago

ES-Alexander commented 5 months ago

Is your feature request related to a problem? Please describe. Thinking a bit about extra control axes, and realised it would be helpful if the mesh visualisation could also give a sense of printhead orientation and twist, instead of just position and extrusion volume, to help confirm when 4+ axis GCode is actually being generated, as well as potentially helping to build intuition about how it works, areas for optimisation, and where it might be likely to fail.

Describe the solution you'd like While custom extrudate visualisation colourings should still be supported, it would be nice if we can create a new one that's focused on highlighting the orientation of the printhead relative to the base, ideally including cumulative filament twist over time (potentially with some thresholding / energy term to account for twist slip within the melt zone).

I haven't properly thought this through yet, but I'm thinking part of the solution could be having the mesh geometry account for printhead/bed tilt (i.e. instead of the polygonal cross-sections being locked to vertical on the planes transverse to translation), potentially emphasised with separate colours for the strips representing each side of the extrudate. I'm not sure how hard that would be to combine with the current "colour per turn" and "colour per extrusion cylinder" options, and haven't thought about the most useful ways of doing so (or whether it's best to just have a separate "side strips" mode, with no progress-based colour controls).

Describe alternatives you've considered A toolpath+toolhead animation (and especially a controllable one) could serve a similar purpose, although the static visualisation has the benefit of being less complex to explore, and likely significantly simpler to generate, while also being easier to share (including in image form).

Additional context Was watching this video and realised exploring 5-axis gcode generation approaches would likely be easier if the visualisation was more indicative of what the machine would actually do.

fullcontrol-xyz commented 5 months ago

Absolutely on board with this, and I think it's fairly simple. The 5-axis FullControl design already includes all the information that is required. It would be relatively simple to add a function that checks for min/max values of the desired extra axis (e.g. A/B/C) and then determine colour based on that just like it does for the z_gradient colour option.

I also really love the idea of an animation and/or progress-slider like slicers have.

For the tube stuff, I'm not sure of your exact programming for that, but it might also simplify things since 'twist' will be dictated by the design rather than automatically calculated. It's a little complicated by the fact the user currently design the GCode value of 4th/5th axes, which means different systems with different kinematics may have different nozzle orientations for the same values in gcode. This means system-specific kinematics may be required to identify the tube orientation. This unnecessary complexity will be eliminated if the user designs nozzle angle rather than the GCode values of extra axis. Both design methods are valuable. But if the user designs nozzle orientation (e.g. with spherical coordinates without radius) that very simply dictates the visualisation regardless of the system being used, which is very much in line with the overarching FullControl principles, so I like that. Perhaps an fc.Orientation object, used in conjunction with regular 3-axis points is a beautifully simple way to achieve that! It may eliminate the need for different fc.Point objects for different multiaxis systems.

Also, the video you shared seems to be doing 3 axis GCode then modifying the actual printing by adding some extra rotation and seeing what happens. I do find that quite fascinating, but I'm not sure it's worth focusing on since the practical value of that approach seems limited. It's kind of 'finding out' what the geometry is rather than designing it. The cause of the geometric variation due to extra axis motion is very easy to implement directly in a design. For example add a function to your design that rotates all points about a chosen centre-point by a given amount that depends on the current layer number. That would be the same as modifying the C axis a bit for each layer as. Gcode postprocess. And if you also modify the C axis in the design on each layer, you get the exact path that was previously achieved kind of accidentally. If we really wanted to offer people the ability to do the accidental thing, we could enable two design coordinate systems. FullControl currently assumes you're designing in the 'part' coordinate system and inverse kinematics calculate what the printhead needs to do to accommodate movement due to 4th/5th axes, but it would be possible to allow the use to design in 'system' coordinates, where it is the literal position of the nozzle relative to the printer frame rather than the part which may be twisting around all over the place.

Sorry, big brain dump there. Short story: colouring based in user-designed 4th/5th axis data is very easy and I think worth adding to the road map for implementation asap, with a linear colour gradient between min/max values of the chosen axis