alden

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/references

So 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

I’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.

It 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.

Thanks 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

Wow! 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

I 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

John, 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

I 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