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

[orthoa]

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

[MaikStohn]

Hi,

thanks for the report and the files. This means that there is still some rounding error in the firmware which we need to find.

[adrianbear]

Hi @orthoa,
Could you share your Simplify3d factory file too? (or Cura or Slicer settings).
I'd like to try and re-produce your issue.
Thanks
Adrian

[adrianbear]

Hi @orthoa,

Actually don't worry about it. I just reproduced the issue with a Calibration ruler.

Complete files available here =>
3D_CalibrationRuler_v2.zip

Adrian

[Riffer]

Same problem here: drifting to right with every layer. The higher the objects gets the fewer the drift gets.

My first concern was about the slicer Software but I got the same drifting with Slic3r and with Simplify3d regardless of older or newest version of up3dtools.

Anything we could do about this topic?

[adrianbear]

Hi @MaikStohn ,
When you say this is a rounding error, is it because the gcode is received with relative movement values and during your translation to UPCode with relative movements your loosing precision (i.e. with rounding errors or data type conversions).
The result being at the end of each layer the extruder is not at the exact expected position before increasing the Z axis.

If this is the case would it be feasible to first run an absolute position conversion over the gcode so you know exactly where the extruder should be before the layer change.
Based on this you could either alter the up code conversion to work based off the absolute gcode positions instead of the relative positions or make a final position adjustment before the layer change based on the gcode end of layer absolute position.

Or do I have no idea what I am talking about?

Thanks
Adrian

[orthoa]

Sorry forgot to post more info, I've been busy. It was also set to 100% infill and as you can see from the picture this isn't the case. From memory when I was watching it print the first 10-15 layers did have 100% infill.

I can upload the FFF and Factory file if needed for some reason github isn't allowing me to upload ZIP files at the minute.

[adrianbear]

Hi @MaikStohn ,
Just thinking on my suggestion and also the "error correction" stuff you've been saying. None of this makes sense to me because we can decode the UPcode file back to gcode and it looks ok.
If there were errors (rounding or otherwise) shouldn't we see them in the reconverted gcode?
Adrian

[MaikStohn]

Hi,

the rounding is inside of the MCU. The UP does NOT take GCODE or absolute coordinates. It just wants periods of speeds for every motor.

Just a small example: The GCode instructs to go from step position X:0 Y:0 to X:10 Y: 3 with a speed of 2. This results in 5 segments for X: X+2, X+2, X+2, X+2, X+2
Since the Y movement must be at same level as X (Y can not arrive earlier or later then X finishes) this again results in 5 segments for Y: Y+0.6, Y+0.6, Y+0.6, Y+0.6, Y+0.6

You can see that X always is running 2 steps, while Y is going 0.6 steps per period.
The UP does have a fractional part inside to be able to handle fractional steps. Unfortunately this is done with a very imprecise fixed fraction of 9 bits (1/2^9 = 0.00195). So the resolution is limited to 0.00195 steps. In case one axis is doing a very fast movement while the other is doing a very slow move this limitation can exceed the precision and lead to a virtual step which is calculated but never executed.

Means: In total we instructed the machine to do 100 steps but in fact the machine did 99 only. Even the machine internal calculation is convinced it did 100 steps and that's why the error is not compensated when the layer change occurs which indeed uses the absolute coordinates.
==> Inside the machine was a rounding error which the machine itself also doesn't know.

The original UP software is doing a lot of crazy calculation to minimize this effect. It cuts precision prior calculation of the moves and also tries to limit segment size in order to minimize this kind of failures.
But the real problem is that there are rounding errors which my model just can not predict completely.

==> We must find out how to limit the fractional part to be less precise in order to avoid the rounding error from up machine software.

Maik

[Gitty-Hub]

I just had problems with these rounding errors too I think. Just came home to a Box full of spaghetti.
When I printed two of the same model today I had no issues, I saw no errors. But when I printed 7 or 8 of these at the same time all of them were askew/drifted and eventually knocked over by the print head.

