Forum Replies Created
-
AuthorPosts
-
aldenMember
Bart,
This motor should be fine if you wire it up in series mode. The drivers on grblshield are Texas Instruments DRV8811’s which are bipolar drivers that can supply up to 2.5 amps per phase. The data sheet for the drivers is on our github:
https://github.com/synthetos/grblShield/tree/master/referencesSo as long as you wire the motors in series mode they will take a max of 2.1 amps per phase. The wiring for series is on the motor data sheet you referenced. Series wiring means that the ends of each coil are wired to the plug, and middle leg of each phase are floating (unattached to anything) (I realized that this last statement may be confusing – Referencing the motor data sheet – the “middle wire” is the blue-connected-to-yellow, and the brown-connected-to-orange. Many unipolars are 6 wire, looks like this one is 8 wire where the above connections connect the middle. It would be easier to explain if I could draw a picture).
Let us know how your project goes. – Alden
aldenMemberIt’s in stock now. We’ll switch the message back on the store shortly.
aldenMemberI’m afraid I don’t know what’s going on with your verification error. I suggest starting with the instructions for loading grbl onto the Arduino. If there’s still an issue you might post an issue to the grbl project github issues.
You are not the only one we’ve heard who has had some issues getting grbl onto the Arduino using AVRdude, but please persevere. It is possible and once you get through it you can do a lot. We are working on a solution to make that part of the process go much more smoothly but we don’t have it ready yet.
aldenMember<advertising_mode>
This is actually the forum for the grblshield, which is a spiffy single board solution that replaces the Reprap drivers and all those wires with a single 3 axis stepper controller that plugs right on top of your arduino. Simple, convenient, cost effective and lasts a long time.
</advertising_mode>Seriously, I’d look over on the grbl github Issues list for an answer to this one. I have not used the end stops in grbl so I can’t help from personal experience. The grbl github is here: https://github.com/simen/grbl
aldenMemberIt seems straightforward but I gather that backlash compensation can do some nasty things to line planning – or to the jerk on the machine if you don’t control it. Take the case of a 360 degree circle in XY. There are points at the 4 quadrants where the direction in X or Y reverses. Backlash compensation would cause the nice, smooth planned circle to jump 0.5mm to the left, right, up or down. This looks to the line planner as a 90 degree turn – followed immediately by another 90 degree turn (but the machine shouldn’t be loaded – because it’s traveling through the slop region). The planner would like to slow down to a velocity that it can make the corner, then speed up momentarily through the correction line, then slow down again for the end of the correcting line. If it does this it will cause the tool to go though a dip in velocity at the quadrants, and will affect the smoothness of the cut. The alternative – not slowing down – is worse, as the tool will try to move “instantaneously”, and cause a stepper to drop steps, or jerk the table and rough-up the cut accordingly. I imagine the right answer is going to be somewhere in between those two extremes, and may require some special detection or handling aside from normal line planning. Anyway, I plan to have a go at it, but I do think it will be challenging.
aldenMemberI’ve been looking into adding backlash compensation into TinyG at the firmware level. At first glance it seems straightforward, but as you read more about it getting backlash compensation at speed and under load requires some real tricks to control jerk (You might not know that TinyG implements the “real” 3rd order jerk equations of motion to control tangential and centripetal jerk to set maxima for each axis. And if I can get through a few things this weekend we’ll get the first 24 production units in the store early next week. FInally! But I digress.) So I’d like to say I’ll get backlash compensation into TinyG relatively soon, I want to be cautious about this statement.
aldenMemberThanks for the info. I’m inspired to do my conversion. AFAIK the higher to voltages don’t actually mean any more torque, but they do make the motors and chips run cooler as there is less time in switching – which is where the power is consumed (wasted). We have driven the drivers over 2.5A with fan cooling, but they are not happy about it (they get hot, but still work). Below 2.5 a is good – assuming you cool it well. We also have found some nice heatsinks for the little chips; they will go on the site soon as well.- Alden
aldenMemberThanks for the note. You may notice that grblshield is really just 3/4 of TinyG, minus the Xmega and USB. Coincidence? (not).
I’m inspired that you got the Rong-Fu working with it. I’ve got a Grizzly G0619 that I’ve been spooked to convert for some time now. If you don’t mind, I’m curious about your conversion. Did you work from plans or do it on your own, and do you have a parts list or even some sources you recommend? (I can add any sources to the HacDC suppliers page – which is a nice resource: http://wiki.hacdc.org/index.php/Suppliers). I particular, what motors did you use, and did you find you got enough torque with your gearing?
We just got the first production TinyG boards a couple of days ago. They will go out on the site soon. Riley is putting the finishing touches (initial finishing touches; finishing initial touches?) on a really nice Python control program that drives both grbl and TinyG. It won’t do a drawing preview (yet) but it does most everything else we’ve wanted. In the mean time, TinyG implements XON/XOFF protocol and I’ve worked with the author of CoolTerm (Roger Meier) to get CoolTerm working really well with it (native on Mac and PC). You can run TinyG from the command line and also stream files down to it. Beware – right now only the beta (v1.4x) works for streaming files – there was a really nasty bug that Roger fixed – but I’m not sure it’s made it’s way out to the general release of CoolTerm which I think is still 1.3x It bears repeating that while you can use CoolTerm to issues commands to grbl, you can’t use it
to stream files (no XON.XOFF). Riley’s program will work with either system.aldenMemberWow! This is amazing. Really nice work. How long have you been working on this? I hope you don’t mind me putting this on the grblshield wiki projects page. – Alden
aldenMembergrbl offers a ruby script in the /script directory to feed files to grbl. We (Synthetos) are also working on a console program to be released shortly that will work with both grbl and with TinyG, but it’s not public yet. Neither generates tool path preview, and I’ve not explored what’s out there for this – but there are a number of Gcode previewers out there if you hunt around. If you find a good one please post.
aldenMemberI don’t know the status of the grblshield changes in the v0_6b 168 package. Here’s the background.
We submitted a pull request to the grbl project on March 1, 2011 that was incorporated into the edge branch sometime later. You can find the details by looking at the closed pull requests in the edge branch on the grbl github. The changes were:
– Changed the default invert mask in settings.c to 0x1C to support active LO stepper drivers
– Changed stepper enable to be active LO in steppers.c/.h
This is the most crucial change. If you look for occurrences of STEPPERS_DISABLE_BIT in steppers.c in the edge branch you will see what grbl changed that to. (It’s different than what we had in the pull request, but gets the job done… so no matter)– We also did some things with the serial read to make it work in an WinAVR/AVRStudio environment.
We have not made a 168 version of the patched grblshield code and to my knowledge the grblshield patches have not been incorporated into the grbl master branch or the v0_51 branch. AFAIK the v0_51 is the only one that supports the 168 – which is now considered legacy by grbl.
If you wanted to hack the v0_51 branch for the grblshield patch you should look at the above changes applied to the edge branch and make at least the first 2 to the v0_51 branch
Or just wait for your 368 to arrive. 🙂
Hope this helps
Alden
aldenMemberThe motors you are using are slightly over the edge of the power handling capacity of the board. The driver chips are rated at 2.5 amps per phase maximum – the motors you are using are 2.8 amps per phase. These might work, but you will have to pay attention to cooling. Use a fan.
You can try using the 2.8 amp Kelings, as long as you have them. If the motors are too much for the drivers to handle the drivers will go into thermal shutdown and the motors will stutter or shut off. So far I have not managed to kill the drivers with overly large motors (and I’ve tried); but no gurantees. I’m running a Probotix Fireball with some 4 amp / phase motors. The chips run hot, but they do run. The caveat is that I have not done any really heavy cutting to properly load the things yet.
The board is rated to 30v because the capacitors are 35v caps. If you run them at 36v you run the risk of blowing the caps. I usually run at 24v, or dial down a 36v or 48v adjustable supply to 30v. The amperage needs to be sufficient for your moves – worst case 6x what a winding takes, but in reality it’s somewhat less than that as it’s unusual to get all 3 motors running at full cutting load.
Alden
aldenMemberJohn, These are all good ideas. Have you posted your items to Issues on the grbl github? https://github.com/simen/grbl/
We only developed the grblshield to run on top of grbl, and are not the authors of grbl itself. A number of people have forked grbl and are making various modifications, and the project itself moves along as well. You might get better response posting to those forums – and it’s also possible that one of the grbl forks is addressing these items.
It’s possible to sync on grbl’s ‘ok’ return prompt. When you receive that it’s OK to send the next Gcode block (line) without overrunning the buffers Also, I think there’s a Ruby script on the grbl site that streams to grbl.
Alden
aldenMemberJohn, You should have no problem with 1.4A motors – I have driven much larger with and without heatsinks. We are putting some heatsinks on the site soon. We found some copper heatsinks used for RAM cooling by case modders. These work pretty well.
We also looked at underside mounted solutions, but there’s not much room between the boards – especially with the ISP programming header sticking up off the Arduino.
If you have any issues with heat you will know it – as the driver chips will cycle on and off due to thermal shutdown – or even stutter in extreme cases. In most cases this means you have your current set too high and are overdriving the motors. Back it off until the stuttering stops, then check your torque. You should still have plenty. The chips may run hot, but this is expected.
The most effective cooling is to use a fan. Blow some air across the board and through the gap between the Arduino and the board. This actually makes much more difference than any heatsinks we’ve tried – including the monster on the TInyG board. However, at 1.4 amps you should not need this.
Also (ironically) the motors run cooler with higher voltages as the power electronics spend less time in switching. So running at 24v will provide better motor operation and cooler chips than running at 12v.
Alden
aldenMemberI agree. We are thinking about either making a pre-programmed 328 DIP chip available, or just selling a pre programmed Arduino – possibly both. Do you have a preference? There’s less chance for an inexperienced user to have problems with the pre-programmed Arduino, but of course it would cost more.
Also, we are planning to put motor plug kits and some neat heat sinks for sale on the site as well.
Alden
-
AuthorPosts