First layer with almost no extrusion, second layer is normal with X3GWriter

[juan090988]

Dear Ghostkeeper,

I have an Mbot Cube dual, and I'm trying to create the .def.json configuration file for this printer. I took the "ZYYX Agile.def.json" configuration file as basis and did a few modifications (I have already removed "machine_x3g_variant": "z" line). Now the X Y Z dimensions seems to work fine but there is still one problem. I'm using the X3GWriter 1.1.12 version and when I print something, the first layer has almost no extruded material, while for the the second everything is OK.

I have checked this is not a hardware issue by using the "ZYYX Agile.def.json" as config file. When i do this everything works fine except the X Y steps per mm, which are not calibrated for my printer and therefore my printing are 5% smaller.

I have also checked that the data needed for the "X3GWriter.py" is in my .def.json file.

I set the default values for all cura parameters in order to verify this was not the issue.

I have also compared the gcodes generated using both for both "ZYYX Agile.def.json" and my config file versions and everything seems coherent.

I'm forgetting something? Do you have any suggestion? I can share with you my .def.json configuration file in case you want to look at it.

EDIT: I have converted my gcode using GPX converter and everything works fine, maybe there are some parameters that are not send/ transmitted with X3GWriter?

Best regards,

Juan090988

[Ghostkeeper]

The ZYYX Agile printer uses the Makerbot g-code flavour, so X3GWriter adds -g to the command. It also uses the "ZYYX - Single Extruder" machine profile, which adds -m z to the command. As a result, I'm getting the following command to GPX, as shown in my Cura log file:

gpx -g -p -m z /tmp/tmpdhymz2_4 /tmp/tmpfrtejei6

The temp files are generated by X3GWriter as temporary storage locations for the g-code and the X3G file until writing is complete.

What command have you been using, when you used the GPX converter yourself manually?

If you remove the machine_x3g_variant line, the X3GWriter will generate a config file using the Cura settings in your printer definition to specialise the X3G settings that Cura has a setting for, to make sure we pass the correct Steps Per MM and such to X3G. Most X3G settings are overridden then, but not all of them since Cura has no setting for packing density, for instance.

This is the config file I'm getting for the default XYYZ Agile printer profile, after removing that line:

[printer]
ditto_printing = 0
build_progress = 1
packing_density = 1.0
recalculate_5d = 1
nominal_filament_diameter = 1.75
gcode_flavor = makerbot
build_platform_temperature = 0

[x]
max_feedrate = 17987547480000
home_feedrate = 4800
steps_per_mm = 88.888889
endstop = 1

[y]
max_feedrate = 17987547480000
home_feedrate = 4800
steps_per_mm = 88.888889
endstop = 1

[z]
max_feedrate = 17987547480000
home_feedrate = 17987547480000
steps_per_mm = 400
endstop = 0

[a]
max_feedrate = 17987547480000
steps_per_mm = 96.27520187033366
motor_steps = 3024.5746691871454
has_heated_build_platform = 0

[right]
active_temperature = 210
standby_temperature = 200
build_platform_temperature = 0
actual_filament_diameter = 1.75
packing_density = 1.0

[machine]
nominal_filament_diameter = 1.75
packing_density = 1.0
nozzle_diameter = 0.4
extruder_count = 1
timeout = 20

[juan090988]

Dear Ghostkeeper,

Thank you very much for your answer.

What command have you been using, when you used the GPX converter yourself manually?

