Jump to content

Marlin fork questions


antiklesys

Recommended Posts

Posted · Marlin fork questions

Hi,

I'm working on a fork for Marlin and I'm currently in need to make major changes to the configuration.h file.

The issue I'm running into is that i need to remove some of the defined constants in configuration.h and have the system use them as variables.

Of course if I even try to change:

#define Z_HOME_DIR -1

into:

int Z_HOME_DIR = -1;

I will get loads of compilation erros.

Any hints on how to proceed further?

My programming skills are a bit rusty, but I'm working on removing some dust from them :)

 

  • Link to post
    Share on other sites

    Posted · Marlin fork questions

    Those defines, if you go and change them into variables, all hell breaks lose because the code is filled with #ifdef and #if statements.

    You have a long way ahead if you want to change that particular one into a variable, not to mention you will lose performance in critical code.

     

  • Link to post
    Share on other sites

    Posted · Marlin fork questions

    Hi Daid,

    Why would be there a performance loss?

    For instance, X & Y default steps are defined in configuration.h, but then Marlin stores them in the eeprom and allows you to change them from the lcd menu. You actually go only back to the default values if you need to do a restore of the settings.

    Shouldn't it be possible to achieve a similar behavior for the Z_HOME_DIR without having a performace loss?

     

  • Link to post
    Share on other sites

    Posted · Marlin fork questions

    Hi Daid,

    Why would be there a performance loss?

    For instance, X & Y default steps are defined in configuration.h, but then Marlin stores them in the eeprom and allows you to change them from the lcd menu. You actually go only back to the default values if you need to do a restore of the settings.

    Shouldn't it be possible to achieve a similar behavior for the Z_HOME_DIR without having a performace loss?

     

    Because defines are evaluated at compile time, while variable happen at runtime. (which is also why you get these errors)

    Some of this #ifdef stuff is found at timing critical code, which is why it is done this way.

     

  • Link to post
    Share on other sites

    Posted · Marlin fork questions

    Why would be there a performance loss?

     

    Because if you define it as a variable, it is stored in memory. The processor has to go and fetch that value before it can use it. That's another instruction cycle which takes time. Not much extra time, but in critical code - it matters.

    When it is a #define, the value is known at compile time. The compiler can build the value into the instruction so it does not need a separate fetch cycle.

     

  • Link to post
    Share on other sites

    Posted · Marlin fork questions

    For yes/no flags (or "direction" in this case) you can do an IFDEF and have it compile one set of code versus another. So there is a decent performance improvement with this kind of thing. It eliminates an entire section of code and an extra "if" statement.

    For "steps_per_mm" kind of variables you aren't going to have any IFDEF statements so the performance difference is small if any (fetching value from code memory versus fetching from ram).

     

  • Link to post
    Share on other sites

    Posted · Marlin fork questions

    To answer your question - in the "h" file you can do:

    external int my_variable;

    And in *one* of the c files do:

    int my_variable = -1;

    But this only works if there are no IFDEF or IFNDEF statements accessing that variable.

     

  • Link to post
    Share on other sites

    Posted · Marlin fork questions

    Converting it to a variable only makes sense if you want to change the variable at runtime (eg; Do you want your user to be able to change the direction of the Z without recompiling the firmware?)

     

  • 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.7 stable released
        Cura 5.7 is here and it brings a handy new workflow improvement when using Thingiverse and Cura together, as well as additional capabilities for Method series printers, and a powerful way of sharing print settings using new printer-agnostic project files! Read on to find out about all of these improvements and more. 
         
          • Like
        • 18 replies
      • S-Line Firmware 8.3.0 was released Nov. 20th on the "Latest" firmware branch.
        (Sorry, was out of office when this released)

        This update is for...
        All UltiMaker S series  
        New features
         
        Temperature status. During print preparation, the temperatures of the print cores and build plate will be shown on the display. This gives a better indication of the progress and remaining wait time. Save log files in paused state. It is now possible to save the printer's log files to USB if the currently active print job is paused. Previously, the Dump logs to USB option was only enabled if the printer was in idle state. Confirm print removal via Digital Factory. If the printer is connected to the Digital Factory, it is now possible to confirm the removal of a previous print job via the Digital Factory interface. This is useful in situations where the build plate is clear, but the operator forgot to select Confirm removal on the printer’s display. Visit this page for more information about this feature.
          • Like
        • 0 replies
    ×
    ×
    • Create New...