Forum Replies Created
-
AuthorPosts
-
alden
MembergrblShield just provides the 3 motors / axes, not the underlying software, which is grbl. There’s been some discussion on this topic at the grbl wiki and issues. I’d check there.
https://github.com/grbl/grbl/wiki
https://github.com/grbl/grbl/issues?direction=desc&sort=created&state=openHope this helps
— Alden
September 19, 2013 at 11:02 pm in reply to: Using TinyG with SSR Relays.. Not Turning On Relays? #4548MemberIm sorry it’s not working and we need to fix this. Please give me a chance to look into this and find a solution. This is going to be hard for the next 7 days or so given the Makerfaire travel and some other things that are happening jn the days that follow. We’d like to get this resolved.
— Alden
September 19, 2013 at 7:17 am in reply to: Help! Firmware flash problem – motor lights on hard #4543MemberGood. The motor power sequencing is a tough one to get right as user requests are somewhat in conflict. There has been a longstanding request for motor power management to power on the motors as soon as the motor power management settings are taken, and not wait until the next move. Having implemented this in 380.05 it means that the motor power will come on at bootup, if you have set $1pm=1 (or 2, or 3, or 4). Then it turns off after the timeout interval ($mt)
I realize this is a change in behavior.
September 18, 2013 at 9:39 pm in reply to: Using TinyG with SSR Relays.. Not Turning On Relays? #4537MemberI would like to check this out further if I may. I traveling (NYC Makerfaire) and won’t be back until late next week but will look into this further then.
September 18, 2013 at 9:36 pm in reply to: Help! Firmware flash problem – motor lights on hard #4536MemberIt sounds like you got the code flashed. That’s the right sequence.
What version of the FW are you flashing?
Do you have problems driving it once it’s flashed? What are you using to drive it?
MemberI would think that the 23’s should get the job done. You can probably max out the current then adjust the jerk so you can get the start you want.
Are you using a high-speed wood router spindle?
Another option (more $) is to take the step/direction/enable breakout from the v8 and drive external drivers, but now you are probably into Geckos or some other solution north of an additional $70 per axis.
FYI – we have been working on driving this with the Beaglebone Black and have some of it working now. Needs more work, of course, but over the next few months…
MemberYou can drive the larger NEMA24 motors, but you won’t be able to deliver the all current they can handle, so you won’t get the additional torque. So you might as well stick with the 23’s, which are presumably cheaper. We have some 4 amp Lin motors on the Probotix v90. Great setup, but I know there’s more in the motors I am not getting.
MemberWell, maybe, maybe not. The limiting factor is the driver’s current capability. The max you can drive into the motor is limited by the drivers themselves, and is 2.5 amps per winding – possibly a tad more with good cooling.
We’ve been playing with some big NEMA34 motors and here’s what we’ve found.
On a NEMA34 rated for 5 amps/winding and 7 Nm (~1000 oz-in) we can drive this fine to about 300-400 oz-in holding torque. More that that and the motor stalls. This is most likely due to the max current that is deliverable being lower than the current that the motor is actually capable of handling.So your NEMA34s will probably work, but you won;t be able to get full rated torque from them.
MemberIt seems you got a prototype v5. These are not for sale yet. But here’s what’s going on and some options for you.
There are 8 pins on J6 on the v5 gShield. If you have an R2 UNO there are only 6 pins on the power connector, meaning the 2 additional pins from the gShield J6 are hanging loose. On an R3 Uno these pins deliver power. The v5 can be made to work on an R2, but you have to move the jumper on J11 from the lowest position to the top position (cut the jumper and add a new one). This will route 5v from the R2 Arduino to the gShield.
The other option is to return the v5 for a v4. We’ll pay for all shipping as its our mistake.
MemberNo sample code, but I highly recommend using the JSON mode if this is what you are looking to do. Set up a status report with all the variables you want to track and set status verbosity to filtered. This way you will receive reports when any of these values change, and you can receive timed reports during movement by setting the status interval (e.g. 250 milliseconds for 4 reports / second)
–Alden
MemberThanks. I think you found a condition we should try to trap. Sorry you had a problem, but glad it’s working now.
Alden
MemberCan you please run the $defa=1 command again then capture the $$ output? I would like to see if the board resets to a known state.
Thanks
Alden
MemberI’m not sure what’s going on, but here are a few things to try.
– Once you set $defa=1 do a $$ and see if the $xvm, $xfr and similar for Y and Z are non-zero and reasonable.
– Turn off all your limit switches – set them to zero. Also, set the switch type to Normally Open (you have it at normally closed). If you have NC switches enabled and limit switches enabled the machine might always think it hit a limit and not move.
– Try moving a short G1. Like G1 f100 x5
– Set power management on the motors to 0. This is more normal for a belt machine (do you have a belt machine?).
– Disable the A axis (axis mode = 0). Just to take Radius mode out of the equation.
MemberFirst, try typing in the following:
$xvm=3000If that doesn’t work try running the following command:
$defa=1This will reset the settings to defaults
MemberI think your problem is that X velocity maximum is set to 0.
[xvm] x velocity maximum 0.000 mm/min
-
AuthorPosts
