how do I set a parameter without writing to EEPROM?

Home › Forums › TinyG › TinyG Support › how do I set a parameter without writing to EEPROM?

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • September 30, 2015 at 1:49 pm #8793
    Adam
    Member

    Hi, the current probe (G38.2) code does not back off of the latch after hitting it. This means that when using the Z-max limit switch for probing, one must first set $zsx=0. Otherwise the TinyG will leave the machine in the limit-switch-hit position after G38.2 completes, and the next command will always trigger a limit-hit position, locking up the TinyG.

    Unfortunately this is in conflict with what the “Flow Control and Footers” page says: since updating a parameter like $zsx writes to EEPROM, and writing to EEPROM requires disabling interrupts, the serial port flow control becomes unstable during this time. So you must not change parameters in the middle of a job!

    This stinks: I’m caught here between two requirements: MUST change $zsx during a job and MUST NOT change $zsx during a job. Yikes!

    The simple solution would be to update $zsx but not write the updated value to EEPROM. How do I do that?

    Thanks.

    October 1, 2015 at 6:43 am #8796
    cmcgrath5035
    Moderator

    I am not a probe user myself yet, but have seen a lot of dialog on the subject.
    Your writeup is a bit confusing.
    Why are you using the Zmax switch for probing ?; it would appear that the G38.2 code is optimized for probing using the Zmin switch, based on this:

    The mental model for the implementation is a PCB milling machine searching (down) for the surface of the blank board for setting a precise zero.
    You may be using tinyG for a totally different sort of application.

    Be bit careful reading too much into “Flow Control and Footers”; It was last updated Jan 2014 and may not be completely aligned with current FW.
    But for sure the issue remains for tinyG that parameter updates, such as $zsx= .., must be done one at a time as serial comms will be blocked during the update.

    If you have a unique application that does not follow the milling machine mental model, you may need to consider tinyG2, which has no EEPROM and also sports significantly more flexibility on configuring switches.

    You may want to pose this question here:

    but do expand a bit on your use for Zmax ‘probing’.

    October 2, 2015 at 4:59 pm #8804
    Adam
    Member

    > The mental model for the implementation is a PCB milling machine searching (down) for the surface of the blank board for setting a precise zero.

    Correct. On most CNC/PnP machines the Z-axis is “upside down” — Z=0 is the highest position and Z=1000mm would be underground, in the basement of the building. This is so that homing to X=0,Y=0,Z=0 is independent of what is underneath the machine head.

    FWIW this is a pick and place application. I need to probe the thickness of the PCB and various components.

    I ended up digging through the source code to fix this, although I was rather disturbed by what I saw. I’m probably going to switch to LinuxCNC.

    October 3, 2015 at 7:53 am #8805
    alden
    Member

    Sorry about the catch 22. What you are seeing is a workaround for a silicon bug in the Xmega. Any constructive criticism is welcome.

    Also, we have usually seen Z axes set up where 0 is at the top and it goes negative towards the work. That may solve your issue.

    • This reply was modified 9 years, 1 month ago by alden.
    October 3, 2015 at 12:03 pm #8807
    cmcgrath5035
    Moderator

    Adam
    Just to be clear; tinyG’s model is that home on Z, sets Z=0 at top of movement range on Z axis.
    Z=-1000mm is underground (headed in that direction);
    Z=1000 is invalid, beyond the homing and limit switch and headed to the sky.

    Perhaps you have the polarity set incorrectly on you Z axis motor ?

    October 3, 2015 at 12:42 pm #8808
    JuKu
    Member

    > Any constructive criticism is welcome.

    For switches (and other parameters that might change during regular operations, maybe all of them), you could keep a copy of the eeprom content in ram and implement a switch that allows changing only the ram copy. This allows a job to configure the machine for the requirements of the special job. The regular jobs don’t need to learn how to do this, those can rely on the machine having the standard configuration at power up. What do you think? In addition, this would make the applications that do configure the machine (including mine) on the run more reliable, avoiding wearing out the eeprom.

    October 4, 2015 at 7:24 am #8809
    alden
    Member

    It’s a good idea. In general, we should have more control over persistence. It’s possible to turn “auto-write” off, then have a “write” command. This would also address the issue of having to pause for 30 – 50 ms between each config during configuration sequences.

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