[dfyx]

@MaikStohn with the smallest possible step being known, shouldn't it be possible to calculate the path at that precision with something like the Bresenham algorithm and then aggregate multiple of those micro-segments into larger segments? That should be possible without any rounding errors.

As for errors accumulating over multiple commands, that shouldn't be an issue either, as long as you do all calculations (including the variable that keeps the current position) in "micro-steps".

TL;DR: do everything with fixed point arithmetics with the same precision the machine uses internally.

[kscheff]

The main issue is that both x and y axis needs to move simultaneous at a certain speed in order to deposit the material at the correct position. Talking about Bresenham adresses not the problem, since we already reach the right endpoint, but with a certain fractional rest error. This fractional rest accumulates differently in the UP Firmware and in UP3D software. The goal is to keep this rest at a minimum, optimally below 1 micro step.

The issue Maik is fighting is to find a way to a) firmly understanding how the error accumulates in the Firmware and b) find a way to keep it under control (e.g. correction steps).

As Maik commented one way is to break a path in smaller segments, so that the segments can be chooses to reach the end point with a smaller factional error.

In earlier versions I analyzed and plotted the resulting error. Here I found that the error inside up3d calculation has a tendency to grow in a single direction ( but we don't know if the firmware sees it similarly). So another idea would be to distribute the error evenly so that the resulting error doesn't result in a drift. This means to take care of all rounding in the calculation. Next we wound need to understand if the error distributes differently by different geometries (eg Circles vs. Cubes in different angles) or different placements.

-Kai

Am 06.06.2016 um 10:18 schrieb dfyx [email protected]:

@MaikStohn with the smallest possible step being known, shouldn't it be possible to calculate the path at that precision with something like the Bresenham algorithm and then aggregate multiple of those micro-segments into larger segments? That should be possible without any rounding errors.

As for errors accumulating over multiple commands, that shouldn't be an issue either, as long as you do all calculations (including the variable that keeps the current position) in "micro-steps".

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[dfyx]

Okay, either I misunderstood the problem that Maik described or I'm just not very good at explaining my idea.

In the example above we would go from (0,0) to (10,3) which would be 10_2^9 = 5120 micro-steps in the x-direction and 3_2^9 = 1536 micro-steps in the y-direction. Dividing that into 5 equal segments would give us an error of 1 micro-step in the y-direction. In this case the solution is pretty easy, we can just add that one micro-step to any of the segments. (given that the transfer format allows us that kind of precision which I assume it does as the UP3D software can produce the right output)

It gets a little harder when we are off by more than one step. In that case, we can't just add all missing micro-steps to one of the segments as that could result in a slight but visible curve. Instead we need to distribute those corrections among the segments as equally as possible. Of course Bresenham is only one option to do that, a simpler one might also work.

Example:
Assume we want to go 1538 micro-steps instead of 1536. One good solution would be segments of 308, 307, 308, 307, 308 micro-steps.

[MaikStohn]

Hi,

to confuse you a bit more here a real world example for UP internal machine MCU:

If you accelerate, travel and decelerate in one direction and then do exactly the same in opposite direction you will have a difference of 1-5 steps depending on the fractional part of the step Bresenham.

But this is not the problem. The problem is that you sometimes do NOT have a missed step in your own and in MCU calculation (UP MCU reports the current position to be same as calculated). However it missed 1 step to execute. This is the problem.

Maik

[MaikStohn]

@dfyx
You don't tell UP to execute steps. You give a period, a frequency and a speed / acceleration. The period and frequency is shared for all 3 axis. So you always will have an error of some steps for at least 2 axis.
But this is not a problem. It can be compensated easily. Like mentioned above the problem is that some "magic" is going on inside of UP MCU which prevents some steps from happening which should have been executed. Even the UP MCU itself calculates this steps as executed and reports the new position. But as the print shows this steps are missed.

[MasterOfDesaster666]

Same problem with the Mini :( But i am not sure if this happened with older versions of up3dtranscode also...

Too bad no one was yet capable of hacking/cracking the machine to be open to 3rd-party software :(

[adrianbear]

@MaikStohn ,

This smells like a float data type precision issue to me.
You mentioned a fixed fraction of 9 bit precision (which is unusual in itself). It may be that the firmware expects a 9 bit precision data type and calculates cumulative values based on this but then rounds it (or drops precision bit) to only 8 bit precision when implementing actual moves.
Are you able to drop a bit (not round) from your precision values (i.e. force a 0 in the least significant fractional position) and I'll test again.

Thanks
Adrian

[Gitty-Hub]

I compared the models I mentioned earlier, so two models printed at once also drift. The more movements/models the more it drifts obviously.. But I think the previous transcode versions had less of this problem, I did not notice any drifting before 0.7.0. I do hope this can be fixed, I want to leave the Up software and focus on Simplify3D because of the freedom :-)

[kscheff]

@MaikStohn

As far as I understand the issue is related to the error summing up inside the UP firmware. So one of your previous comments says
that giving a move command in one direction and returning from there to the original position reports a different location.

Can’t we use this mechanism to figure out how the error sums up, I mean that generating some patterns and analyzing the results (e.g. in an spread sheet)
to see what happens. Next we could develop an error correction and test the result with the same patterns. This test could be carried out with no extrusion, or with no filament
loaded, so we don’t generate a mess in the printer. The focus would just be to make a series of known movements and record, compare the positions.

I think along the line to generate programmatically a series of fine straight back-and forth movements in x direction with different speeds and length.
Then we can repeat the similar pattern but in y-direction. Another test pattern would be to use a circle with different diameters and speeds. The test program
would then spit out the test sequence and reports back the position information on each sequence.

Then I also remember you said that the firmware reports a different location then the actual head position, here comes the question if the report might be wrong or the
position (or both) is wrong. Here again, we would need to develop a standard test pattern to print, which exhibits this possible failure.

-Kai

Am 10.06.2016 um 12:04 schrieb Gitty-Hub [email protected]:

I compared the models I mentioned earlier, so two models printed at once also drift. The more movements/models the more it drifts obviously.. But I think the previous transcode versions had less of this problem, I did not notice any drifting before 0.7.0. I do hope this can be fixed, I want to leave the Up software and focus on Simplify3D because of the freedom :-)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #31 (comment), or mute the thread https://github.com/notifications/unsubscribe/AIfahmKmurfCgOK7VoamMPemxQbnQBMPks5qKTaZgaJpZM4ImKCm.

[MaikStohn]

@kscheff

the error which is reported back I mentioned can be fixed easily (is already compensated). The problem is the error the machine is having when you instruct to drive 100 steps but is is doing 99 only but reporting back 100 been done.

You can see that the position is wrong... just look at the prints. I did some test runs (just x/y moves) and checked reported positions with instructed positions. All is 100% fine. The only problem is that the head is not where it is expected to be.

Maik

[kscheff]

@MaikStohn

OK, then we can focus on this behavior by generating some test pattern like:

Generate a pattern of x lines which consists of many segments with the same fractional error.
In fact this should generate a single straight line with a certain length.

Next we increase the y position by e.g 0.5 mm and start the next sequence.

some pseudo code like this:

y = 0
fractional = 0
lines = 100
for line = 1 to lines
segment_length = 1 + fractional/512
x = 0
for segment = 1 to 100
generate a segment x,y,segment_length
x += segment_length
next segment
y += 0.5
fractional += lines/512
next line

Could we see than where the step on the line end in x direction occurs?
Then we can narrow the range to figure out what type of rounding is happening.

-Kai

Am 10.06.2016 um 15:07 schrieb Maik Stohn [email protected]:

@kscheff https://github.com/kscheff
the error which is reported back I mentioned can be fixed easily (is already compensated). The problem is the error the machine is having when you instruct to drive 100 steps but is is doing 99 only but reporting back 100 been done.

You can see that the position is wrong... just look at the prints. I did some test runs (just x/y moves) and checked reported positions with instructed positions. All is 100% fine. The only problem is that the head is not where it is expected to be.

Maik

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #31 (comment), or mute the thread https://github.com/notifications/unsubscribe/AIfahnu09jK6fJR1qTOVA59dpPHJJCx0ks5qKWGlgaJpZM4ImKCm.

[MaikStohn]

@kscheff

1 step on UP mini is 1/854.0 mm = 0.00117 mm. So not sure how to measure a single missed step...
Right now I do experiments with the supplied test data but unfortunately always need to print it in order to see the "tilt".

Another idea I have in mind is to solder some wires to the step output pins and make a small electronics to count the real step pulses. Since the frequency can be very high (up to 1 MHz) it must be something powerful like a ARM mcu (e.g. STM32).

Maik

[kscheff]

@MaikStohn

Indeed that missed step is a tiny fraction, but somehow in the prints it is summing up to a recognizable amount.
So the idea is to use many segment in a straight line to sum it up. The previous example used 100 segments, so that might still be not enough.
We can increase these 854 segments per line, so we end up with 1 mm which should be recognizable.

As the 1MHz steps counting goes, it is difficult to catch these with a simple TTL uC input on the motor since these have quite some inductance. You
will see positive and negative swings. Before you jump into programming a uC and attaching to it, how about using an off the shelf frequency counter, usually they
have also a counting mode and a decent analog comparator to play around with a trigger level. Some Scopes have a counting mode as well. For reset you might
consider using the light on/off.

-Kai

Am 10.06.2016 um 21:41 schrieb Maik Stohn [email protected]:

@kscheff https://github.com/kscheff
1 step on UP mini is 1/854.0 mm = 0.00117 mm. So not sure how to measure a single missed step...
Right now I do experiments with the supplied test data but unfortunately always need to print it in order to see the "tilt".

Another idea I have in mind is to solder some wires to the step output pins and make a small electronics to count the real step pulses. Since the frequency can be very high (up to 1 MHz) it must be something powerful like a ARM mcu (e.g. STM32).

Maik

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #31 (comment), or mute the thread https://github.com/notifications/unsubscribe/AIfahr6u06tdH_UhCqoWX3RqXcnjb3oCks5qKb3sgaJpZM4ImKCm.

[adrianbear]

@MaikStohn, @kscheff,

Is there absolutely no way to extract the firmware and disassemble it?

Also if the UP software works around this issue we should be able to analyse the native UP code output to search for their pattern to work around the issue.

Can you compare a 3 or 4 layer circle output from up against the same from gcode transcoder. I'm willing to bet they simply reduce precision in the values they could send. I.e. 10.456 likely gets reduced to 10.450

I am still working on the assumption that this is not intentional by UP and there must be a simple programming reason for it.

Adrian

[kscheff]

Adrian,

I have already looked into these idea. So far we can see the following:

The UP slicer breaks up a straight line in many smaller segments. Especially the corners are kind of "rounded" with very tiny segments.

Next the maximum repeat count in each segment (I think it was the value p1) is limited to 500. Maik prefers here to use longer runs, since the planner doesn't split each segment into smaller pieces.

I also thought how to implement this break ups, but I came to the conclusion that this would need to know the geometry of the figure, so the small segment can follow a path. Reconstructing these from gcode is a bit of a pain, since this would require some kind of look ahead to identify the corner angle. Next these small segments must be puzzled together in a way that x/y factional parts are minimized.

-Kai

Am 11.06.2016 um 01:10 schrieb Adrian Bear [email protected]:

@MaikStohn, @kscheff,

Is there absolutely no way to extract the firmware and disassemble it?

Also if the UP software works around this issue we should be able to analyse the native UP code output to search for their pattern to work around the issue.

Can you compare a 3 or 4 layer circle output from up against the same from gcode transcoder. I'm willing to bet they simply reduce precision in the values they could send. I.e. 10.456 likely gets reduced to 10.450

I am still working on the assumption that this is not intentional by UP and there must be a simple programming reason for it.

Adrian

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[kscheff]

@MaikStohn
There is another idea crossing my mind: P2 is the period for the acceleration part and P1 the repeat counter. The UP firmware needs to calculate the required steps for the internal motor drive timer based on P2 timing period. These two timing periods differ from each other. So one implementation result could be that a remainder for the last internal timing period is dropped and the motor does not execute these steps. So we could search if the original software uses some discrete P2 timing steps, another method would be t figure out what frequency the internal UP firmware stepper interrupt is relying on.

[Riffer]

No solution to this issue and the project died?

[kscheff]

@Riffer I just got a prototype Cetus3D which is based on the same control concept than the other Tiertime printers. The steppers of this printer run with 160 steps/mm, compared to 854 on the UP mini. So the resulting error is more prevalent on the prints see #39 for more details.

So I am back to square one to identify the rounding issue.
@MaikStohn is silent for the last months, not sure where he is up to
@adrianbear has nothing to test print
@dfyx seems to be monitoring....

[kscheff]

This issue is probably the same than #39 and should be fixed with #40.

[dfyx]

My guess is that @MaikStohn has abandoned this repository for now (I haven't seen any public activity from him on GitHub or his blog). I think the best course of action would be to open an "UP3D" GitHub organization, fork this repository over there and invite him. This way, @kscheff can merge any features and bugfixes himself.

[kscheff]

@dfyx @MaikStohn seems to be absent for a while now... creating a new organization and forking would mean we loose the continues integration features of travis, at least until this is established for a new repository. Myself I use mainly OS X, so no testing on Win or Linux systems.

[orthoa]

I can do some testing if needed for win system.

I've actually been testing a custom MCU for the UP! Machines that is
working great.

On Saturday, 24 September 2016, kscheff [email protected] wrote:

@dfyx https://github.com/dfyx @MaikStohn https://github.com/MaikStohn
seems to be absent for a while now... creating a new organization and
forking would mean we loose the continues integration features of travis,
at least until this is established for a new repository. Myself I use
mainly OS X, so no testing on Win or Linux systems.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ASp3Jigm3UgGF6TbARehTOCdBb9gD2ZWks5qs_v1gaJpZM4ImKCm
.

Thomas Leahy

Unit 3 / 121 Newmarket Rd
Windsor QLD 4030

1800 730 552

[orthoa]

@kscheff https://github.com/kscheff Do you already have a Cetus then? How
easy do you think it would be too add a heated bed?

On Saturday, 24 September 2016, Thomas Leahy [email protected]
wrote:

I can do some testing if needed for win system.

I've actually been testing a custom MCU for the UP! Machines that is
working great.

On Saturday, 24 September 2016, kscheff <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

@dfyx https://github.com/dfyx @MaikStohn https://github.com/MaikStohn
seems to be absent for a while now... creating a new organization and
forking would mean we loose the continues integration features of travis,
at least until this is established for a new repository. Myself I use
mainly OS X, so no testing on Win or Linux systems.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ASp3Jigm3UgGF6TbARehTOCdBb9gD2ZWks5qs_v1gaJpZM4ImKCm
.

Thomas Leahy

Unit 3 / 121 Newmarket Rd
Windsor QLD 4030

1800 730 552

Thomas Leahy

Unit 3 / 121 Newmarket Rd
Windsor QLD 4030

1800 730 552

[kscheff]

@orthoa I am just working on getting a fork working on the Travis CI, so the builds for Linux, OS X, Windows run automatically and should be available later for testing here https://github.com/UP3D-gcode/UP3D

I am just fighting to setup the api key access token...

Yes, I have an Cetus prototype on my desk, so I can play around with some software. I can't comment further on it.

[orthoa]

Sounds good I will give it a test when can.

Also if you could send me a message when you are allowed to talk about it
that would be great. We are really interested in them as they are perfect
for our application.

On Saturday, 24 September 2016, kscheff [email protected] wrote:

@orthoa https://github.com/orthoa I am just working on getting a fork
working on the Travis CI, so the builds for Linux, OS X, Windows run
automatically and should be available later for testing here
https://github.com/UP3D-gcode/UP3D

I am just fighting to setup the api key access token...

Yes, I have an Cetus prototype on my desk, so I can play around with some
software. I can't comment further on it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ASp3Jng7lNCLrRiiXJ-YI5rJAqJkikTjks5qtDRCgaJpZM4ImKCm
.

Thomas Leahy

Unit 3 / 121 Newmarket Rd
Windsor QLD 4030

1800 730 552

[kscheff]

So I managed to get the binary files automatically build with the #40 fix included. Please visit this page https://github.com/UP3D-gcode/UP3D/releases

[Gitty-Hub]

Are these issues fixed now?

[kscheff]

@Gitty-Hub this should have been fixed with the #40. So far there is no feedback from the original owners. So we might just close the this issue here (Maik?).

[orthoa]

It isn't fix and we are still having the same problems.

…

On Mon, Dec 5, 2016 at 6:06 AM, kscheff ***@***.***> wrote: @Gitty-Hub <https://github.com/Gitty-Hub> this should have been fixed with the #40 <#40>. So far there is no feedback from the original owners. So we might just close the this issue here (Maik?). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASp3Jhl7ap8Y4A20xP20v8avUMlQHKRTks5rEvMjgaJpZM4ImKCm> .

-- Thomas Leahy Unit 3 / 121 Newmarket Rd Windsor QLD 4030 1800 730 552

[kscheff]

Hm, I don't see this issue on the UP mini nor the Cetus printer, I don't have a UP Box to test with.

Trying to catch up here: @orthoa are you using UP Box or do you have access to UP mini as well? Next I try to understand if the 3-5 degree angle depend on the X/Y content or only at the height (number of layers) of the object: e.g. does a cylinder or cube with the same base width and height(and layer height) result in the same lean angle? Another option to identify the issue would be to play with different infill % on the same object.

Some more questions:
Is the 3-5 degree angle one specific angle or is it always different, e.g. on the same object with same settings different angles?
Do you use Z-lift setting in either Slic3r or S3D and is it depended on the Z-lift setting?

What I try to differentiate with this is: if it is still a rounding issue not being able to track the position correctly, then this must be content dependent (so how many rounding issues are summed up in a single layer). If it is not content depended, it can't be a rounding issue based on the XY layer movements. When it is a static fixed lean angle, it should solely depended on the number of layers printed (height / layer height) and we might consider a fixed offset per layer to compensate (if we can't find any other source of trouble).

-Kai

[Gitty-Hub]

I tried a cylinder and that does not look so bad. But now I'm printing the calibration ruler from this thread and I can see already the structures are printed with an angle to the left. So I don't know why sometimes this happens and sometimes not, the ruler is straight and doesn't have too much round areas like the cylinder. I measurd the cylinder and the outer diameter is about 24.75 mm where it should be 25 mm.

[orthoa]

Cylinders and Cubes are fine but as soon as you print anything slightly complex it starts getting the 3-5deg tilt. (Note that it use to also print on a angle with cubes but the newer version has fixed it) Number of layers isn't a factor it starts to print on a angle almost strait away.

…

On Sun, Dec 11, 2016 at 3:57 AM, Gitty-Hub ***@***.***> wrote: I tried a cylinder and that does not look so bad. But now I'm printing the calibration ruler from this thread and I can see already the structures are printed with an angle to the left. So I don't know why sometimes this happens and sometimes not, the ruler is straight and doesn't have too much round areas like the cylinder. I measurd the cylinder and the outer diameter is about 24.75 mm where it should be 25 mm. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASp3JuKt5GaenzdGrF14_FlfytFQgSrJks5rGr3ugaJpZM4ImKCm> .

-- Thomas Leahy Unit 3 / 121 Newmarket Rd Windsor QLD 4030 1800 730 552

[kscheff]

Hm, I am printing with the same transcoder on an UP Mini and on an Cetus3D fairly complex things and I cannot see any of the reported issues. So this seems to be UP Box specific, but the only difference in the code are some defaults for e.g. steps per mm in X,Y,Z ... so I wonder how to further debug this issue.

[kscheff]

Shit! I have to agree, now I printed an object with this issue on an UP mini sliced with S3D... So at least I can reproduce the issue.

[Gitty-Hub]

I see the project has been forked by somebody from Tiertime.. And at Cetus kickstarter there's a comment that Cetus Studio will have gcode (can't find it in the software yet).
Is Tiertime also working on this project, making their own gcode thing or did they just download this code?
I have seen that newer Up printers will only work with Up Studio so gcode is needed more than ever, I don't like Up Studio.

