[QUESTION] Functionalities of fc5 function

[sid0nair]

Hey fullcontrol community! I have been trying to deepdive into the functionalities of the fullcontrol program (5 axis lab). How can I do it? Is there any possible way to get an overall idea about the workings behind the function...

[fullcontrol-xyz]

The multiaxis aspects are quite preliminary in nature since not many people have 5-axis systems and those that do, have quite varying systems. Basically, you design all the 5 coordinates (XYZBC) for every point. Then FullControl automatically figures out how to move the part correctly. It's complicated by the fact that rotating the bed also moves the part, so even if you design rotation but wanted to keep the nozzle in the same location on the part, the nozzle needs to move in X Y to stay in the same place on the part. And tilting printhead behaves differently. Eventually FullControl will accommodate lots of different options but for now they're just demos. Aside from those aspects linking the different axes together, 5-axis stuff is not really any more complicated than 3 axis aside from needing to design additional coordinates. To allow users to make use of the geometry functions in FullControl, you can use them but need to give the 3-axis fc.Points the ability to have two extra axes' information added. You can then retrospectively add BC data to the points.

[CleisonManriqueAguirre]

Does it apply also for rotating bed mechanisms ?

[AndyGlx]

Yep. The 4-axis example of FullControl is for a tilting nozzle, but one of the 5-axis examples is for a tilting+rotating bed. You 'design' in terms of part coordinates and FullControl will automatically calculate how the nozzle needs to move around when you rotate the part

[CleisonManriqueAguirre]

I have something similar to the brendonbuild prototype in a voron (I mean my toolhead cant rotate but bed can in 2 dof ). I am trying to build 5 axis gcode for an arc in yz pointing bed normal to the arc line but at the end the command [ gcode = fc5.transform(steps, 'gcode', gcode_controls) ] changes the expecting result to other coordinates .

[AndyGlx]

You'll need to make sure the origin of your rotation stages are set correctly in FullControl. I think they default to XYZ =0. If that doesn't help, start with a single point (e.g. X=10,y=0, z=0) then apply a 90 degree rotation in B or C and check thats the points 'moves' or doesn't as expected in real life. When the point 'moves' the nozzle naturally needs to follow it, hence the GCode no longer going to X10 Y0 Z0 after a rotation about C for example

[CleisonManriqueAguirre]

Thanks for the quick answers. I ll do some tests and see if everything goes fine

[CleisonManriqueAguirre]

Is it possible to disable that feature (the naturally movement)? I have some collisions between toolhead and the rotating bed. Or is it possible to adjust that naturally movement (could be amazing cause i need it)?

[AndyGlx]

I wonder if your axes might rotate the opposite way to FullControl's assumption. Convention is that +ive rotation moves the part anti-clockwise as you look down the axis (in the - ive axis direction)

There isn't currently an option to design B and C for the 'system' as opposed to the part. I mean to just define rotation and not move the nozzle. I will add that at some point.

For now, you just need to always think what you want the nozzle to do. So if you rotate a square 180 degrees, you also want the nozzle to move to the opposite corner. That will naturally lead to the nozzle staying still while the part moves. Not ideal, but not too difficult.

[CleisonManriqueAguirre]

Could be amazing if we can follow the box corner naturally and make naturally an arc in xz , ( the box corner when it rotates it make an arc naturally ) , so we can discretize it or use g2 g3. Thanks for the quick answer . Just one last question. Can I use fullcontrol for the open5axis (b_bed_c_bed) project?

[fullcontrol-xyz]

It's already easy to do that... just extend you list of steps with a 180-deree arc, and use enough segments (e.g. 32 or 64) so it'll look like a perfect arc. Even g2 and g3 commands are segmented into short straight line section (just by the printer firmware instead of you). It's just one line in fullcontrol with fc.arcXY :)

The b_bed_c_bed is how the 5-axis example is currently set up I think.

[CleisonManriqueAguirre]

Good , after dicretizing the arc works fine , inv kinematics works fine . Thanks

[fullcontrol-xyz]

