Topics created by Freddiester

@t3p3tony said in 5-axis 3D printer on Prusa i3:

@cncmodeller the "slicer" is currently written in grasshopper which is part of the CAD software Rhino.

Thanks for the heads up. I'll have a look when I have some spare headroom.

It'd be interesting if the approach could be ported over to Fusion 360 as they have a fully integrated CAM approach.

I've often wondered if a 5 axis 3D surface toolpath with a ball end mill would work as a way to generate a wrap layer for such an application.

Anyway great stuff!

Cheers
Barry M

@Freddiester

Reading an Xbox controller, from an Arduino, or a Raspberry PI, or an ESP32 is EASY. Part of my halloween costume this year used a Wii joystick controller being read by an ESP32 (which is a $4 or $5 imbedded processor, most noted for its "internet of things" uses) to then change some of the things on the costume. Simple. Easy. Cheap. And only took a few hours to code everything.

Making pulses to move one stepper motor, on any of the above platforms, is EASY. Making pulses to move several steppers is almost as easy.

Making a "motion controller" to achieve "Coordinated Linear Motion" of a physical object such as a 3D printer head, a CNC cutter, a magnet for a sand table, is HARD.

Consider the simple case of a CNC cutter moving along at some non-trivial speed in a straight line. Coming soon is a 90 degree corner. The physical carriage cannot instantly stop moving along the existing line, and cannot instantly start moving in along the new line. It must be smoothly deccelerated; this is likely to involve changing the rate of several motors. Once the corner is reached, the carriage must be accelerated along the new line. Again, likely this takes coordinated motion of several motors. And so on and so forth. This is complex code and takes lots of time to develop and test. Also, it exists, inside numerous controllers like Grbl or TinyG or Marlin or Klipper or Duet.

Same thing if an Xbox controller is feeding, only worse, because the motion planner cannot "look ahead" and see the next direction changes. So the carriage is moving along at a good clip and all of the sudden the person pulls the joystick almost directly opposite. Again, must decel, then accel, etc, etc. This is complex code.

So, yes, the Duet and other G-Code based controllers are designed to have "look ahead" planners that work from a sequence of commands. That's probably not the place to start for human (or other non-predictable) input to control steppers to move objects. It is most definitely the place to start for any motion that can be described or calculated or listed in advance.