UP USB protocol

Software
1

I’m starting to using the open-source gcode converter UP3dTools (which has been discussed on the forum before) to do some basic prints, but it doesn’t produce good results and I’m trying to determine why that is.

When looking at this test gcode file that has been 3D-printed through Up Studio 2 to my Up Plus 2:

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

; current movement, -19.5mm on X axis
G1 F900 X60.25 Y79.75 E1.21607

This is the corresponding series of relative-movement commands (command 4) sent to the printer by Up Studio:

Hexadecimal bytes                        Relative movement command parameters
040000001e00a861d8ff11001100aeff00000000 (30, 25000, -40, 17, 17, -82, 0, 0)
04000000ab0176615df601000a00000000000000 (427, 24950, -2467, 1, 10, 0, 0, 0)
04000000ab0176615df601000a00000000000000 (427, 24950, -2467, 1, 10, 0, 0, 0)
04000000ab0176615df601000a00000000000000 (427, 24950, -2467, 1, 10, 0, 0, 0)
04000000ab0176615df601000a00000000000000 (427, 24950, -2467, 1, 10, 0, 0, 0)
04000000ab0176615cf601000a00000000000000 (427, 24950, -2468, 1, 10, 0, 0, 0)
04000000ab0176615df601000a00000000000000 (427, 24950, -2467, 1, 10, 0, 0, 0)
040000000200ca53e1f8ff00ff003c0000000000 (2, 21450, -1823, 255, 255, 60, 0, 0)

Looking at the commands, it seems that parameter 1 is a number of counts, and parameter 3 is the number of 512ths of a motor step to advance the X axis by on each count. This gives 6,325,727 / 512 = 12354 motor steps, which is 19.18mm for the Up Plus 2’s 644 steps/mm. A bit short of the actual 19.5mm movement. Presumably, the 6th parameter can be used to make up the missing 103,969 512th-steps for the X axis. But it’s not clear how that might add up to 103,969.

So my questions are,

  1. How do the final 3 parameters work? - UP3DTools interprets these as acceleration terms.
  2. Why is the Y axis (4th parameter) being slightly moved during an X-axis-only movement command?

Can anyone give any hints on how this works or is intended to work?

2

could it have to do with feedrate, acceleration and jerk?

I’m not sure but after seeing the perimeter infill gap go unfixed for close to 2 years… I wouldn’t be surprised if this was simply a bug to be honest.

3

I hope so, because that would at least make sense! But I wouldn’t be surprised if it was a bug either. If it is a bug, and someone from Tiertime would be kind enough confirm the intention/mathematics of the parameter values, it might be possible to work around it with software.

UP3DTools treats the extra parameters as acceleration values, and has a mathematical formula to follow, which the original author seems very confident about. But the numbers don’t add up, and the print gets a 3-5 degree tilt to it as the errors accumulate over multiple layers. I’d rather keep it as an open-ended question.