I hope that the issues can be fixed :-)

[kscheff]

@Gitty-Hub I am not aware that Tiertime uses this for their GC transcoder. I doubt it since they have other professional printers with such support for quite some time.

The idea behind open source projects is also about contribution. The authors are not paid for this work, it is our enthusiasm driving this. So far we are stuck with this issue, so some help would be greatly appreciated - hoping alone won't fix it.

If you can take a look yourself or you know others with high interest, may help to move forward with this.

[Gitty-Hub]

Well, they now seem to have some issues with it in Cetus software - errors in size and direction that sounds a bit like the last rounding errors in this project. And they also call it a transcoder which is a coincidense. I think it would be quite funny if they use this work to offer gcode to their printers.
Anyway, I would like to contribute and I tried the software multiple times however I am not able to code sadly.. If I still can help in any way please let me know. I really appreciate all the hard work done by everybody here. I have asked a bit around if people could help out or know people that can code.

[kscheff]

This issue seems not to be related to the rounding issue. Rounding issues on the movement would be highly dependent on the content printed. So far this seems not to be related in such a way. It would be helpful to analyse the error in more detail, e.g. at which point it exactly deviates. This may be visualized by capturing the position data during print and comparing to the original. Helping is not necessarily a coding issue, since the program is doing what we want, but the printer is somehow not understanding exactly what we believe to tell it...