First I sliced my .stl file, and then I exported the Gcode (using cura). Then I used the GPXUi to convert my Gcode to X3G. I modified the steps per mm in the GPXUi, (although this was useless because the prints were also 5% smaller, I don't know the reason) and the printer was actually printing normally, with normal I mean the extruded material was normal. Now that I think about it... this is not OK because I guess I'm never using my .def.json file. (assuming the .def.json config file doesn't affect the Gcode generation in cura)

This is the config file I'm getting for the default XYYZ Agile printer profile, after removing that line:

Could it be possible to have more details about where to find or how to save this .ini config file ? Indeed this could be very helpful to debug my .def.json config file.

Most X3G settings are overridden then, but not all of them since Cura has no setting for packing density, for instance.

I think the packing density is set to 1 in your script when the line machine_x3g_variant is deleted , should I include this packing density parameter in my .def.json config file?

Maybe I'm wrong from the beginning; my printer has a clone motherboard of a Makerbot (mightyboard) with an ATMEGA 1280 microprocessor. My understanding is the .X3G binary file is a sort of instructions in machine language for the stepper motors and extruders, and my assumption was that the steps per mm could be changed in cura, so when the gcode instructions are converted to .X3G the conversion is performed using the correct steps per mm that were set in cura (.def.json config file). But maybe I'm wrong and these step per mm needs to be changed in the firmware of the printer?

Best regards,

Juan090988

[Ghostkeeper]

Could it be possible to have more details about where to find or how to save this .ini config file ? Indeed this could be very helpful to debug my .def.json config file.

Note that no config file is created if you have the machine_x3g_variant metadata. But if you don't, it creates one in the temp folder of your computer with a random file name. Where exactly that temp folder is according to Python, and what random file name was generated, is put in Cura's log file. You can read the file after saving is complete, too. Just open it with a text editor (since it doesn't get a file name extension).

But maybe I'm wrong and these step per mm needs to be changed in the firmware of the printer?

It's my understanding that they need to match in the printer firmware with whatever you fill in with Cura though. I must say that I'm not sure what the X3G file format even contains. Perhaps it only needs the steps per mm in order to round properly and get correct timings?

[juan090988]

Dear Ghostkeeper, thanks for your answer,

In deed, a have verified that the correct parameters are generated using my def.json config file :

[printer]
ditto_printing = 0
build_progress = 1
packing_density = 1.0
recalculate_5d = 1
nominal_filament_diameter = 1.75
gcode_flavor = makerbot
build_platform_temperature = 60

[x]
max_feedrate = 747000
home_feedrate = 4800
steps_per_mm = 95.09061
endstop = 1

[y]
max_feedrate = 747000
home_feedrate = 4800
steps_per_mm = 94.139704
endstop = 1

[z]
max_feedrate = 70200
home_feedrate = 70200
steps_per_mm = 402.01005
endstop = 0

[a]
max_feedrate = 300000
steps_per_mm = 96.27520187033366
motor_steps = 3200.0
has_heated_build_platform = 0

[right]
active_temperature = 205
standby_temperature = 175
build_platform_temperature = 60
actual_filament_diameter = 1.75
packing_density = 1.0

[b]
max_feedrate = 300000
steps_per_mm = 96.27520187033366
motor_steps = 3200.0
has_heated_build_platform = 0

[left]
active_temperature = 200
standby_temperature = 175
build_platform_temperature = 60
actual_filament_diameter = 1.75
packing_density = 1.0

[machine]
nominal_filament_diameter = 1.75
packing_density = 1.0
nozzle_diameter = 0.4
extruder_count = 2
timeout = 20

The X an Y dimensions of the printing are now OK, but still i got the extruded material which becomes very irregular when using my config file... any more thoughts?

[Ghostkeeper]

Then something must be up with the [a] or [b] header. Or just the print settings?

MBot has a Marlin repository with some modifications on their Github page, but it doesn't look like they adjusted the config file. It would be a little weird anyway since Marlin can just read g-code and wouldn't need X3G. They also have a fork of Sailfish but made no modifications there, so that can't be right either (and it's ancient).

That steps_per_mm value seems like it's calculated from theory. It's almost exactly 400²/(23²*pi), and 400 is a common number of steps per revolution for stepper motors. 23 could be a gear ratio or gear diameter somewhere. I can't imagine that this calculation is wrong since it's objective theory, not a measurement.

Is it producing the wrong temperatures maybe?