Can this plugin be optimized for Weistek Ideawerk WT150?

[gunplar]

I have a Chinese printer with the name Weistek Ideawerk WT150, with a rather unusual Z axis setting: the print bed's default position is max Z range and it moves up to position 0, where the nozzle is, when printing. After looking through some German forums, I assume that it uses Sailfish firmware v7.3. The software from the manufacturer is not open source, and at the start of the gcodes they often have:

G162 Z F500 ;home max Z, or drop the bed to the bottom G161 Y X F2500; home min X and Y G92 X-75 Y-75 Z142.3 A0 B0; set current position, so that <0,0,0> is at the center of the bed and the nozzle touches the bed G1 X-75.0 Y-75.0 Z10.0 F2500 E0.0; move the bed up near the nozzle

This only works when it is directly connected to my PC and I use the manufacturer's software, which sends the x3g file directly to the printer and I have no way to access it. When using this plugin, the X and Y positions only change slightly, and the Z position only changes halfway, and everything happens at an extremely slow pace (increasing the feedrate won't help). I have also tried using ReplicatorG to translate this gcode into x3g and it works but results in a different (but wrong) movement. So I wonder, do different x3g writers work differently? Does anyone have the same printer and encounter the same problem?

[Ghostkeeper]

Yes, different printers work differently when given the same X3G file.

a rather unusual Z axis setting: the print bed's default position is max Z range and it moves up to position 0, where the nozzle is, when printing.

We have a solution for this since Cura 3.3 and X3GWriter 3.3: In the printer definition file you can set the machine_endstop_positive_direction_z to true. It should then home towards positive Z.

When using this plugin, the X and Y positions only change slightly, and the Z position only changes halfway, and everything happens at an extremely slow pace (increasing the feedrate won't help).

This makes me think that the X3GWriter uses the wrong steps per mm for your printer as well. Try increasing the machine_steps_per_mm_x, machine_steps_per_mm_y and machine_steps_per_mm_z settings in your printer definition.

And if you have nice values for your printer, I'd love to hear them so that we can add them to Cura :)

[gunplar]

Thanks for your suggestion Ghostkeeper 😄 I have tried searching various resources folder, but I can only find the .cfg file of my custom FDM Ideawerk printer. It does not contain steps per mm settings, should I add those? Or should I create a whole new .def file?

[gunplar]

Try increasing the machine_steps_per_mm_x, machine_steps_per_mm_y and machine_steps_per_mm_z settings in your printer definition.

I found out the steps per mm for X and Y to be around 492, but still cannot find the right value for Z. I have tried the rang from 50 to 400000 but it still won't make a difference. Maybe there is another reason to the slow movement beside this setting?

[Ghostkeeper]

I have tried the rang from 50 to 400000 but it still won't make a difference.

That should make a difference! Maybe that's a bug in X3GWriter or GPX then.

[Ghostkeeper]

I found no difference between how Z is handled and how X and Y are handled both in this plug-in and in the GPX source code. It seems like it should work fine. I wonder how it would work via Octoprint...

[gunplar]

Unfortunately I'm not very familiar with Rasberry Pi or this Octoprint. But as far as I see, if they say it can work on Windows then I will give it a try. I use ReplicatorG to parse the gcode from Cura and it works fine. Is the ReplicatorG open source? Can we see the difference between its X3G translator and yours?

[gunplar]

Some weird things happened:

1. I left the printer alone for 2 weeks and when I come back the steps per mm settings should now be around 72 to work instead of 492 like before.
2. The homing speed of one axis depends on the steps per mm settings of other axes. I chose these settings for the Cura description file: machine_steps_per_mm_x = 72 machine_steps_per_mm_y = 492 Then the G-code command is: G161 X Y F1000 ;home x and y G92 X0 Y0 Z0 A0 B0 ;set coordinate G1 X50 F600 ;move x to 50mm position Things worked smoothly. Obviously if it was for Y it would go out of its max range pretty fast. But then I fixed the settings: machine_steps_per_mm_x = 72 machine_steps_per_mm_y = 72 The homing of both axes was way too slow and even got timeout before it reached zero. The G1 command worked normally though for both axes. Have you encountered this before?

[Ghostkeeper]

Sorry for the long delay.

No, I haven't encountered that, but I have no printer that can read X3G at all. I just took it upon myself to rewrite an old plug-in for modern Cura since I have deep knowledge of Cura, but I basically cannot test anything myself other than "does it create a file".

For all the printers I know, G0 and G1 is interchangeable. Slicers tend to mark a move as G0 if it's a travel move and as G1 if it's an extrusion move due to legacy.

One thing you could try is to add a post-processing script "Search and Replace" that replaces all occurrences of G0 with G1 and see if you can print then. That is just a workaround though.

What I really need to know is what to communicate to GPX to make it work for your printer. There's a couple of applications I know of that use GPX to convert g-code to X3G:

• This plug-in
• Octoprint
• Mattercontrol

ReplicatorG is also open source but doesn't use GPX.

[Ghostkeeper]

I've written more extensive explanations on how to support additional printers in the readme: https://github.com/Ghostkeeper/X3GWriter#support

Hopefully that answers the original question in this thread.

[Gouster4]

Anyone has made *.def.json for weistek WT150 for himself, and can share it please? I dont have almost any 3d printing experience, and zero experience with X3GWriter, but this part of ReplicatorG should be helpfull if anyone is able to port support for this printer and wants to do it for himself, and ideally share with us. https://github.com/jetty840/ReplicatorG/blob/master/scripts/s3g-decompiler.py Thanx.