alden

Forum Replies Created

Viewing 15 posts - 601 through 615 (of 702 total)
  • Author
    Posts
  • in reply to: Step Invert mask for GRBLShield? #1716
    alden
    Member

    Todd,

    I do believe you are correct. I’ve never had to mess with the grbl default settings other than setting the motor steps, $0, $1, $2. Grblshield should be just plug and play.

    $3 is the step pulse width. The stepper drivers on grblshield can take as little as 1 microsecond, but I’m not sure what the lower range if grbl is. 2 should work.

    $7 is the invert mask. It should work with standard grbl settings – try $7=0. Note that bits 0 and 1 are not used, so the bitmask actually looks like: 0b Zdir Ydir Xdir Zstep Ystep Xstep 0 0

    Try this and see if it works. If the motors turn the wrong direction you have to add 32 to the number to invert the X direction, 64 to the number to invert Y and 128 to invert Z – i.e. $7=32 to invert X, $7=96 to invert both X and Y, etc.

    in reply to: Axis LEDs seem wrong… #1860
    alden
    Member

    I’ve tried 0.8a and it seems fine. As far as the lights lighting, this is not unusual. As long as the axes you are diving r moving correctly (and the others are not doing anything they should npt be) this is OK.

    in reply to: Step Invert mask for GRBLShield? #1713
    alden
    Member

    Yes, this is the invert mask. It’s a bit confusing. You can use the invert mask to change the direction in software. I have to refer you to the grbl documentation on how to use this setting. https://github.com/grbl/grbl/wiki/Configuring-Grbl

    in reply to: GUI for TinyG controller #1497
    alden
    Member

    Riley has been making good progress on this. You and he should connect up about the JavaFX development.

    in reply to: Axis LEDs seem wrong… #1858
    alden
    Member

    What version of grbl are you running and from what source? Here’s the official source and our wiki page about getting grbl

    https://github.com/grbl/grbl/downloads

    http://www.synthetos.com/wiki/index.php?title=Getting_grbl

    in reply to: Step Invert mask for GRBLShield? #1709
    alden
    Member

    This sounds like a hardware problem to me. If the direction line for the X axis is not working correctly then the axis will only move in one direction. Do you have the ability to see if the dir signal is being set correctly? I know this is a bunch of work involving an oscilloscope and probes, and may be too much. Depends on your time, equipment and skills. Alternately we can send out another board if you will return yours.

    As for grbl SW support, the place to look is the grbl github. The Issues tab has a pretty active forum with Sonny Jeon (Chamnit) handling the lion’s share opf the requests. github.com/grbl/grbl

    – Alden

    in reply to: Access to TinyG step/dir for larger drivers? #1096
    alden
    Member

    The step and direction pins are not broken out separately as there are not enough IO pins to do this for the way the board is configured. However, if you want to hack the board or the C code this is what I’d recommend.

    – You can grab the TinyG schematics here:
    https://github.com/synthetos/TinyG/blob/master/hardware/board131v6_schematics_pg1.pdf

    – The TI chip pinout is here:
    http://www.ti.com/lit/ds/symlink/drv8811.pdf

    – Repurpose the GPIO2 port (J8 on the schematic) as outputs instead of inputs. You lose some homing inputs, but actually you only need one pin to trigger homing, so you get 7 that can be used for outputs. Bear in mind that these are 3.3v outputs and are not isolated (opto or otherwise) so you need to be careful with them. Alternately you could just take the existing bits that go to the steppers off the board as Freddy has. These are all mapped in system.h. Look at stepper.c to see how they are used.

    Microstepping is an interesting question. Microsteps is a motor parameter that is set in the default profiles for the settingsXXXXXX.h files. The microstep value can be changed from the serial port using the $1mi command (where ‘1’ is the motor number 1-4). This command does 2 things: (1) it sets the _set_motor_steps_per_unit() internal system parameter and (2) it sets the IO bits for the 8811s. You don’t care about (2) but you do care about (1). I have not tested this, but I see no reason you could not enter 10 or 16 which should set (1) correctly for step generation. You may lose some maximum step rate as the steps/sec X microsteps cannot exceed 50,000 (Hz). My examination of the code points out that even though the (2) operation would fail, the system won’t complain, so perhaps I need an error message here, and possibly blocking the (1) action from occurring!

    If you are doing any software hacking I’d wait a few days for version 0.93 to appear on the github site.

    – Alden

    in reply to: Spindle control? #1364
    alden
    Member

    I am about to release version 0.93. I want to hammer it over the weekend and run some final tests. Version 0.93 has spindle and coolant controls implemented (M3,M4,M5 and M7,M8,M9). The exact pin mapping will be on the wiki, but heres the functional pinout:

    – Spindle on/off bit
    – Spindle direction bit
    – Coolant on/off bit

    Coolant is mapped down to a single bit, so mist coolant (M7) and flood coolant (M8) both enable the same bit.

    in reply to: Newby here #1377
    alden
    Member

    The steppers are not locked because the power management mode is on by default. If they were locked the motor LED would be on. This mode is settable by using $nPW=1, or can be turned off by $xPW=0. Where n is the motor number as indicated on the board silkscreen (default mapping is 1=X, 2=Y, 3=Z, 4=A).

    Please note that in version 0.93 (due out shortly) this will change to $nPM. The configuration details can be found here. http://www.synthetos.com/wiki/index.php?title=TinyG:Configuring

    in reply to: CNC build using TinyG #1912
    alden
    Member

    Thanks for you interest and post, and the compliment. I read your blog. We’ll definitely add your project(s) to the list of TinyG projects on the wiki.

    As you look for a beefier power supply let me suggest that you look to provide the motors with 24 volts. You will get much better performance and cooler operation than with a 12 volt supply. You will, of course, still need to supply 5v, but any reasonably regulated 5v supply over 100 ma will do.

    in reply to: grbl is garbling my program #1703
    alden
    Member

    As far as you know is the grblshield hardware working correctly? Do the light’s flash when they are supposed to? One possibility is that you may have current set too high and the chips are going into thermal shutdown. Are the motors firing intermittently, turning on and off or stuttering?

    If you think this is a software issue you might try posting this as an Issue at the grbl forum on github/grbl/grbl.

    – Alden

    in reply to: Odd behaviors – only X axis works #1519
    alden
    Member

    Well congrats on the good news and drat on the bad news. I’m not sure this can be diagnosed over the wire. It doesn’t sound like HW as all the motors work, and it doesn’t sound like firmware as you have a new load. So if you don’t mind, can you send the board back and we’ll swap one in the mail? I’d like the chance to put your board on the bench and see what’s wrong. Riley will follow up with an email in response, if this is OK with you.

    – Alden

    in reply to: Odd behaviors – only X axis works #1517
    alden
    Member

    Matt, Thanks for your patience.

    – Alden

    in reply to: Odd behaviors – only X axis works #1515
    alden
    Member

    Matt, I think we sent you a board with the wrong firmware. The current production firmware is 326.06, not 326.01, which was a release candidate. We apologize for our mistake. Here are your options:

    – Reprogram the board from the correct firmware
    – Send the board back to us and well do it ASAP (and we’ll pay shipping both ways)
    – Send the board back and wait a week or two for the 0.93 firmware
    – Return the board for refund

    To re-program the board from the current production use the master on https://github.com/synthetos/TinyG
    For programming we recommend using AVRStudio4 from Atmel (windows), and an Atmel AVRisp mkII programmer – about $35 from Mouser Electronics. For future upgrades you will want to be able to program the board yourself but I understand if you want a swap.

    We are putting the finishing touches on the 0.93 firmware revision that has automatic status reports, feedholds, multiple coordinate axes (G54-G59), advanced homing and JSON support. But that’s probably a week or so away. Of course if this is all too much we will refund you on board return.

    Again, we apologize for the mistake.

    – Alden

    in reply to: Odd behaviors – only X axis works #1512
    alden
    Member

    Thanks for the detailed explanation. So if you start from a reset and do a seek – g0x100y100z100 do you have the same result?
    (You do know that since Gcode coordinates are absolute (unless G91 is active) that doing another identical move has no effect: issuing a second g0x100y100z100 will not move because the Gcode model is already at those coordinates).

    Can you try the following Gcode blocks (lines) and tell me what’s happening for each one (LEDs, does it move, final position reported by ? cmd)
    <reset>
    g0x100
    y100
    z100
    x0
    y0
    z0
    $2ma0
    $4ma0
    <repeat the above>

    Can you tell me if at any time the Y or Z axis trimpots were over-torqued? They are only supposed to rotate through 270 degrees and can be damaged if forced beyond that.
    Thanks

Viewing 15 posts - 601 through 615 (of 702 total)