Config parameters not being saved

Home › Forums › TinyG › TinyG Support › Config parameters not being saved

Tagged: 

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • April 5, 2018 at 5:21 pm #10951
    jimtellier
    Member

    I’m using TinyG V8, $fv=0.97 $fb=440.20. Just got my X,Y
    motors moving, and in the process of setting up switches, then
    doing tuning steps. I have noticed that setting various params
    $1tr=12.7, $2tr=2.54, $xtm=762, $ytm=200 etc. do not persist across a
    power cycle of the TinyG. Two questions:
    1) are ALL of the configuration parameters supposed to persist, or just
    a subset? If not all, which ones?
    2) is there a case where the built-in Defaults get restored without my having
    used the $defa=1 command?
    I’m using CoolTerm under Windows 10; manual cli entry of single Gcode commands.
    Any insight would be appreciated!
    Jim

    • This topic was modified 6 years, 8 months ago by jimtellier.
    April 5, 2018 at 10:11 pm #10954
    cmcgrath5035
    Moderator

    I would say that all settable parameters in the $$ report are (supposed to be) persistent, the fact is one, perhaps 2 cannot be changed (like Serial Numb)and are really read only. For sure motor and axis parameters are changeable and persistent.

    A new firmware download will reinstall the default parameters.

    Run a quick test
    $1tr=new number
    Manual (push the reset button) reset; $1tr still = new number?
    if so, Power cycle tinyG; $1tr return to default or remain new number?

    April 5, 2018 at 10:16 pm #10955
    cmcgrath5035
    Moderator

    I would say that all settable parameters in the $$ report are (supposed to be) persistent, the fact is one, perhaps 2 cannot be changed (like Serial Numb)and are really read only. For sure motor and axis parameters are changeable and persistent.

    A new firmware download will reinstall the default parameters.

    Run a quick test
    $1tr=new number
    Manual (push the reset button) reset; $1tr still = new number?
    if so, Power cycle tinyG; $1tr return to default or remain new number?

    April 11, 2018 at 7:28 pm #10959
    jimtellier
    Member

    Finally had a chance to get back on this!… tried your quick test…works fine…
    I then tried setting all of the parameters I need for 3 axes, switches etc…and again, works fine! I don’t know what happened the previous times I did this, but I do know it really didn’t “stick”, but now it does. Gremlins!
    I’ll keep an eye on things as I move forward, and report any issues.
    One difference I note is that, when I was initially testing persistence, I was doing things using individual commands, e.g.:
    $1tr=12.7 –> $1tr –> power-cycle –> $1tr.
    This time, I did the value verification by using $$ each time I set a few parameters, then after Reset and again after power-cycle. I captured and compared each $$ output and all is well. Thanks for your assist!

    • This reply was modified 6 years, 8 months ago by jimtellier.
    April 11, 2018 at 10:04 pm #10961
    cmcgrath5035
    Moderator

    Well, good news, but unusual behavior to be sure

    The write cycle to EEPROM can be rather long, but I doubt you type that fast
    Try this again: $1tr=12.7 –> $1tr –> power-cycle –> $1tr
    but this time, $1tr=12.7 –> $1tr (do you get a $1tr=12.7 response ?)–> [wait 5] sec power-cycle –> $1tr

    April 12, 2018 at 1:26 am #10962
    jimtellier
    Member

    In all cases as you describe, $1tr returns 12.7 after power cycle.
    I have XON flow control in use, rather than CTS; are there any known
    reliability issues with that? I doubt if that’s relevant, but…

    April 12, 2018 at 6:55 am #10963
    cmcgrath5035
    Moderator

    A couple years back (before Chilipeppr, CNC.js and others), CTS was suggested to be more reliable by the Synthetos devs, but both CTS and Xon/Xoff remained supported by the tinyG FW.
    That “While back” would be before Win10 as well.
    And issues that were reported were with file transfer, i.e. sending longish jobs, not individual commands from the CLI.

    It is possible that some glitch has appeared with the CoolTerm-Win10 (serial protocols concatenated with FTDI support)-tinyG_FW chain. Most performance users have moved on to buffer based flow control (ala Chilipeppr), so it is almost impossible to know how well certain segments of the connection space are getting tested.

    Short answer – move on, but keep a eye out that parameter changes you need are remaining persistent.

  • Author
    Posts
Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.