Open Extremator1 opened 7 years ago
chamnit
commented
7 years ago @Extremator1 : That would be feasible and pretty quick to implement. It could run independently of the main serial channel so existing GUIs would still work. However, the communication protocol doesn't really let GUIs know when a realtime command executes. So, GUIs may get confused if they are written to account for this well.
Extremator1
commented
7 years ago A-ha... Yes... conflict-free synchronization between the two channels is the issue ... But what horizons will open if to solve this problem. We can do jogging by hardware buttons or joystick or hand rotary encoder. We can adjust the speed and feed by potentiometers, just like on professional machines. We can control the automatic changer tool if there is one. We can tie some PLC logic to electrical equipment of CNC machine, etc. Breathtaking!
Need to do something with sync.
shooter64738
commented
6 years ago I do a few of those things with mine. I have grbl running on a mega, and I have a second mega connected to it, but I did not use serial. My software (which has no name) loads gcode via serial, parses it, converts canned cycles to regular gcode, loads tool offsets, so forth. (theres a ton of room left on it right now for other things as well) It then passes that gcode data on to the grbl board. I can fit a pretty good sized gcode file in memory too..
But then it gets drastically different from what others have done. I read the pulse and direction outputs on the the grbl board with my software to know where it has moved too all the time. I can jog it when its idle using jog controls from my board, I can sync (to within 1 pulse) a rotary axis with the grbl linear axis, even well enough to mill some threads on a rod using grbl. The trick for me was reading the grbl output on the output pins, not via serial communication. Because this adds zero overhead to grbl, it was going to set the pulse and direction to drive the steppers anyway.
I would imagine if you have an encoder on a spindle and controlled the spindle speed with the second board you could do rigid tapping the same way. The tap just needs to rotate at a specific speed depending on the rate at which the z is feeding down. Then reverse it to the matching speed when the z retracts.
The only issue I have yet to resolve to make this sync almost perfect is to know exactly which motion plan the line is on. Since I have read the gcode already, manipulated it for offsets or canned cycles, I know whats going to execute and in what order. But determining which one of those lines is active in the planner and which one just finished is tough. All I need is to pulse another digital pin so that my board knows 'we are on line1, line2, line3, etc... ' So far I havent had too much trouble with it but I keep tweaking and hunting for that one piece in grbl that i can change so that my board knows where its at in the planner. And maybe I dont need to do that, but looking at the code it seems like that might be an issue.
Aside from that I can see where the tool is at, and what line of gcode is currently executing, all with no serial tx/rx (aside from sending the gcode to grbl via serial obviously)
109JB
commented
6 years ago That all sounds great, but your description of rigid tapping is contrary to how it is usually done. Usually the spindle is not controlled precisely like the axes are, so an encoder is added to the spindle and the axis follows the spindle rotation. This way the spindle can speed up and slow down under the load of tapping and the z-axis compensates.
shooter64738
commented
6 years ago While I agree, theres not a spindle sync currently that I was aware of. I was trying to think of a way using existing code and not overloading grbl further.
I am mostly exploring non serial methods to sync motions/actions together between boards, and what I could accomplish by doing that.
chamnit
commented
6 years ago @shooter64738 : With Grbl moving onto ARM, I'm not worried about overloading Grbl with things like rigid tapping. I'm quite interested in coming up with the right solution that will help facilitate this, but I'm not sure what the correct approach yet.
If @109JB is right about the axes adjusting to the spindle, Grbl will need to tightly integrate the path planner with the spindle realtime state. Doable with lots of code refactoring, but could get really difficult with tighter sync requirements. However, I suspect that adjusting the axes to the spindle might be done this way to maximize productivity. For hobbyist, this may not be as important. Plus, the axes motors and spindle would likely need to be precisely spec'd together to get maximum performance out of them. Hard to do without a lot of experience with this.
I think your approach is easier to deal with. The main requirement is ensuring your spindle can maintain and change the rpm under load and with the axes acceleration. This would slow the job time down, likely considerably, but doesn't require any major changes to Grbl's planner itself.
Anyhow, I'm open to suggestions on how to deal with spindle sync and rigid tapping. However, let's do it on a new thread.
109JB
commented
6 years ago In order to have the spindle track the axis in rigid tapping would require the spindle to be able to very very closely adjust rpm to match the desired rotation. This would require the spindle to be something like a servo driven spindle. They do exist, but on most homemade or converted CNC machines, the spindle is not a servo, but a common motor with an encoder of some kind added to the spindle shaft.
For example, LinuxCNC allows lathe threading using only a single index pulse on the lathe spindle and you can use the single speed induction motor that came with the manual lathe that was converted. The RPM is anything but precise and can vary a bit with the cutting load. LinuxCNC uses the index pulse to gauge how fast to feed the lathe Z-axis to achieve the desired feed/ rev. It also uses the index pulse to gauge when to start the feed because in the case of lathe multiple pass threading, each successive pass must follow the previous pass exactly.
For milling machine rigid tapping the same is true regarding spindle motors, except that LinuxCNC has to be able to stop and reverse the motor. In regard to the encoder for rigid tapping, it must be a quadrature encoder with index pulse. It needs to be a quadrature so that LinuxCNC can not only detect speed, but direction, and the index pulse is needed again to start the feed at exactly the same time. A machine that can rigid tap should be able to feed the tap through the same hole multiple times and have the tap follow the previous threads exactly.
The link below is to a video of gear hobbing using LinuxCNC. Just about the 45 second mark of the video the gentleman talks about the 4th axis being "geared to the spindle in software". This is essentially what is done for rigid tapping as well in that the mill Z-axis would be geared to the spindle when a tapping command is issued and then un-geared once complete. Note that the gentleman in the video turns the spindle by hand and the 4th axis follows the spindle rotation as the spindle is rotated back and forth. In terms of gear hobbing, the 4th axis and spindle are "geared" essentially permanantly, but for rigid tapping the gearing is turned on and off by the g-code, but the principal is essentially the same. The encoder on the spindle shown in the video is essentially a homemade quadrature encoder using optical switches and a slotted disk.
Hello everyone!
Grbl is a great project! Many thanks to all the authors and participants! Now, with grbl-Mega are opening new opportunities.
What about creating a second UART-channel for Realtime and Extended Realtime commands? This will allow us to do an optional hardware control panels, with buttons, lamps and POTs (with addition Arduino, of course).