Home › Forums › gShield › grblShield Support › limit switch/spindle control support ?
- This topic has 18 replies, 3 voices, and was last updated 13 years, 4 months ago by
alden.
-
AuthorPosts
-
May 2, 2011 at 6:25 pm #1754
thibalte
MemberHi,
Spindle Control and Limit Switches are not supported in the current version of Grbl though in another thread I could read your build of Grbl adapted for the shield already support the limit switches on pin 9-10-11, how about Spindle Control ?
I would like to connect my drill power to a relay to switch it on/off automatically, browsing through the github repository i could find some spindle control-related files.
Is it already integrated in your version of Grbl? is there an enable pin working? I’m waiting to receive my shield and have been thinking of other ways to switch off/on the drill but it would make it more simple.
Btw, if i connect the limit switches on port 9-10-11 does the G28 (Go Home) function works straight ? nothing to set up ? does it work in Incremental mode as well ?
sorry for all the questions, I’m new to G-Code, thanks a lot!
May 5, 2011 at 6:16 pm #1755dkirtley
MemberIt probably doesn’t make that much sense to handle just a spindle enable, just flip the switch. For a full implementation, you would want a direction as well. Then maybe a PWM output to set the speed, maybe a tool changer, coolant, dust collection, auxiliary power supply, cooling fans,….. It goes on and on. They are already cramming a bunch of stuff in on what can be done with the base Arduino. I think a better option would be to build a separate spindle controller to fit the type of spindle (and possibly handle homing, coolant, and limit stuff separately as well.) The whole beauty of changing away from the parallel port is that you can easily have multiple devices. USB is a bus. Plug in another controller.
Your program to communicate to the Arduino doesn’t *have* to just dump code to the serial port. Have it take a look at each line and make some decisions. Looking at gcode.c, everything that is not implemented in grbl could be done with a pre-processor except additional axes (and you might even be able to do that if you were careful). All the icky stuff like acceleration, arcs, step timing and such are already there.
May 8, 2011 at 6:33 am #1756Memberyes I do agree that to take care of all the rest aside the movements an auxiliary controller might be a better choice. I’m asking this because Im using Grbl to control an art installation that should run by itself and be able to start/stop the spindle when it needs to mill something, the data milled would come dynamically via network. I dont want to let the drill run continuously, and since I’ve been able to see that anyway spindle control and limit switches (homing) are on the roadmap of the Grbl project I just want to know more about it. From what I know the Grblshield-compatible build support already the homing functions but I couldnt find any tips about it..
I just want to know what exactly does support the grblshield build. Otherwise I’ll build my own .hex from the Experimental branch on the github repository, what are the requirements for it to work well with the Grblshield ?
thanks a lot!
May 8, 2011 at 9:49 am #1757MemberOf course this whole tool chain is new to my as I have previously just been playing with the arduino IDE and not directly with the AVR stuff. I have not seen the actual code for the .hex that the designers here have modified but the repository just flips DDRB bit 6. This *should* be digital pin 13.
Unless someone posts the config used for the build, the easiest thing would just be hook an LED to 8 through 13 and send gcode for turning on and off the spindle and see if it turns them on and off.
May 8, 2011 at 11:00 am #1758alden
MemberI’m in the process of posting the whole project on the Synthetos grblshield github. [https://github.com/synthetos/grblShield] It was out there before but I want to verify a few things and organize it better. I’m hoping to get this done today. I’ll also have the schematics out there which should answer some of the other questions. — Alden
May 8, 2011 at 11:34 am #1759MemberJust out of curiosity, with this fork are you planning on back porting from the official branch of the grbl code? All grblshield really needs is to maintain the config.c to match the hard wired definitions. That would be a lot less work to keep synced. That is an awful lot of bit twiddling to maintain.
May 8, 2011 at 12:26 pm #1760MemberI’d prefer to get the patches back into the official project, and have posted a pull request, so that’s the preferred way. There are actually no changes in config.c – grblshield maps directly on to the 0.6 grbl pinout – if I understand your point correctly. The changes are in a few other places in the code involving bit polarities and a minor character read bug. See the readme in https://github.com/synthetos/grblShield/tree/master/firmware. We also want to post a number of other materials related to the hardware and some upper-layer software, so I just created a firmware directory for the grbl patches.
May 8, 2011 at 1:01 pm #1761MemberOk nice, i’ll wait to have a look at that grblshield repository to know exactly what it does!
thanks
May 8, 2011 at 1:04 pm #1762MemberIs the grblshield code from the main branch or the edge branch?
May 8, 2011 at 1:10 pm #1763Memberyup same here, actually if the build is made from the edge branch everything i need is already supported!
May 8, 2011 at 1:14 pm #1764Memberfrom what i can read in the github repository of the grblshield firmware it’s based on the Edge branch, so homing and spindle are actually already supported.
So its perfect for my needs, i just recieved the shield yesterday, recieving the steppers tomorrow, everything perfect then! 🙂
May 8, 2011 at 1:46 pm #1765MemberCool, I guess I will have to solder on some headers when I get to work tomorrow 🙂
Part of my problem has been getting used to the tool chain and repository. I didn’t realize from the web interface on github that there were even different branches available before it was pointed out here. I had only seen the main branch.
May 8, 2011 at 2:07 pm #1766MemberIt’s from the edge branch. As for toolchains, I’ve been using the AVRstudio4 Win-AVR GCC toolchain from Atmel. It’s windows only but I’ve had no problems running it on OSX from a VMWare image of Windows XP. You should have no problems with it as long as you use optimization level -Os (which you need to fit the code onto the 386p).
It uses an older version of the avr libc.a (version 1.6.7) which has caused me some subtle problems on another project (tinyg), but only when I used unoptimized mode. I’ve tried the AVRstudio5 beta that uses the newer libc (version 1.7.1) that fixes the libc bugs, but I find the AvrStudio5 beta still too buggy for real use. So I’m attempting to port the newer libc back into AS4 (plural – there are about 20 varieties of them!). Should be straightforward, but these things usually aren’t. If I get it working I’ll put out a blog about it as I’m not the only one with these issues, I expect.
May 8, 2011 at 7:35 pm #1767Memberok, that’s nice, but from my understanding, since the current grblshield build .hex is based on the most advanced (edge) version of Grbl there is no point into building my own since im burning the firmware on a regular atmega328, right?
May 8, 2011 at 10:02 pm #1768MemberThat’s correct. The hex is out there as a convenience so you don’t have to go through all this. Unless you want to make your own mods to the code. Please also be aware that we have tested it on the 328p. It will not work (fit) on a 168, and the current grbl release does not support the Arduino Mega (atmega1280). We are looking into some issues there as well.
-
AuthorPosts
- You must be logged in to reply to this topic.
