Jump to content

Custom profile issues (SV04, IDEX, Linux/Flatpak)

Recommended Posts

Posted · Custom profile issues (SV04, IDEX, Linux/Flatpak)



I am trying to create a set of new profiles for my Sovol SV04, a dual extruder (IDEX) printer. I am using Cura 5.7.1 on Fedora Linux 40 as distributed through flatpak/flathub.


The files themselves are available at: http://www.zytor.com/~hpa/cura/

I am using a Perl script to generate JSON, because there is so much replication, and things like the G-code strings are painful to edit as JSON.

I have a few problems/questions:

1. Installing the definition and extruder files in $HOME/~/.var/app/com.ultimaker.cura/data/cura/5.7 and removing the files in $HOME/.var/app/com.ultimaker.cura/cache *usually* works, but sometimes it doesn't seem to update everything. It is also kind of frustrating to have to re-install the printer manually every time - especially since this printer has five separate profiles (see below).


2. When something is wrong, the printer just doesn't get listed by Cura. The log file doesn't seem to show a single hint as to what is wrong. Is there a debug mode that I can enable?

3. It picks up the extruder definitions for *some* of the profiles, but not all. Notably, it seems to fall back to a default extruder for the "Single Mode 2" (right extruder only) profile. Following the Sovol definition, I have put its extruder in position "1", but I'm not sure that that is right. Note that the tool number for the G-code is T1 in this mode, so just blindly changing it to "0" probably would not work. Is this wrong, and the position should be "0" and only have extruder_nr be 1? Either way, it is really confusing to me that only some of the printer definitions files are picked up.

4. It rather sucks to need five different profiles; in particular the single profiles feel awfully redundant. I am scripting the generation, but still. The only real difference between Dual, Single 1, and Single 2 mode is some of the setup and shutdown G-code commands. Is there a sane way to detect and conditionalize code which extruders are enabled? The only way I can think of is to look at the combination of {initial_extruder_nr} and {extruders_enabled_count}, but that seems hacky at best and of course will not scale past two extruders.

-> For extra credit, it would be lovely if Cura would give the extruders *actually used* as opposed to *manually disabled*.
-> Similarly, I would love to be able to insert extruder-specific custom gcodes for the following events if an extruder is used:

     a. Immediately after machine_begin_gcode

     b. Before the *first time* the extruder is used (only);
     c. After the *last time* the extruder is used.

5. Regarding "variants": it states in the documentation that "variants mean nozzles". Would not things like Copy and Mirror modes make good variants rather than having an entirely different printer definition? (Alternatively, would it be better to create a custom printer setting in the .def.json file and use conditional expressions everywhere?) This would require being able to control the number of extruders based on that setting.)

6. Am I correct that it is possible for the machine_*_gcode fields to contain a Python expressions which would be evaluated at the time the gcode is generated (by using "value" instead of "default_value")?

