[BUG] Markforged_XY option has problem to make small circles round

[Marek-zl]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

1) Markforged_xy there is problem with motor direction, I can not find the right setting. Motor is going all the time in wrong dirrection. With all settings like true and false direction or change pins on motor. No right possition. 2) the circles are not circles are on left and right side smaller, sides of the circle are more like cube. With size of the circle, it is more less dissapier.

Bug Timeline

new

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

02010000

Printer model

No response

Electronics

BTT octopus pro v1

Add-ons

No response

Bed Leveling

No Bed Leveling

Your Slicer

Prusa Slicer

Host Software

Other (explain below)

Additional information & file uploads

[Marek-zl]

result

[descipher]

LOL, if you move X manually does Y move?

[descipher]

I did some tests on a cartesian frame with MARKFORGE_XY enabled. It works correctly without odd flat areas on the sides. Of course it is skewed at 45 degrees but that's expected due to X moving negative to hold it's position. I did have to modify the code for it to operate correctly in XY format. You may be experiencing a racking issue where the axes need to be adjusted to square and or belt tension needs to be set equal. Just used a pencil to track the move, it was a little loose but not an issue.

https://github.com/MarlinFirmware/Marlin/blob/a1d4942f760fa1d589af11d378a938fba6f45cd2/Marlin/src/module/planner.cpp#L825

  block->decelerate_after =  block->step_event_count - decelerate_steps; <-this makes sure the steps are set equally at each end of a segment. 

https://github.com/MarlinFirmware/Marlin/blob/a1d4942f760fa1d589af11d378a938fba6f45cd2/Marlin/src/module/planner.cpp#L1962-L1964

  #elif ENABLED(MARKFORGED_XY)
    if (da - db < 0) SBI(dm, A_AXIS);              // Motor A direction
    if (db < 0) SBI(dm, B_AXIS);                   // Motor B direction

https://github.com/MarlinFirmware/Marlin/blob/a1d4942f760fa1d589af11d378a938fba6f45cd2/Marlin/src/module/planner.cpp#L2015-L2016

  #elif ENABLED(MARKFORGED_XY) 
    ABS(da - db), ABS(db), ABS(dc)

[Marek-zl]

I think that if there problem with belts, has to be problem print something. I have fine surface on prints, no problem to print cubes, the problem is just on circle. I can try to play around with belts, but I do not think that problem is there.

[descipher]

block->decelerate_after =  block->step_event_count - decelerate_steps;

This is important for syncing steps across the axes , did you try it?

[Marek-zl]

no, where it is?

I tried 0,1mm steps to test belt tention, manualy stepping x y and seems it is quite good.

[rondlh]

@Marek-zl

if (da - db < 0) SBI(dm, A_AXIS); // Motor A direction (- instead +) Changing the sign doesn't do much, it's just a matter of definition of the positive Y-direction. Changing the sign will mirror the print in the Y-direction, that's all.

I tried 0,1mm steps to test belt tention, manualy stepping x y and seems it is quite good. This kind of zigzag line is quite useful, it would show the problem I expect my printer has (on the mechanical side, sticking of the X-carriage, perhaps a bit of racking). To really test this the 0.1mm steps should be made slowly to allow the carriage to come to a complete stop before doing the next step. This can be done manually or insert some G4 (dwell). Several zigzags would be needed. The problems are in the change of direction.

In my case, I will reduce the friction on the X-carriage as much as possible. I found that the carbon fiber guide rods and PETG bearing have a bit too much static friction. I will work on this and do some more test, but I currently do not have access to the printer because of the labor day break.

For Markforged_XY, there seems to be a bit of confusion still... da just means delta on stepper A. Stepper A is linked to the X-axis. If you make steps on motor A then the carriage X-position will change, but not the Y-position. Stepper B is linked to the Y-axis, but moving Y affects the X-position too. So you will have to take corrective actions on X to keep it's position, or to make it go where you want it to go. I'm convinced that the Marlin math and stepper signals are correct.

[descipher]

@Marek-zl

if (da - db < 0) SBI(dm, A_AXIS); // Motor A direction (- instead +) Changing the sign doesn't do much, it's just a matter of definition of the positive Y-direction. Changing the sign will mirror the print in the Y-direction, that's all.

That's true however this must be consistent across the code. e.g. needs to be insync with

https://github.com/MarlinFirmware/Marlin/blob/3bcbd3259f8d1ff3fc262b2ede83efd873863d5f/Marlin/src/module/planner.cpp#L2063-L2065

[descipher]

no, where it is?

https://github.com/MarlinFirmware/Marlin/blob/a1d4942f760fa1d589af11d378a938fba6f45cd2/Marlin/src/module/planner.cpp#L825

I tried 0,1mm steps to test belt tention, manualy stepping x y and seems it is quite good.

Yes you have an issue. It is not transitioning at 90 degrees.

[Marek-zl]

block->decelerate_after = accelerate_steps - plateau_steps --- Is doing nothing in the result

I gues that if this problem is on belt, it has to looks different. Belt is pulling until is on the top of the circle.

When problem with belts has to be circle broken in the point where motor changing dirrection. But it is not this case, flat part start before top of the circle, so before belt changing dirrection.

On picture is circle made of the normal G-code

this circle is with G2 with this setting

// G2/G3 Arc Support //

define ARC_SUPPORT // Requires ~3226 bytes

if ENABLED(ARC_SUPPORT)

define MIN_ARC_SEGMENT_MM 0.01 // (mm) Minimum length of each arc segment (0,1)

define MAX_ARC_SEGMENT_MM 0.1 // (mm) Maximum length of each arc segment (1,0)

define MIN_CIRCLE_SEGMENTS 72 // Minimum number of segments in a complete circle

//#define ARC_SEGMENTS_PER_SEC 50 // Use the feedrate to choose the segment length //#define N_ARC_CORRECTION 25 // Number of interpolated segments between corrections (25) //#define ARC_P_CIRCLES // Enable the 'P' parameter to specify complete circles //#define SF_ARC_FIX // Enable only if using SkeinForge with "Arc Point" fillet procedure

[descipher]

Belt is pulling until is on the top of the circle.

Not really, look at the movement trace I did on the Cartesian frame. That represents the actual motor movements. With the image horizontally mirrored to match your moves the right XY idle point belt transition is approximately at 60 degrees and thats where X starts to go in the negative direction from a stand still.

[rondlh]

I did some more tests and solved some issues on my IDEX Markforged_xy printer. I found that the X-carriage was sticking a bit causing the artifacts that I showed above. After making some adjustments (new bearings, tighter belts) I got some nice results. I attached the STL and Gcode (Cura 5 beta 1) too for reference. Note that the gcode does not use the G2 command, but it uses straight line approximations in the same ways as G2 does. This looks quite satisfactory in my view. Markforged systems will always have some inaccuracy because of racking, friction and belt flexibility, I believe that is what the people here are experiencing. So please make sure your belts are tight and friction is at a minimum. For testing you can use tiny steps (0.1mm) in the X- and Y-direction, forwards and backwards to see of the carriage follows that accurately. In my case I could see that some steps were not visible in carriage movement, but after some more steps suddenly the carriage started moving. Circle_test STL GCODE.zip

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.