Experimental firmware release 1.17c+1
-
Retraction issue is a bit odd, are you doing firmware retraction ? I've not tried firmware retraction yet , I've done multi hour prints with 1.17 c+1 with zero issues. Loaded c+2 and will be trying that out tonight.
Jeff
-
@(In)Sanity:
Retraction issue is a bit odd, are you doing firmware retraction ? I've not tried firmware retraction yet , I've done multi hour prints with 1.17 c+1 with zero issues. Loaded c+2 and will be trying that out tonight.
Jeff
I have C+2 on my kossel and it's working fine, I had it on my rostock and it was giving me issues. I flashed back to 1.17c and with the same GCODE i was trying to print on c+2 worked fine on 1.17c.
They are both Duet Wifi's with web 1.14a.
I don't know why its working on 1, and not the other.
-
I just found a bug in 1.17c+1 and +2 that affects printing when absolute extruder coordinates are used. Does this explain the problem you are seeing?
-
I just found a bug in 1.17c+1 and +2 that affects printing when absolute extruder coordinates are used. Does this explain the problem you are seeing?
Well that explains why it works perfect for me, I'm using relative extruder positions as suggested via the wiki.
Jeff
-
Version 1.17d is now released.
-
Problem solved, thanks David.
-
Decided to do some work in the area of arcs (G2 G3) and I'm finding that the motion is not at all correct. I've got a program called jViewer which allows me to preview gcode moves. It is showing the arc moves as I was intending however if I let 1.18beta1 run this code the motion is not remotely like arcs on either the G2 or G3 arc commands. These are the test arcs which produce two concentric circles made up of a few short lines and arcs to mix it up a bit. Radius is around 10.3mm.
G90
;outer circle
G1 Z10.000 F2000
G1 X105.000 Y105.000 F6000
G1 X106.650 Y115.800
G1 X105.752 Y115.761 F515
G1 X104.861 Y115.643
G3 X96.350 Y105.500 I1.788 J-10.149
G1 X96.389 Y104.602
G1 X96.507 Y103.711
G3 X116.950 Y105.500 I10.146 J1.790
G1 X116.911 Y106.398
G1 X116.793 Y107.289
G3 X106.650 Y115.800 I-10.149 J-1.788
;inner circle
G1 X106.424 Y115.698 F6000
G1 X107.326 Y115.678 F515
G1 X108.223 Y115.578
G2 X116.850 Y105.500 I-1.575 J-10.081
G1 X116.810 Y104.599
G1 X116.691 Y103.704
G2 X96.460 Y105.049 I-10.038 J1.796
G1 X96.460 Y105.951
G1 X96.540 Y106.850
G2 X106.424 Y115.698 I10.113 J-1.352Hopefully you can spot if it is either an error in the g-code or an error interpreting the arc calls?
I've also almost completed some code to take regular 3d print gcode, locate curves based on the perpendicular line intersections (centre of arc) of the short lines and turn them into either a G2 or G3 arc call. The g-code above is a section of the output from the code which replaced about 200 small moves to make up a curve.
Hoping the end result will be a very smooth printed curved surface rather than all the flat edges you typically get from slicers/.STL files?
Also downloaded another g-code simulator from http://www.cncedit.com/Basicviewer/ and it also renders the arcs as expected.
-
And another very basic test -
Arc from 0,0 to 10,10 CW with a radius of 10 (90 deg arc) should be -
G1 X0 Y0 F500 (start of arc)
G2 X10 Y10 I10 J0 (I = start X + 10, J = start Y + 0 as pivot point of arc)However when this runs on 1.18beta3 it goes straight up, loops over CW about 180 and stops at 10,10
Scaled up -
G1 X100 Y100 F500
G2 X150 Y150 I50 J0The motion ends up going directly up to Y150 and proceed to 50mm radius arc up and over to the right 180 to X200 Y150 and then does a line back to X150 Y150. So it seems to be placing the midpoint of the arc at X150 Y150, starting the arc at X100 Y150 and finishing at X200 Y150, followed by a line back to X150, Y150. Not sure how this behaviour matches up with this description from RepRapWiki G-codes on the web? -
Xnnn The position to move to on the X axis
Ynnn The position to move to on the Y axis
Innn The point in X space from the current X position to maintain a constant distance from
Jnnn The point in Y space from the current Y position to maintain a constant distance from -
Yes, it's definitely wrong. Right now I am looking at the behaviour of G2 I0 J20 X0 Y40 starting from 0,0 which should describe a semicircle. I'm looking into it.
-
Found the problem, will be fixed in beta 4. An unreleased build including the fix is at https://dl.dropboxusercontent.com/u/19369680/DuetWiFiFirmware.bin.
-
Awesome David! Will give the newer FW a go now and let you know if all is good after I've tested a bunch of CW/CCW variations.
….
After some testing it looks like we are on a winner. I may have mentioned that you probably need tests to make sure an arc does not drive the head out of the bed limits however in reality the part won't be outside of the bed limits in the first place. It's only when a rubbish arc call in the gcode can cause this. Up to you if you want to include that safeguard in the code?
Thanks again for making this work. My code to take visibly faceted curves on an object and smooth them out by replacing all the short lines with one arc call is coming along nicely. Here is a good example of a before and after using the code -
Still more work to do with complex objects before it is ready.
