Z axis problem

Home › Forums › TinyG › TinyG Support › Z axis problem

Tagged: 

Viewing 6 posts - 31 through 36 (of 36 total)
1 2 3
  • Author
    Posts
  • April 3, 2014 at 11:55 am #5740
    sparkcrafter
    Member

    I had a chance to do some quick testing yesterday and the new firmware seems to work good for me as well. I was able to get both of the reliefs I had posted to cut without problems.

    For the $st setting, it seems to work correctly if you set $st=1, it just doesn’t report it back correctly (always reports back zero).

    April 18, 2014 at 11:39 am #5776
    grim
    Member

    I’ve run the new firmware a number of times now and have had the z-axis problem pop up again. The first two times it moved up, which was awesome compared to before, and I was prepared to live with that, but yesterday I had it plunge again. Still very random though. The first time was on a relatively simple and short program, but the second time it made it about 4 hours into a very long and complicated program before it happened. The third time was again on a simple short program. I’m sending files using coolterm. I know this sounds crazy, but it seems like right after I flash firmware everything works OK and then the more I run programs the more the problem happens. I don’t know how this could be possible, but it seems like that’s whats going on.

    April 18, 2014 at 11:48 am #5777
    alden
    Member

    Are you running build 421.06? Since 421.06 I have found what I believe is the root cause of the problem. I want to run some more tests on the current build then push a commit sometime Saturday.

    In build 421.06 plan_line.c lines 229 and 230 need to be reversed. There is a condition caused by a series of very short and/or high-speed Gcode blocks that leads to a buffer starvation, causing the position to be mis-recorded.

    Can you please confirm the build you are on?

    Thanks

    April 19, 2014 at 1:12 am #5780
    grim
    Member

    Alden, I am on build 421.06.

    April 21, 2014 at 7:32 pm #5803
    Riley
    Keymaster

    Hey Spark,

    I see you are using coolterm? Did you try tgFX? I will have an OXS new “edge” build out tonight? (i hope) that you can test. However, I am curious as I do a different method of sending files rather than just using RTS. I use RTS + count bytes. Its not ideal and I will update this to use qr’s as well. However I would be very interested to see if you still experience this same issue in tgFX.

    ril3y

    April 22, 2014 at 5:17 pm #5813
    sparkcrafter
    Member

    Riley,
    I assume you’re really interested in feedback from grim, as he is the one currently having an issue. My issues with the buffer issue seem to be ok now with 421.06. I did do a quick of the latest tgfx build you posted to see how it worked, however it crashed after just a few keystrokes so I’ll stick with coolterm for now. Here’s the quick feedback on the tgfx build:
    1) “Hardware” is misspelled in two places in the section listing firmware version.
    2) The graphical display of position will be great when it is fully working, but not having any ability to zoom limits its usefulness for me. Also, I like to put the 0,0 location of the spindle in the center of the work piece. This results in the graphical drawing extending out past the graphics window. For now, a simple constraint on the drawing to stay within the graphics window would suffice, but the optimum solution for me would be to auto-zoom the window to the extents in the loaded gcode file.
    3) To hang tgfx I loaded the rabbit gcode mentioned earlier in this thread into tgfx and clicked on “run”. After running a few minutes I clicked “stop” and then clicked “run” again. There was no response from tinyg when “run” was pressed. I then clicked “reset” and then “run”. At this point tgfx was hung with the circular “wait” icon.

  • Author
    Posts
Viewing 6 posts - 31 through 36 (of 36 total)
1 2 3
  • You must be logged in to reply to this topic.