Excellent! So it works fully as expected? ... Aside from the nice-to-have additional functionality of being able to directly design rotation of an axis without fullcontrol automatically maintaining nozzle position, everything is good?

[CleisonManriqueAguirre]

I have this gcode ; G0 F8000 X0.0 Y0.0 Z0.0 B0.0 C0.0 G1 F1000 X50.0 E1.663007 ;
G1 Z30.0 E0.997804 G1 X30.0 Z-50.0 B90.0 E0 ; why after rotating 90 degrees clockwise x goes to 30 again ? it needs to go further than 50mm .

When does the bed decide to rotate or not ? with fullcontrol i am free to set rotations and so on but when I rotate bed i do forward kinematics not inverse afaik

[fullcontrol-xyz]

This is what happens in real life. If you have a point at X50 Z30 and rotate is about the x axis (note that B+90 means you rotated anticlockwise when looking in the negative X direction), the 'X50' component will have moved to Z-50 and the 'Z30' component will move to X30. So the nozzle must move to that new point, to stay in the same location on the part being printed.

I'd recommend putting a blob of blue-tak on your rotation stage and sticking a toothpick in it. The free end of the toothpick represents a point on your part. Move the nozzle so it's just above the free end of the toothpick. Now do a small rotation of say 20 degrees and watch the toothpick move away from your nozzle. Then you'll need to manually move the nozzle to be back in contact with the end of the toothpick. That's the calculation that fullcontrol is doing.

[CleisonManriqueAguirre]

I see . I was following the inv kinematics form http://linuxcnc.org/docs/html/motion/5-axis-kinematics.html oc it depends on configurations but more or less it was the idea . So yours is not inv or forw , is a set of formulas to follow the current point .

[fullcontrol-xyz]

Is it inverse kinematics I believe... inverse kinematics calculate how the print head should move in the system (or machine) coordinate system based on the desired position and orientation in the part (model) coordinate system. It's just so happens that the BC terms have the same values/concept in both machine- and part- coordinate systems, so the designer is kind of designing system orientation even though they might be thinking in terms of part orientation.

[CleisonManriqueAguirre]

I see , thanks for explanation . I understand your formulas but from that website the y axis inverse kin formula doesn't match . I wonder why

[CleisonManriqueAguirre]

Following the gcode G0 F8000 X0.0 Y0.0 Z0.0 B0.0 C0.0 G1 F1000 X-30.0 E1.663007 ; G1 Z50.0 E0.997804 G1 X50.0 Z30.0 B90.0 E0

After going that direction I want to move x-15 but it writes z-15 . Is there a way to change to a relative position like G91 ? And after that move x-15 . Suppose I wanna start printing on top of one lateral face from a box

[fullcontrol-xyz]

Not within FullControl's python design environment. You're hacking between different coordinate systems... wanting some inverse kinematics and some not, which is a little risky. I understand why you want to do it and do sometimes myself, but you run risks of collisions. A simple way to do it is to add fc.ManualGcode(text='G92 B0') immediately after your B90 move. FullControl doesn't inspect ManualGcode so doesn't 'know' what you do in them, which is why I always say not to use them for anything that FullControl might need to know about (speed changes, movements, etc.). However, you deliberately don't want FullControl to know you've moved the part 90 degrees, so it's a neat trick for you!

Personally, I would recommend switching from the XY mindset to the full XYZ mindset. If you're printing on the lateral face of a box, you are printing in an XZ or YZ plane as opposed to XY. Again, I understand the appeal of XY. E.g. FullControl's geometry functions are mostly XY. But you can use FullControl's geometry functions still if you create them in the XY position and then rotate all the points about the centre of the box, or bottom edge of the box or something, to get them positioned correctly in the XZ plane.

The 'proper' thing for you is probably to define a new coordinate system on the face of the box, like a new sketch work-plane in CAD. Then you can design everything in XY and use a translation function to go from your temporary work-frame/coordinate system to the original 'part coordinate system'. This is what is often done behind the scenes in robotics to simplify things like probing ... if you make the probe direction temporarily +Z regardless of it's actual orientation, for example, then it's v easy to say "probe 10 mm in the 'Z' direction".