psyko

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 36 total)
  • Author
    Posts
  • in reply to: Post processor for VCarve 4th axis work? #10216
    psyko
    Member

    Hello jonnorrismusic, elcanadian,

    Not sure if you found a solution to your issue, but I also use a 4th axis on my CNC.
    I’ve been developping Goko (http://www.goko.fr) and it supports rotary axis (including 3d representation).
    There is also a wrapper modifier for GCode allowing to change X, Y or Z axis to A axis.

    Let me know if that’s what you need.
    Thanks,

    in reply to: Arc Specification Errors #10179
    psyko
    Member

    Hi LonV

    Sorry, I just found your topic (yeah almost 7 month later…)
    I’m the developper behind Goko. Did you find what was causing your error ?
    In this case Goko simply reports the error from TinyG to the user.
    Most likely it’s because the start and end point of the arc command are not equally spaced from the center point….

    A feature to specify some error to ignore is somehow on my todo list, but I’m not sure this one should be ignored.
    Do you have any GCode to reproduce it ?
    Can you please use github or forum of Goko for this topic ?
    discuss.goko.fr
    https://github.com/cncgoko/Goko

    Thanks a lot, and again, sorry for the late answer…

    in reply to: Machine not following gcode, crashes #10022
    psyko
    Member

    Hi,

    Just found this topic πŸ™‚ I’m the author of Goko


    @vex
    this indeed looks likes a flow control issue, and some gcode are mixed.


    @cmcgrath5035
    the link you’re posting is actually the doc for the software

    The download itself is available at goko.fr (and not goko.com as you mentionned πŸ™‚ )

    If you have any question, feel free to ask on discuss.goko.fr

    Thanks,
    Psyko

    • This reply was modified 8 years, 1 month ago by psyko.
    in reply to: Offline GUI??!! #9717
    psyko
    Member

    @hareedy1
    Sorry for the delay. It does not support TinyG G2 for now.
    I didn’t check the diff between TinyG and G2, but it’s something that should be achieved quite easily (when I have time to do it, of course πŸ™‚ ). I have to see how stable is G2.

    You guys let me know if you have any issue/question/suggestion on Goko.

    Thanks πŸ™‚

    in reply to: Offline GUI??!! #9545
    psyko
    Member

    Hello,

    I’m working on an application called Goko available here : http://goko.fr/.
    It supports TinyG & Grbl.

    A new version featuring updates is under development and should be available soon.

    It’s still under development, soi let me know on github if you find any issue :
    https://github.com/cncgoko/Goko

    Regards,

    in reply to: Weird inaccurate first move after homing #6369
    psyko
    Member

    Hi,

    Is there any significant change in the json dial protocol since 380.05 (I know I’ll have to change the Buffer planner report)

    Thanks

    in reply to: Weird inaccurate first move after homing #6241
    psyko
    Member

    Thanks Alden, I’ll check this.
    Is there any changelog somewhere to see the differences ?

    in reply to: TinyG/CoolTerm crashing solved #5584
    psyko
    Member

    tom, you should always use the motion Gxx keyword before issuing a move, unless you’re 100% sure of the mode.
    I would suggest you to read the RS 274 NGC GCode specification :
    http://technisoftdirect.com/catalog/download/RS274NGC_3.pdf

    Once you have a good understanding of GCode functionalities, you can try and use TinyG.
    I’ve been using it for a while now, and didn’t notice major issues. What you are mentionning really are the basics of GCode… I would be surprising that those basics methods don’t works, regarding what I’ve been able to do with the board.

    The only issue I’m having is small unexpected arcs. But I’m still trying to figure out the cause (TinyG, USB noise, so on…)

    in reply to: TinyG/CoolTerm crashing solved #5547
    psyko
    Member

    TinyG is modal. Resetting the buffer does not reset the board or the mode. Since g3 was the last β€œmode” it was in. It will continue to be in this mode until you change it.

    Agreed, sending simply a Z0 command doesn’t mean anything in Iso GCode.
    It’s like hitting the accelerator pedal and expecting the car to move forward while you have the rear gear engaged.

    in reply to: Firmware? #5546
    psyko
    Member

    Hello,

    You’ll find the firmware on Github
    https://github.com/synthetos/TinyG/tree/master/firmware/tinyg/default

    Download the hex file

    in reply to: An example #5300
    psyko
    Member

    @alden I’m running 380.05.

    I’ll try to find GCode that causes the issue. Infortunately, I’m not close to my workshop now…

    in reply to: TinyG Planner buffer #5293
    psyko
    Member

    Ok I’ll try to use the planner as it is now.

    The only issue I see for now, is that using the planner queue is not enough. We have to use Xon/Xoff
    – I can’t send a group of command, since I’m not sure how much slot the command will take in the buffer (If I remember correctly, I’ve seen arc command take up to 10 slots…). I have to send one command, wait for the QR answer, and send another.
    – Using Xon/Xoff kind of kill the idea of planner buffer flow control. Using only Xon/Xoff should completely do the trick. Right ?

    I’ll have to take a closer look at all this.

    Thanks anyway

    in reply to: An example #5292
    psyko
    Member

    Hello guys,

    Now that I read that arc issue, I sometime do have it as well.
    I always assumed it was some kind of heating problem, or some issue with my control software.
    I figured out that my software have issues with filling the planner buffer, but it is sending the command properly.
    Unfortunately I do not have any GCode or data to provide but I noticed this behavior several times.

    Hope you can identify the issue.

    in reply to: TinyG Planner buffer #5283
    psyko
    Member

    Thanks, I’ll take a look at these !

    Would it be possible to increase the queue size ?

    in reply to: An example #5266
    psyko
    Member

    Keep in mind that Coolterm is simply a terminal.
    If you cancel in the middle of a line, when CR/LF is not send, I think the data will stay in the Serial buffer because TinyG didn’t encounter the end of command token (new line char). Then you send g0z0. In TinyG serial buffer, this leads to the following line :
    y1g0z0\r\n

    which is assumed to be a motion I guess. That might be one explanation, but the line you gave is not the same as my guess.
    I’m not sure that there is a command to flush the serial buffer in TinyG. ‘%’ will only clear the planner buffer.

    But I’m simply a user, alden will confirm or deny what I’m saying.

Viewing 15 posts - 1 through 15 (of 36 total)