Would like servo control for pen lift vs spindle stepper

[Shornone]

@jasonwebb there are some arduino 328 grbl forks that have reworked the 'spindle_control.c' to provide servo control for the pen lift. I just got a Mega for building a second wall plotter. The servo is good for keeping the pen gondola mass low.

https://github.com/robottini/grbl-servo

http://www.buildlog.net/blog/2017/08/using-grbls-spindle-pwm-to-control-a-servo/

[jasonwebb]

Yes! Servo control is planned, and I actually just did the initial work a couple days ago - crazy timing. It's not committed yet, because I haven't even tested out the work I've already done with a live system.

robottini's repo is kind of borked, so it's really hard to tell what modifications he did in his implementation. But from what I've gathered so far, I think there are better ways to do it.

I like the implementation that cprezzi did, which is to extend grbl's spindle code with a switchable 'servo as spindle' mode flag. Much cleaner, I think. https://github.com/cprezzi/grbl-servo

The trouble with both approaches comes when generating G-code for the machine. I want to use standard CAD/CAM tools like Fusion 360 to generate G-code, but it is not standard to use a servo with an up/down state instead of a stepper motor in the CNC world.

It'll be super easy to generate toolpaths that 'retract' the Z axis while moving between disconnected paths, so my intuition is to conditionally 'hijack' these Z axis change G-codes and instead actuate the servo when that 'use servo as spindle' flag is used.

Also worth noting is that a servo may not strictly be the only option here, but is so common that it's important to support. Turns out there are such things as 'micro' stepper motors that are comparable in weight to servos, which Grbl could support out-of-the-box. That might also enable varying degrees of contact with the paper for weird effects. And they are adorable: https://www.pololu.com/product/1204

[jasonwebb]

Brain fart moment! It just dawned on me that the Arduino Mega (ATmega2560 microcontroller) has 3 more timers than the ATmega328, which means that the servo could easily run on it's own dedicated timer, rather than have to share one with the spindle. Just means even easier work for me! Also means I need to revert the local changes I started working on, haha.

[Shornone]

Cool. Yeah I agree with you that the servo may not be the only option. Part of why I like the servo is that grbl cnc boards and the RAMPS board have dedicated servo connections with integral 5v power. I can then run a dedicated wall wart for the heavier stepper motor requirements.

I do like that micro stepper [I would need a 2nd voltage supply for it]. I have a new RAMPS 1.5 board coming in this weekend. With the Superbowl I may not get much setup done, but I might breadboard it up and at least tune the current feedback on the stepper drivers (keeps them from getting hot and keeps the noise down).

From your tweet- Yes - absolutely I think there could be a benefit in collaborating. I am good with hardware not so much with software, but I will gladly share what I am doing with my setup.

If you don't already know about it- the RAMPs 1.4 board has a thermal pad error see: http://reprap.org/wiki/RAMPS_1.4

[just-jason]

The trouble with both approaches comes when generating G-code for the machine. I want to use standard CAD/CAM tools like Fusion 360 to generate G-code, but it is not standard to use a servo with an up/down state instead of a stepper motor in the CNC world.
It'll be super easy to generate toolpaths that 'retract' the Z axis while moving between disconnected paths, so my intuition is to conditionally 'hijack' these Z axis change G-codes and instead actuate the servo when that 'use servo as spindle' flag is used.

I am all for using a servo too. I think there could be a way to look at the problem differently. It is true that it is supper easy to generate Z retract moves when creating G Codes in Fusion etc. What seems more useful than this process of hijacking the Z moves , is watching out for the G0 codes that are generated during travel moves, and G1 codes that are linked to the " cutting " ( in this case drawing ) moves. They are much more reliable for filtering out what is pen up or pen down. What do you think of this idea?

[ithinkido]

Could this be useful?
https://github.com/bdring/Grbl_Pen_Servo

[CCERocks]

im lost here... So now this firmware compatible with Servo Motor?

[jasonwebb]

Sorry @CCERocks, at this time this particular project (grbl-mega-wall-plotter) does not support servo motors.