…

-Kai

[orthoa]

But how can they be having problems with the Cetus g-code software surely they know how their printers are working.

…

On Wed, Jan 18, 2017 at 12:26 AM, kscheff ***@***.***> wrote: This issue seems not to be related to the rounding issue. Rounding issues on the movement would be highly dependent on the content printed. So far this seems not to be related in such a way. It would be helpful to analyse the error in more detail, e.g. at which point it exactly deviates. This may be visualized by capturing the position data during print and comparing to the original. Helping is not necessarily a coding issue, since the program is doing what we want, but the printer is somehow not understanding exactly what we believe to tell it... -Kai — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASp3Jus3VLgO2AfTVS1FPC_k3JB0-EReks5rTM-mgaJpZM4ImKCm> .

-- Thomas Leahy Unit 3 / 121 Newmarket Rd Windsor QLD 4030 1800 730 552

[Gitty-Hub]

Seems the Cetus Studio has gcode working.. Is there any progress and hope for this tool here? I would love to print gcode well on my Up Box too. Last thing I read was there were some new developments and discoveries by Maik..

[smonson78]

Hi, I just began using this utility today with my Up Plus 2 and this X-axis tilt issue is immediately apparent. Did anyone ever find the underlying cause?

[smonson78]

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]

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]

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?