Limit switches

Home › Forums › TinyG › TinyG Support › Limit switches

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • January 8, 2013 at 11:38 am #3681
    jana
    Member

    Alden

    Hi. I am really impressed with this project.  In fact i liked the controller so much that i bought both the GRBL shield and the Tiny-G . About the limit switches. I have also seen the same problem as mcduff has

    reported .  https://www.synthetos.com/topic/limit-switches-y-a-switched/ .

    We have built lot of cnc machines in the past.  the limit switches are used for controlling the machine work area . In this way                                   we never had any crashes in our systems. And the xmin and ymin could just do that.  Right now the limit switch resets the board. And               we are unable to connect the system back. Only way to connect back is by resetting the board. Instead could you implimint it in such a way that it will pause the entire run. So that we could issue a software reset and issue the G28.1 command and restart the job from homing.

     

    Thanks

    Jana

     

     

    January 9, 2013 at 6:10 am #3682
    alden
    Member

    Thanks for the kind words. I have actually done what you suggest, but the code is not in the Master release yet (on github). The way limits work 0.95 pre-release code in Edge is documented here – see the Limit Switch section.

    https://github.com/synthetos/TinyG/wiki/TinyG-Homing

    The Y and A have been fixed, and there is a software way to do a reset. However, it is up to the controller to restart the run – the board has no way to know where the tool actually is at that point. We have to assume that the machine has lost position when a limit is hit.

    Please also note, the homing sequence has moved from G28.1 to G28.2 in order to make G28 compatible with the LinuxCNC (EMC2) behaviors.

    Alden

     

    January 9, 2013 at 12:01 pm #3684
    jana
    Member

    Alden

    Really appreciate your quick response. I am really inspired by the way you support the community .

    Should i recompile the source code from the edge . Or is there a compiled version present which i can burn the code

    directly to the controller.  Will get back to you after the verification tomorrow.

     

    Thanks and have a nice day

    Jana

    January 9, 2013 at 1:26 pm #3685
    alden
    Member

    You can find the tiny.hex file in the edge here: https://github.com/synthetos/TinyG/tree/edge/firmware/tinyg/default

    The build in edge is 357.01 (not 537.01 as I typo’d) . You can see changes up to that point here: https://github.com/synthetos/TinyG/wiki/Road-to-1.0

    Alden

     

    January 10, 2013 at 6:54 am #3686
    jana
    Member

    Alden

    I could successfully bun the code.

     

    1. X and Y axis limit switch fix has being verified and now the mapping is correct.

    2. When the Max limit switch on x and y are hit. The spindle ccw led blinks and indicates that the machine is at halt position.

    Thanks for the led indication . This is really use full for the operator. Sending the ^x command from cool term rests the machine .

    Led stops blinking. And the machine goes to G80 stop mode. and once the machine is bought to G0 command works as fine

    Fixes to be done

    1. When we first connect to the board using cool term . The terminal is not showing the typed commands on the screen.

    And the “tinyg [mm] ok > is displayed in horizontal manner . not as previously when entered  key scrolls vertically down

    2. Homing is not working properly. When we issue G28.2 x0 command the machine first moves the axis in postive direction 2 times and then

    moves in revers direction hits the limit switch hard and backs of only once . Previously after issuing the command the machine use to

    start moving in reverse direction first. and when the home switch is hit it backs off two times which was better. Please fix this as i lost my

    one of the limit switches already. Because when the limit switch is hit on the max side . I issued a G28.2 command to go to home . Instead

    of reversing back at first. It moved in the positive direction and hit the switch hard. Please fix this asap.

    3. $defaults variable is removed now.

     

    Thanks Have a nice day

    Jana

     

     

    January 10, 2013 at 8:41 am #3687
    alden
    Member

    Homing is very dependent on your settings. Can you list your $x settings and your $sys group? Are you using NO or NC switches and is $st set for the correct type?

    The defaults are set up for X on the min switch. Have you changed the switch settings to reflect your setup with X on the max switch? I’d like to understand and reproduce your issue. Some pictures of your setup may also be helpful, as the backoffs need to be sufficient to clear the switches. This can vary widely for different switch arrangements.

    January 11, 2013 at 7:01 am #3689
    jana
    Member

    Alden

    After going through the setting carefully . I saw the switch value was wrong. Sorry from the trouble.  The machine is in the

    office cameras are not allowed. Still will upload asap. Now everything is working fine. Though there is one small issue in the homing .

    Previously with the same switch that is being used now. At the homing switch end. The machine use to bounce back twice. But now it

    bounces only once . Please find my below settings and let me know if the values are fine.
    Switch that is used http://www.newark.com/omron-electronic-components/d2sw-3h/microswitch-v4-plunger/dp/13J8836?in_merch=true&MER=ALT_N_L5_Switches_None

    $st

    [st]  switch type                 0 [0,1]

    $sys

    [fb]  firmware build            357.01

    [fv]  firmware version            0.95

    [hv]  hardware version            7.00

    [gpl] default gcode plane         0 [0=G17,1=G18,2=G19]

    [gun] default gcode units mode    1 [0=G20,1=G21]

    [gco] default gcode coord system  1 [1-6 (G54-G59)]

    [gpa] default gcode path control  2 [0=G61,1=G61.1,2=G64]

    [gdi] default gcode distance mode 0 [0=G90,1=G91]

    [ja]  junction acceleration   10000 mm

    [ct]  chordal tolerance           0.010 mm

    [st]  switch type                 0 [0,1]

    [ic]  ignore CR or LF on RX       0 [0,1=CR,2=LF]

    [ee]  enable echo                 1 [0,1]

    [ex]  enable xon xoff             1 [0,1]

    [eq]  enable queue reports        1 [0,1]

    [ej]  enable json mode            0 [0,1]

    [jv]  json verbosity              5 [0-5]

    [tv]  text verbosity              3 [0-3]

    [si]  status interval           200 ms [0=off]

    [baud] USB baud rate              0 [0-6]

     

    $x

    [xam] x axis mode                 1 [standard]

    [xvm] x velocity maximum       7000.000 mm/min

    [xfr] x feedrate maximum        700.000 mm/min

    [xtm] x travel maximum          220.000 mm

    [xjm] x jerk maximum       50000000 mm/min^3

    [xjd] x junction deviation        0.0100 mm (larger is faster)

    [xsn] x switch min                3 [0-4]

    [xsx] x switch max                2 [0-4]

    [xsv] x search velocity        -400.000 mm/min

    [xlv] x latch velocity          100.000 mm/min

    [xlb] x latch backoff             1.000 mm

    [xzb] x zero backoff              2.000 mm

     

     

    January 11, 2013 at 8:57 am #3691
    alden
    Member

    Jana,

    Glad you got it fixed. The “single bounce” behavior you are now seeing is correct, and is different from the earlier code. This is deliberate. Here’s how it works now. (1) advance to the switch at search velocity and stop (decelerate) once the switch is hit. (2) back off the switch at a much lower latch velocity until the switch opens again. This is the set point. (3) back off the switch some amount to set the zero for that axis. My machinist friend told me this is the way it’s supposed to work, so I changed it.

    In looking at you configs I see you using -400 for search velocity. The – sign is not necessary anymore as homing now always searches in the direction of the homing with – which it now knows because of the $xsn and $xsx settings.

    Also, the latch backoff may be too small. I see you have just plungers and no leaf on the switch. If the latch backoff does not clear the switch the results will not be accurate, and the homing routine may not be able to clear a limit switch that was closed on initialization (i.e. you started homing but the other switch was closed). Try using 5mm – at least enough to back off a worst-case switch closed situation. With these types of switches you should also be careful not to search on them too fast as the axis needs to have enough room to decelerate without destroying the switch.

    Alden

     

    January 11, 2013 at 9:25 am #3692
    jana
    Member

    Alden

    Thanks for your support. With this kind of support. I have decided to buy more controllers .

    One small  ???

    When the text file is sent from the cool term it works fine .But when sent from universal g-code sender . After few commands

    the machine does not except any command. Why?

     

    Thanks

    Jana

    January 11, 2013 at 5:49 pm #3697
    Riley
    Keymaster

    Universal gcode sender is NOT made tobe used with TinyG.   Its in the way the buffering work I am pretty sure.  Its purely for grbl.

    ril3y

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