search

MaikStohn / UP3D

UP 3D Printer Tools
GNU General Public License v2.0
79 stars 33 forks source link

Up! Box printing at a 3-5 degree angle. #31

Open orthoa opened 8 years ago

orthoa commented 8 years ago

Was testing out the new release v0.7.0 and it is printing at a slight angle 3-5 degrees. Raft was solid and I don't get this issue through the UP! Software.

gcode and umc file are in the zip tensile-specimen.zip

img_1270 img_1269

smonson78 commented 3 years ago

I started messing around with this and made a USB capture of the Up Studio software's output. After converting this from umc to gcode with convg there are many things that appear to be broken and that I don't understand. If anyone out there is still interested in collaborating with me on trying to fix this old software give me a 'hoy.

smonson78 commented 3 years ago

I spent some hours today looking at a comparison between an original gcode file generated by Cura and the .umc output that was actually sent to the printer. The first thing that stands out is that the cmd4 (MoveL) mathematical formula doesn't appear right.

Example:

; previous movement
G0 F3600 X79.75 Y79.75 Z0.3

; next gcode movement command in the original file
G1 F900 X60.25 Y79.75 E1.21607

This corresponds to a movement of exactly 19.5mm on X (or Y as it's called in the convg'd output), which is 12,558 physical steps (6,429,696 512th-steps) on my Up Plus 2 which is 644 steps per mm.

The umc data rendered into the printer is:

; 040000001e00a861d8ff11001100aeff00000000 MoveL (30, 25000, -40, 17, 17, -82, 0, 0)
; 04000000ab0176615df601000a00000000000000 MoveL (427, 24950, -2467, 1, 10, 0, 0, 0)
; 04000000ab0176615df601000a00000000000000 MoveL (427, 24950, -2467, 1, 10, 0, 0, 0)
; 04000000ab0176615df601000a00000000000000 MoveL (427, 24950, -2467, 1, 10, 0, 0, 0)
; 04000000ab0176615df601000a00000000000000 MoveL (427, 24950, -2467, 1, 10, 0, 0, 0)
; 04000000ab0176615cf601000a00000000000000 MoveL (427, 24950, -2468, 1, 10, 0, 0, 0)
; 04000000ab0176615df601000a00000000000000 MoveL (427, 24950, -2467, 1, 10, 0, 0, 0)
; 040000000200ca53e1f8ff00ff003c0000000000 MoveL (2, 21450, -1823, 255, 255, 60, 0, 0)

When using the cmd4 math from the codebase, this comes to 6,325,727 512th-steps (that's ignoring the acceleration), plus acceleration adjustments on the first and last command:

30 * -40 = -1200
427 * -2467 = -1053409
427 * -2467 = -1053409
427 * -2467 = -1053409
427 * -2467 = -1053409
427 * -2468 = -1053836
427 * -2467 = -1053409
2 * -1823 = -3646

plus acceleration terms:
first: (30 - 1) * (30 / 2) * -82 = -35670
last: (2 - 1) * (2 / 2) * 60 = 60

Total 512th-steps: -1200 - 1053409 - 1053409 - 1053409 - 1053409 - 1053836  - 1053409 - 3646 - 35670 + 60 = −6361337

This is 6429696 - 6361337 = 68359 = 0.20731mm short of the true distance.

When rendered back into gcode by convg, the nozzle move commands end at

G1 X79.7500 Y-60.4488 E3.05621 F868

which is -60.4488mm, close to the predicted figure of -60.45731mm instead of -60.25mm as it should be. Although it is still out by 0.00851mm (5 steps) for which I have no explanation.

I am wondering whether these math errors are contributing to the error in the layer starting positions. Both X and Y axes are affected by the tilting issue, although it seems X is more substantially affected than Y for some reason.

I would like to know where these formulae came from if anyone knows.

smonson78 commented 3 years ago

Another question is why does Up render 1 in the Y axis when that axis isn't supposed to be moving at all? Does 1 really mean 0 somehow?