Networked TinyG's for 5th and 6th axis?

Home Forums TinyG TinyG Support Networked TinyG's for 5th and 6th axis?

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #5364
    donhiatt
    Member

    Wondering if anyone has done this? Does Gcode commands automaticly use the networked TinyG’s to issue commands for 5th & 6th axis control?

    Thanks!

    Don

    #5366
    pat19087
    Member

    I am sure that the firmware automatically supports this. But we should let one of the authorities chime in. Alden has told me on several occasions that the TinyG can be connected together and “it just works”

    #5371
    alden
    Member

    Well I hope I didn’t say “it just works”, because it took some work, but we did get this running for a customer that was building a 5 axis machine.
    http://www.pocketnc.com/

    We connected 2 v7’s together using RS-485 and ran one (the master) as XYZ and relayed gcode down to the other for the rotary axes. It worked, but the few milliseconds of latency between the master and slave was enough to mess up the fine coordinated motion required for 5 axis machining.

    So our solution (and what the PocketNC uses now) is a true 5 axis board based on the ARM code base we’ve been working on the the last 12 months. The code base is available in experimental for under the synthetos G2 github. It will compile for our ARM proto boards (example): http://www.flickr.com/photos/rileyporter/12083763146/

    …or to run native on an Arduino Due. You provide all motor electronics.

    We are aiming to have the ARM version out this spring (soon!)

    • This reply was modified 10 years, 7 months ago by alden.
    #5388
    donhiatt
    Member

    So running TinyG2 on the Due allows a grblshield to be attached but is it possible to attach two grblshields to a single Due and from software configure and control six motors?

    The prototype discussion at kinen leads me to believe that five axis would be the norm… three on board with two kinen paddle boards. Easily accessing six motors wouldn’t be possible without some major hacking of the software and possibly some on the hardware as well.

    I’m building an automation machine that lends itself well to several stepper motors and gcode seems like a sort of easy hack to make five motors do something. But I probably also need feedback to the gcode to allow other off axis sensors, limit switches and relays to provide feedback for controlling different situations.

    Am I barking up the wrong tree trying to use gcode and five axis to control eight things?

    #5396
    pat19087
    Member

    No worry Alden, “It just works” is trademarked by Apple. I misquoted you.

    That PocketNC looks like a very interesting project.

    #5446
    alden
    Member

    Sorry for the late response.

    I think Kinen can get you there, but you may need some sort of coordinator for the other items. One main aspect to consider is what is the biggest coordinated domain you need? Is 5 axes enough? Do you need more that that in tight coordination? The other aspect is how many independent motion domains do you need? – i.e. motors or motor groups that do not need to be in lock-step. For example, can manage uncertainty / latency of 10’s of milliseconds.

    (This was the problem with our early experiments with PocketNC – we put 2 TinyG’s together to make 6 controlled axes, but the lag between the XYZ controller and the ABC controller was too great, and the tool head ultimately did not track well. But if XYZ motion were independent of ABC motion it would have worked OK).

    Right now the v9 in development can handle 5 axes – 6 with extension of coordinated motion. The other “onesy-twosy” axes can be handled with independent motion sub-systems. Then you are left with the issue of integrating these.

    Kinen is based on the JSON work we have done, and we are working towards control of multiple motion / sensor domains by routing JSON objects based on inspection of the parent tag (if this makes any sense). See here:
    https://github.com/Kinen/Kinen/wiki/Kinen-RESTful-Hardware-Conventions#wiki-advanced-conventions

    This way you can integrate larger systems consisting of independent sub-systems. It makes Kinen scalable to a reasonably large system consisting of loosely coupled motion / sensor domains.

    If you are interested in moving this forward we should talk further. Otherwise, just watch this space. (No promises on timing!)

    • This reply was modified 10 years, 7 months ago by alden.
    • This reply was modified 10 years, 7 months ago by alden.
    #9822
    Christine88
    Member

    I’m building a 5-axis CNC very similar to the pocket nc and I want to use a TinyG. Can you tell me what I need to plug into the TinyG board to control the A and B axis just as was done with the pocket nc?

    #9825
    cmcgrath5035
    Moderator

    As you can see, this is a very old (in CNC, anyway) thread.

    Solutions include two networked tinyG’s and tinyG2 running on a DUE.

    The thread above highlights potential latency issues with the networked approach, it is seldom talked about here and on-going support might be questionable (or at least slow).

    The universe is moving in the direction of tinyG2 for these applications.
    The added hard=ware horsepower really helps.

    Start by reviewing G2 here:

    as well as this Forum,the Ox Forum and the Chilipeppr forums.

    Lots of activity

    #9836
    vikarpeter
    Member

    hi,

    I am rebuilding my 4-axis(X,YY,Z,A) tinyG cnc machine to a 5-axis setup. The 5th axis will do a ‘cleaning sequence’ so latencies are not an issue. In addition i am also implementing a raspi3 to send the g-code if possible via chillipepper.

    I am thinking to have a stepper shield on the raspi3 to take care of the 5th axis, and somehow have the gcode send instructions to both ‘systems’.

    Curious to hear your thoughts. thnx

    #9837
    cmcgrath5035
    Moderator

    What you seek to do is more in the CAM domain rather than tinyG.
    I’d suggest hunt around Chillipeppr or perhaps Ox forums – lots of RasPi users, some with ideas similar to yours.

    It would seem the challenge would be to coordinate the different driver machines.

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