Forum Replies Created
-
AuthorPosts
-
aldenMember
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.
aldenMemberI’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.
aldenMemberYes, 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
aldenMemberRiley has been making good progress on this. You and he should connect up about the JavaFX development.
aldenMemberWhat version of grbl are you running and from what source? Here’s the official source and our wiki page about getting grbl
aldenMemberThis 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
aldenMemberThe 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
aldenMemberI 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 bitCoolant is mapped down to a single bit, so mist coolant (M7) and flood coolant (M8) both enable the same bit.
aldenMemberThe 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
aldenMemberThanks 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.
aldenMemberAs 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
aldenMemberWell 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
aldenMemberMatt, Thanks for your patience.
– Alden
aldenMemberMatt, 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 refundTo 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
aldenMemberThanks 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 -
AuthorPosts