alden

Forum Replies Created

Viewing 15 posts - 166 through 180 (of 702 total)
1 2 3 … 11 12 13 … 45 46 47
  • Author
    Posts
  • February 7, 2014 at 12:31 pm in reply to: Permanent cnc code on TinyG #5384
    alden
    Member

    You could use J17-J20, except that those are the stepper driver signals, so you would be disabling the steppers if you did so.

    February 7, 2014 at 9:11 am in reply to: Permanent cnc code on TinyG #5380
    alden
    Member

    Nicolo, J17 – J20 are not encoders, these are stepper signal outputs. You might be able to use the SPI outputs to drive an external SD card. The XIO system can be extended to use the SD card as a primary input.

    February 7, 2014 at 7:05 am in reply to: Where is the edge firmware? #5378
    alden
    Member

    OK. We have a new downloads page up that should help. try it out here:

    http://synthetos.github.io/

    +grim We still need to chase down your tgFX issue, though. The build is actually 412.01, and it should work with tgFX. We’ll try thiis out again to make sure there’s not something we missed.

    February 7, 2014 at 5:56 am in reply to: Driving 8 wire stepper with 2 outputs? #5376
    alden
    Member

    One other thing – there are no settings to control backlash in tinyg. This is something we are considering.

    February 7, 2014 at 5:10 am in reply to: Driving 8 wire stepper with 2 outputs? #5374
    alden
    Member

    Interesting.

    “Stalling at full speed” might indicate that full speed is too high for the setup / tuning. Every machine needs to have the max velocity tuned for each axis – it’s just a question of how much you can get out of it. With a more powerful driver you might be able to get a higher max velocity. Perhaps this is what you are saying and I just wasn’t listening correctly.

    I have started a page on using TInyG with external drivers.
    https://github.com/synthetos/TinyG/wiki/TinyG-Using-External-Drivers
    It’s pretty sketchy right now (as of this morning), but we should collect all facts, voodoo, folklore and wisdom there as this topic evolves. You are welcome to contribute if you want – the entire wiki is open to anyone with a github login.

    I will start the page by answering your questions above.

    • This reply was modified 10 years, 9 months ago by alden.
    February 7, 2014 at 5:00 am in reply to: Permanent cnc code on TinyG #5373
    alden
    Member

    No, you are not wrong. There is no provision to load canned gcode other than including it in the main program.

    There is a relatively simple way to do this if you are willing to recompile. Look in tinyg.h at how __CANNED_STARTUP functions. You can provide Gcode as a string array in a header file, compile it in, then have the machine run the Gcode whenever it starts up.

    I know this is a compile option, so it’s not as easy as inserting an SD card or something like that. Watch this space, however, we are continuing to add features and this in not the first time we’ve had a request for a simple way to do canned motion.

    February 7, 2014 at 4:52 am in reply to: Networked TinyG's for 5th and 6th axis? #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, 9 months ago by alden.
    February 7, 2014 at 4:42 am in reply to: TinyG- shield- only( interface) #5370
    alden
    Member

    Thanks for the request.

    We are working on an ARM version of TinyG that will support external axes (and other function) via the Kinen pluggable interface:

    https://github.com/Kinen/Kinen

    One possibility if you need something sooner is to use the Arduino Due port of TinyG under the G2 github repository. Bear in mind that this is really a development project and experimental at this point. It works pretty well, but not all features are implemented or tested. The Due version can be found here:

    https://github.com/synthetos/g2

    February 7, 2014 at 4:31 am in reply to: Female motor connector source for V7 board? #5368
    alden
    Member

    Thanks Pat. Sorry you had to find these on your own. They are now up on the wiki. I need to organize the HW section, but it’s a start.
    https://github.com/synthetos/TinyG/wiki/TinyG-Hardware-Information

    • This reply was modified 10 years, 9 months ago by alden.
    February 5, 2014 at 7:23 am in reply to: Overshooting Max Velocity #5354
    alden
    Member

    Interesting.

    Can you explain what you mean by “takes away the ability for me to have NC limit switches”? As far as I know nothing has changed in that area and the $st (switch type) parameter is still present and active. If you found otherwise we should fix this.

    Thanks for the list of commands you removed from the Gcode file. To my knowledge none of these should prevent the file form running, but there may be a bug. I’ll try them out and see if there’s a problem somewhere.

    Is it possible to provide a link to the Gcode file you ran, or short of that posting the first 100 lines or so? I’d like to run this in context if possible.

    If your machine won;t do 8000 mm/min you should probably drop the velocity maxes down to what each axis can actually handle. That should prevent the stalling. You may also need to adjust your jerk values. See here for some tuning guidance: https://github.com/synthetos/TinyG/wiki/TinyG-Tuning

    February 4, 2014 at 9:43 am in reply to: grblshield v3 not working #5343
    alden
    Member

    Sorry for the delayed response. There’s nothing on the board that should cause the PS (blue) light to blink – I suspect the PS is collapsing. Please try the following: Disconnect your motors. Turn the current pots all the way down. Try again. If the blue light is constant then connect the motors – possibly one by one. Try the power again. Then gradually up the motor current; one by one.

    What might be happening is that the current draw is large enough that one (or more) of the stepper drivers is going into thermal shut down. In this case the thermal can oscillate – sometimes quite fast. If the power supply is not adequate it could be collapsing and causing the blue light to run off when the voltage collapses. You can check this with a Voltmeter or scope.

    What kind of power supply are you using, and what is the voltage and current rating?

    Also, please make sure none of the motor wire ends are touching traces on the board. THis can happen if you are not careful on the Y axis, in particular.

    Lastly, are you sure you have a v3 board? we have not shipped those in a long time. What color is the board – green or blue?

    February 4, 2014 at 7:49 am in reply to: Overshooting Max Velocity #5342
    alden
    Member

    This is a new one on us.

    One thing to be aware of is the maximum velocity sets is used by traverse (G0, $_vm) and it reacts differently than a feed (G1, $_fr). A traverse is designed to go as fast as possible for point A to point B. The $_vm sets the maximum velocity *for that axis*, not for the traverse move. In a multi-axis traverse the resulting movement can therefore be faster than any individual axis in the move. For example, if you moved from (x0,y0) to (x100,y100) and had both xvm and yvm set to 1000, the move velocity would be 1414. Neither axis exceeds it’s limit of 1000 (1414 is just the vector sum of the velocities, i.e. 1000 * sqrt(2))

    This is as opposed to feeds (G1), which limit the total rate of the move to the F rate specified in the move (e.g. G1 F1000 x100 y100). Alternately, a feed may be limited by the max feed rate for a given axis, and the total feed rate of the move therefore reduced.

    So if your move had a minimal Y movement and a long X movement it’s still possible that the move itself will achieve a speed well above the Y limit. This may or not be the situation in your case.

    If you think there’s some other problem can you let us know a few things:

    – What firmware build you are running? – e.g. $fb 380.08

    – What are your X and Y settings (assuming only X and Y are in the move), $x, $y

    – What is the starting point of the move? Assuming the end point is X-43.992 Y224.789.

    – Just for completeness, what kind of machine are you running? Sounds like a belt driven machine given the high velocities you are using

    February 3, 2014 at 10:19 am in reply to: Recovering from failed flash upgrade #5333
    alden
    Member

    Please let us know if you run into any difficulties. Be aware that the boot loader we are using is a separate program located here:
    https://github.com/synthetos/tg-xboot

    If you use the boot loader to program you will not overwrite it. However, if you program the chip directly using an AVRISP mkII programmer it is possible to overwrite the boot loader if you are not careful (or you actually intend to do it).

    TinyG is currently developed under AVR Studio4 and Atmel Studio6.1 – both in a Windows VM. I just moved the VM from XP to W7. The main reason for using Atmel/Windows is a nice integrated simulation and debugging offered in the native Atmel tools. In spite of the Windows requirement. I run the VMs on OSX, but have not tried Mavericks yet. We have other developers using Xcode with GCC on mac, but no one (to my knowledge) in Linux before you tried it.

    If you are so inclined you could add the Linux toolchain notes as a page on the wiki. We’ll link it into the developer’s notes somewhere.

    • This reply was modified 10 years, 9 months ago by alden.
    February 3, 2014 at 9:45 am in reply to: An apology #5332
    alden
    Member

    Tom, Thanks for the post. It is much appreciated. If you can provide some specifics about Coolterm and your environment then we can warn off others.

    February 1, 2014 at 7:13 pm in reply to: Where is the edge firmware? #5323
    alden
    Member

    We are working on a page for all the hexes. Please be patient.

    As far as the verification error, we have seen that from AVRdude on occasion, but it does necessarily not signify that a failure has occurred. If the firmware returns the startup string and drives a motor then it has “taken”.

    Tom – the reason edge is not master (yet) is that it has not been fully tested. We make it available to people so they may try it out but people should know that it is not the “official” version yet. It may have bugs in it that we do not want as the main release.

  • Author
    Posts
Viewing 15 posts - 166 through 180 (of 702 total)
1 2 3 … 11 12 13 … 45 46 47