Wierd GCode Results

Home › Forums › TinyG › TinyG Support › Wierd GCode Results

Tagged: 

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • September 19, 2015 at 12:56 am #8761
    jpistorino
    Member

    I am writing something similar to Chilipeppr and what JuKu is working on and am getting strange results. I am using firmware build 438.02.

    First, I am issuing a series of commands like: “G0 X1500.0000, F400”
    These commands are a jog feature that is issued when the user presses an arrow key. When the user releases the arrow key, I issue a “!%” to stop movement and clear the buffer. It appears the the “F” portion has no effect on the movement speed and movement appears to be at the maximum velocity rate. Why is that?

    Second, at times, it appears that the whole system loses track of it X or Y axis location. The motors move along and axis but the reported axis position changes only a small amount. Why is that?

    Third, sometimes, I am seeing that the axis are transposed in the middle of operation. That is, the machine will be moving on the X axis but the Y axis position is reported being changed. Why is that?

    I have a text file of all the commands issued to the TinyG and the TinyG responses that I could upload, if I had some guidance on how to do that to the forum.

    Any help appreciated.

    Thanks,
    James

    September 19, 2015 at 6:54 am #8762
    cmcgrath5035
    Moderator

    For starters, you need to move up to FW 440.20, the most recent master.
    Some behavior you report is similar to bugs cleared as various times in the past year or so.
    There is no incremental support for old releases, aside from moving to most recent.

    All G0 commands, by definition, move at maximum velocity. If you want to do your jog at F400, use “G1 X1500.0000, F400”. Make sure you consider logic as to absolute or relative movement.

    To share parameter sets, Gcode etc use this method:

    It is usually helpful for us to know what OS you are using for your controlling PC (Win, Linux, Mac)

    Of the many complexities you will face, flow control will be a big one.
    RTS/CTS may work for you, but not all serial drivers do a real good job at high speed. CP manages flow control via buffer fill management; complex but most effective.

    Good luck with your project

    September 20, 2015 at 4:29 pm #8767
    jpistorino
    Member

    Thanks.

    I see in response to my earlier question, you did say “use G1 …” and I just missed it.

    I will reflash with the newest version.

    For me (and possibly JuKu), the buffer size is not an issue as I am not processing a GCode file. Instead I am issuing GCode commands in response to keyboard input. So far, I have only seen two or three commands in the buffer at one time. I did first think of this as a source of the problems but verified the length of the buffer. In any event, it is a good thing to keep in mind.

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