Thank you!


  • Link to post
    Share on other sites

    Posted (edited) · Custom profile issues (SV04, IDEX, Linux/Flatpak)

    The bottom line to all of this is that UM Cura does not support IDEX printers.  You can get it to work well with IDEX machines, but it's all on you (and Sovol).


    I have the Sovol fork of Cura installed.  Looking through the gcodes in Copy, Duplicate, Mirror, 01 and 02 modes the only thing I see where the "mode" is being called out is in the second line of the Gcode in the printer name...


    If that is correct then you cannot change the "name" of a printer because it's actually a setting.

    In a UM Cura gcode the line is a bit further down, but it's the same line.



    No matter how you do it:  Picking a mode from a list in a post-processor, picking a mode from a list provided by a plugin, or picking a mode by selecting the appropriate printer from a list, you are going to have to pick a selection from a list.


    Part of what you are seeing with the different definitions is that the bed size changes according to the mode.  That allows you to know where to put the model so it will fit the printer in the mode you are using.  If you only had a single definition you would need to design a custom mesh platform with lines laid out on it so you would know where you can put the model and have it print on the bed.

    There is a plugin in the MarketPlace called "Extensive Support Logging".  It can help when looking for things in the log file.


    This is a line in my startup gcode.  If the bed temperature is less than 65 then I don't need to wait because it will take the hot end about the same amount of time to heat.  If the bed is at 83 for PETG then I need to wait for the bed to get there before the print starts.

    {'M190 S' if material_bed_temperature_layer_0 > 65 else 'M140 S'}{material_bed_temperature_layer_0}


    If you want to insert a custom command at a tool change you would need either a custom post-processor, or maybe Search and Replace would work for you.

    Edited by GregValiant
  • Link to post
    Share on other sites

    Posted · Custom profile issues (SV04, IDEX, Linux/Flatpak)

    So maybe I should clarify a little.

    There are a number of issues with the Sovol code (at least when using stock Cura); one of which relates to the initial temperature when there are different materials in use.


    I'm actually working against a modified version of the Marlin 2.1.x port which I'm hoping to, among other things, avoid the drain bramage of having to manually choose the mode on the printer. Marlin 2.1 already has commands for controlling the IDEX mode, so it is mostly an issue of configuring them properly.


    Cura *does* provide gcode commands for tool changes, but it can't seem to be made conditional on the first or last use of said tool.


    I'm being overly "fragile" with the level of integration, because I would like to be able to push this upstream.

  • Link to post
    Share on other sites

    Posted · Custom profile issues (SV04, IDEX, Linux/Flatpak)
    3 hours ago, hpalinux said:

    I am trying to create a set of new profiles for my Sovol SV04, a dual extruder (IDEX) printer. I am using Cura 5.7.1 on Fedora Linux 40 as distributed through flatpak/flathub.

    FWIW, support is only offered for the AppImage downloads of Cura produced by UltiMaker. I'm not saying Greg is wrong for trying to help you, just that if it's anything to do with Cura itself the official line is "you have to use the AppImage, then we'll help you".

  • Link to post
    Share on other sites

    Posted (edited) · Custom profile issues (SV04, IDEX, Linux/Flatpak)

    It's because things have been slow and problem solving always intrigues me.


    The first thing is to define the problem...

    @hpalinux Going through these posts it seems you really have two things you want to accomplish.

    1. You do not want to have to walk over to the printer and set the "print mode" manually.  That leads to a question...
      1. Is there a command that can be inserted into a gcode that will switch the mode?  I don't see one in the Sovol Slicer generated gcode.  Only the "printer name" changes and the printer name can be altered by the user so it really isn't a good choice as a "setting" for the printer.  I know that Raise3D uses "M605 S" to change modes.  It is very specific and can be entered into the gcode.  The user still has to select the "Mode" from a list but the gcode file itself can actually set the mode.
      2. Probably 99.9% of printers send themselves an internal gcode command when the LCD button is clicked on a menu item.  Whether it's an M220 to change the feed-rate or M206 to change the Home Offsets;  Some command is being passed from the LCD firmware to the mainboard firmware to make the change.  You need to figure out what the Sovol SV04 LCD button is using to set the mode in the printer.  Once you know the command it could be entered into the gcode while still in Cura and would eliminate the need for any "SneakerWare".  If the printer is capable of connecting to a server like PronterFace/PrintRun you could possibly monitor the printer and maybe catch what happens when you change modes using the LCD.  If you were to change modes and then send an M500 the printer may include the mode in the response.
      3. Sovol's "Five Definition" system is a pretty good way to do things.  You always know the bed size and shape that is  available for the particular "mode".
    2. You have a specific "First Tool Use" script and "Last Tool Use" script you want to insert at the appropriate time in the Gcode for each extruder.
      1. That requires a custom post-processor written in Python.  You would need to decide if it was required for all modes, or just particular modes.  Post-processors become "attached" to the active printer and the settings can be different for each printer a particular post-processor is attached to.


    A quick search turned up this site - "https://github.com/B20bob/sv04/tree/master/Start-gCode/Cura".  It has startup gcodes for each printer and it does appear that the SV04 also uses M605 to change modes.  Provided that works - a single post processor can be used to change modes within the gcode, and also, if the printer is set to Dual, Mode 01 or Mode 02 to add an appropriate script to tool starts and ends.


    Edited by GregValiant
  • Link to post
    Share on other sites

    Posted · Custom profile issues (SV04, IDEX, Linux/Flatpak)



    I'm aware of the internals -- I'm working with modified firmware after all (M605 is not present in the stock firmware as far as I know.)

    The big issues to me is that I'm having problems getting Cura to pick up my changes, and thus wondering if I'm doing it wrong *for the point of view of Cura*.


    I am noting that SV04 is literally the only printer that has an extruder train that is "out of sequence", which is one of the things I'm wondering if it is the cause of my problems.

  • Link to post
    Share on other sites

    Posted (edited) · Custom profile issues (SV04, IDEX, Linux/Flatpak)

    I'm still not 100% sure what you are trying to do.  That has never stopped me from pressing on in what might be an entirely wrong direction.  I still learn things.

    I have written post processors for the Flash Forge and Raise3D IDEX machines.  I figured with a little tweaking it could be made to work with the Sovol.  After reading some other posts (mostly on Reddit) it appears that at least on some SV04's that M605 is enabled.  If that works then you won't have to manually set the mode on the printer.


    The intriguing part of my little SV04 project was setting up macros for the first time each extruder is used, and for the last time each extruder is used.  That was a head scratcher.

    What I ended up with is this system, but it counts on M605 S0, S2, and S3 being enabled in the firmware.  You will have to see if this works.

    Each of the 5 installed Sovol printers would have the "Sovol SV04 IDEX" post processor active.  The post processor has a drop down with 5 options that match the 5 printers.  Each printer would have the post-processor set to match it.  "Dual" for the "Dual' printer, "Single Mode 01" for the "Single Mode 01" printer, and so forth.


    The script adds M605 lines just before the StartUp gcode.  If you are in "Dual" mode there are additional options for single start macro and single end macro for each extruder.  The gcodes for the macro will fit in the box but the box will only show a couple because the box is physically not very long.  It will take a lot of characters though so you could copy and paste into it.  Multiple commands would be delimited with commas.  You can see in the screenshot that I have some commands with lower case letters.  They are changed to uppercase by the script.



    In the case of "Dual" it gets an M605 S0.  I don't have the script adding any hot end heating lines to the startup based on which extruder is used first.  That could be done though.


    Understand that I have no idea if any of this will work with your printer.  The articles I read lead me to believe there is a chance.  As far as the "Start and End" gcodes for each extruder, they go into the gcode correctly, but as I said, I wasn't quite sure what you really want to do.  If nothing else, this was an interesting exercise for me.  If it turns out to be useless...I'm OK with that.

    Unzip the file and place it in your Configuration Folder and in the "scripts" sub-folder.  It will be available with the other post processors.



    As far as Cura "Not holding on to your changes"...The files are disappearing?  Almost any punctuation error will keep a file from loading in Cura.  For post-processors the log file is pretty clear and can tell you why it didn't load or why it loaded but didn't run.  With plugins (mine anyway) it's more like mud and may not mention what the problem is.

    Edited by GregValiant
  • Link to post
    Share on other sites

    Posted · Custom profile issues (SV04, IDEX, Linux/Flatpak)

    Well, merging the single and dual modes using the enabled_extruders_count hack seems to have worked. This reduces the number of profiles from 5 to 3, which is a lot more manageable, and it seems to avoid the problem with Cura not associating with the appropriate extruder files.


    I have posted the updated files to the same URL as I pointed to above.

  • Link to post
    Share on other sites

    Posted · Custom profile issues (SV04, IDEX, Linux/Flatpak)

    Now I find that {initial_extruder_nr} is wrong:


    ;Generated with Cura_SteamEngine 5.7.1
    M82 ;absolute extrusion mode
    ; --- begin SV04 start gcode
    ; extruders = 2, initial = 1


  • Link to post
    Share on other sites

    Posted (edited) · Custom profile issues (SV04, IDEX, Linux/Flatpak)

    There was a bug in "initial_extruder_nr" that caused it to always return the same number.  That was addressed in 5.7.0 but I wonder if there is a reversion here in 5.7.2.

    • Model set to T0
    • Support extruder set to T1
    • Skirt/Brim extruder set to "Not Overridden"
    • No post-processing
    • StartUp Gcode:
      • ;---------SV04 Dual start
      • ;Extruders: {machine_extruder_count}
      • ;Initial Extruder Nr: T{initial_extruder_nr}
      • ;Skirt/Brim Extruder Nr: T{skirt_brim_extruder_nr}
      • ;M104 T0 S{material_print_temperature_layer_0, 0}
        ;M104 T1 S{material_print_temperature_layer_0, 1}
        ;M104 Initial Extruder S{material_print_temperature_layer_0, initial_extruder_nr}
      • ;---------End of SV04 Start

    I get this:

    ;Generated with Cura_SteamEngine 5.7.2
    M140 S60
    M190 S60
    ;---------SV04 Dual start
    ;Extruder Count:2
    ;Initial Extruder Nr: T0
    ;Skirt/Brim Extruder nr: T-1
    ;M104 T0 S111
    ;M104 T1 S222
    ;M104 Initial Extruder S111
    ;---------End of SV04 Start

    T1 starts the brim, and T0 finishes it.  So yes, there appears to be something wrong with "initial_extruder_nr".  It might be part of the switch to "multi-material brims".

    That looks to me like a bug that is described in bug report #17501 on GitHub.

    Maybe @CasperLamboo or @Dustin has more insight on this.


    Edited by GregValiant
  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • UltiMaker Cura 5.8 beta released
        Another Cura release has arrived and in this 5.8 beta release, the focus is on improving Z seams, as well as completing support for the full Method series of printers by introducing a profile for the UltiMaker Method.
          • Like
        • 1 reply
      • Introducing the UltiMaker Factor 4
        We are happy to announce the next evolution in the UltiMaker 3D printer lineup: the UltiMaker Factor 4 industrial-grade 3D printer, designed to take manufacturing to new levels of efficiency and reliability. Factor 4 is an end-to-end 3D printing solution for light industrial applications
          • Thanks
          • Like
        • 3 replies
    • Create New...