@fcwilt +1 from me but at the moment {} brackets are used for putting variables from object model into gcode commands.
Anyway i think that more similiar the conditional code is to c++ and less to python is for me a big yes....i have no problem with this type of language but i hate having indentation to determine the loop/function start/end.
I would give a function its proper "ender" so for example "loop" for while loop and so on.
@bot You might be interested spending 30 minutes watching this: https://youtu.be/aVwxzDHniEw . I enjoyed it a lot!
At my eyes it seems that with so low jerk values the printhead is stopping at every STL triangle and the extruder is overextruding there due to low speed and higher temperature on the already layed plastic. I would try to increase the jerk and print speed. These result are impossibile to be caused but too high jerk. You can clearely see the mesh triangles and still the model seems to be really low on poly count.
Just my 2 cents.
Note: My jerk is at 900 in a medium size corexy with directdrive extruder so i think your values are really too low also with taking account of a heavy toolhead.
So, i was so dumb that i loaded a wrong filament profile on prusa slicer. It was the same PLA but the wrong color. That particular color is 1.8mm in diameter instead of 1.75. Switched to the correct profile and everything went ok. 
@fcwilt i think that they don't get them to work "fine" but usable...but i understand them, they are like me: never surrender! 
Delta are really pleasant to look at and really neat as aesthetic but i would never recommend one to someone that is not skilled in 3d printing! There is so much to learn and i have lose count years ago on the hours i've spent with this printer. I still hope that with a duet better hardware and firmware i'll manage to get it printing consistently. Tomorrow i'm going to recheck all the joints and mechanics in general...still sure that the problem is there, i hope to get at least the bed at around +-0.1mm at the end.
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.4.6 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2023-07-21 14:08:28
Duet Web Control 3.4.6
@alankilian i used to have a V2 and always seen that problem. The real problem (for Delta) is that is really difficult to make the effector to stay flat with the bed surface independently from the direction it is travelling. If you look close when printing, the effector would probably tilt a little bit when switching direction. Also a very little tilt could lead to this because the nozzle is far from the center of the rotation.
So this shows up when a line is lay down in +X direction and the next one in -X direction from example.
I left delta because they need to be really rigid to work properly and seemecnc's one are not so good at this (mine was made in wood so it was the worst case).
That's normal because we print "sliced" stl. The circle resolution is limited on Z axis to your layer height so it will be always print as an oval instead of a circle. That should not happed if printed on the XY plane. On that plane usally you'll get smaller circle than the design caused by stl resoultion (triangle counts) and also for plastic being overextruded on the inside of a circular movement.
Here's a trick to compensate for this problem at design: https://re3d.zendesk.com/hc/en-us/community/posts/360057694271-Printing-the-Most-Circular-Circle-along-the-Z-axis
@fcwilt i would try using the marlin K-factor Calibration Pattern. Need only some find/replace on the generated gcode because it uses the marlin language.
On resume.g add this line at the start:
G1 R1 Z5 F6000
Change F6000 with your move speed. This wil first go 5mm above the position of the last print move before pause occurs.
@Sindarius any news on that? In the meantime i moved my script to inkscape that has advanced scripting functionality and i can convert all the curves to lines so I don't have issues.
@Sindarius said in G-code Viewer G2/G3 arc preview:
@MikeS I'll need to take a deeper look into what is going on with the viewer but it is upset with the U and V params. If you remove them the rendered matches NCViewer.
I can confirm that code without U and V axis is previewing fine. I attach a more elaborated g-code with more arcs that works well with only X and Y but causes a lot of problems for the preview if U and V are present. I hope this can help you troubleshoot the problem and test a future fix. Unfortunately arcs are not so common on current slicers.
X and Y only
Sofia 2Axis.g
X,Y,U and V
Sofia 4Axis.g
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.4.6 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2023-07-21 14:08:28
Duet Web Control 3.4.6
@Sindarius nice! When i get back from work i'll try to export some gcodes without the u and v axes. I'll get back with the results.
@MJLew thank you for the feedback. The second image is the same gcode as posted previewed in dwc. I saw the same behaviour with other tests when g2 and g3 are used. The arcs does not always start from the correct point and linear movement are shown.
I tried launching "print" without motors connected and the extruder in the simulation seems to follow the correct path altought it is difficult to reliably say it because arc are not previewed. However these added lines are not followed for sure so i really think that it is the viewer that is not showing the correct path or my codes are somewhat correctly iterpreted by duet firmware and ncviewer but not from the preview.
Hi all,
i'm facing some issues in previewing own made g-code for a cnc foam cutting machine i'm making.
Machine is made of 4 axis named X,Y,U,V. X is right X carriage, Y is right Y carriage, U is X left carriage and V is left Y carriage. Between the carriage there is a hotwire that i use for cutting foam.
I've written a small Autocad macro for outputting custom G-Code from a closed polyline to allow machine control. Since now i've used https://ncviewer.com/ for checking the output g-code and bugfixing the macro.
Now i've tried uploading a sample code to DWC and preview it. The result is different from what i would have expected and from what the ncviewer is showing. Anyone could replicate it? i'm doing something wrong? X Y U V and I,J values seems to be correct checking them against cad drawing.
PS: i didn't run the code on the machine so i still don't now if this is only related to the preview or to the duet motion too.
I attach here the result and the gcode:
Gcode:
G0 Y7.67669351816836 V7.67669351816836
G1 X10.460086722869 Y7.67669351816836 U10.460086722869 V7.67669351816836
G2 X111.312729233058 Y56.8157257089499 U111.312729233058 V56.8157257089499 I83.5083390409037 J-43.3278104191889
G2 X103.316129299667 Y28.9066637370007 U103.316129299667 V28.9066637370007 I19.773679663431 J-20.7657599308204
G1 X104.906216011594 Y47.7466616126872 U104.906216011594 V47.7466616126872
G1 X66.0782304671486 Y39.7601877983511 U66.0782304671486 V39.7601877983511
G1 X78.6102154332631 Y24.0166143731538 U78.6102154332631 V24.0166143731538
G1 X101.406493263683 Y11.6125868744677 U101.406493263683 V11.6125868744677
G1 X57.365517020264 Y7.55742399224854 U57.365517020264 V7.55742399224854
G1 X49.3689168105043 Y22.2275719838839 U49.3689168105043 V22.2275719838839
G1 X25.0210598390317 Y9.22719695550413 U25.0210598390317 V9.22719695550413
G1 X10.460086722869 Y7.67669351816836 U10.460086722869 V7.67669351816836
G1 X0 U0
G0 Y0 V0
NCViewer preview:
DWC Preview:
@bot You might be interested spending 30 minutes watching this: https://youtu.be/aVwxzDHniEw . I enjoyed it a lot!
@ccs86 I also noticed that when IS is enabled i have to almost double my PA: 0.03 to 0.05 to get the same results. Probably IS is really more effective on sharp corners, but also it introduces some variations to acceleration that alters the tuning we used to have since last 3.3 version.
@dc42 just had 2 hours to play with a VM and managed to compile the source.
On the current source i can read correct data from X and Y axes (both together or alone) but Z axis is always reading -1.9995 as value. Also X Values is near -2 and it seems not correct to me. Shouldn't X and Y be near 0 and Z to -1 with a reading without moves?
UPDATE:
So i've looked at the changes you made in the latest version and came up with this fix:
I am not a programmer, but i've tested it and it seems that it has fixed it. Can you confirm?Maybe it's only another error that fixes my particular issue 
Nevermind all! I've looked more at C++ language and understood that in the for loop ++i has the same behaviour of i++ so that was not the fix. However now it seems to be working fine. I'll do more tests but it seems that there was something wrong with the accelerometers itself, returning wrong data...
@jay_s_uk Thank you, i think the documentation need to be updated then because it says to use CoreNG.
Also CRC32APPENDER need to be copied from rrf tools folder to one of those inculded in PATH to get full compilation.