Marlin firmware running CNC mill

[Alex Gibson]

http://www.youtube.com/watch?v=ibqwF8zZ2OE

Any ideas how to kill this jerky movement? I think my RepRap running the same firmware (original TVRRUG firmware) dies the same thing - just less pronounced. Did anyone solve this issue?

I talked with Bo about porting to later Marlin, it would be worth doing it out if scope right now!



Tapped on my mobile phone.

[Stuart Livings]

Can the stepper drivers microstep? Might just be a large step size?

Stuart

[Alex Gibson]

It's the Toshiba Stepper drivers from the Round 2 TVRR kit. So yes they do micro step, I believe.

The reason for uploading the video is you can distinctly hear the different phases of the movement - the main middle section is fine, but the initial jerk, acceleration and deceleration phases are very clunky indeed.

Would micro stepping issues cause this? Are there ideal jumper settings on the DSMs that would help?

Should mention that I want to solve this both personally, for my RepRap and for this CNC, which I am building through my consultancy for Yossi's business. Not that there's any budget as a result, just being open, and it's a source of time pressure to fix which may mean I switch to an alternative board, which would be a pity as I chose the OMC specifically for the strong Toshiba drivers...

Cheers
Alex

Tapped on my mobile phone.

> --
>
> --- You received this message because you are subscribed to the Google Groups "TVRepRapUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tvreprapug+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Malcolm Napier]

Aren't the jumper settings documented on the TVRRUG web site?

[daprigoo]

I've never seen this problem on the three TVRUGG R2/3 printers I've built.

In the case of the CNC and the video it would appear you are using NEMA
17 steppers, I would wonder if these powerful enough for the load you
are trying to movek, are they getting enough current and what step rate
are you demanding of them.

[Alex Gibson]

They are currently set exactly per the TVRRUG website...

Tapped on my mobile phone.

[Alex Gibson]

Hi, there are 2 nema 17s, one at each end of the lead screws for x and y.

The step rate is low...

Tapped on my mobile phone.

[richard....@btinternet.com]

Are you saying you have two steppers rigidly connected on the same leadscrew ?
Are they driven from same or different driver . Both are bad, but in different ways.
Are you using the motors as bearings for the leadscrew ? Or are there additional radial and thrust bearings ?

[Alex Gibson]

Each of the x and y leadscrew has the same setup:

Tr10x2 leadscrew, with a NEMA17 stepper at each end. The steppers are rigidly mounted.

At one end of each axis is a more rigid connector (metal/polyurethane). At the other is a spiral aluminium flexible connector.

I did run into big issues when I accidentally had the y axis using a rigid coupler opposite the PU bearing. Now it is in line with the x axis, with the flexible coupler, the movement is smooth.

The jerking you see in the video seems not to be mechanical in origin - it's precisely repeatable anywhere along the axis, whereas mechanical issues I had previously would vary along the travel.

I am now trying to better understand how Marlin deals with stepping and acceleration.

Tapped on my mobile phone.

[Richard Ibbotson]

This all sounds like a really bad design especially for a CNC. Who is selling this setup ?
Can the supplier confirm it does actually work ? The suggestion of a "more rigid" connector suggests that movement in the axis is used to compensate for the problem which would compromise accuracy under load.
Steppers as bearings are really bad. The leadscrew should be mounted with proper radial and thrust bearings accurate to the expected accuracy of the machine. A single stepper should drive this through a single stepper motor driver.
Multiple steppers on the same shaft is very bad; lost torque, lost accuracy and lost steps.
Stepper motors are sensitive devices, and this design seems to abuse them in every possible way.
Does your supplier have a forum where you can ask about this ?. Is this design working for anyone else there ?

[al...@alexgibson.net]

Well, that's me told. The supplier is me.

I will ensure my customer is aware of the potential deficits you raise,
but I believe at the budget and accuracy levels expected, the current
configuration will be acceptable. Or, I have an excellent refund
policy. I don't have the same luxury, as my kit supplier proved highly
unreliable and we converted a belt driven design to leadscrew as part of
this project.

I believe the electromechanical setup of the machine is not directly
responsible for the observed behaviour, unless you're aware of a
possible cause?

So, the original question remains, what is Marlin actually doing during
the jerk, acceleration and travel phases to cause this jerking
behaviour?

Cheers
Alex

[Richard Ibbotson]

Sorry, didn't realise the mechanics were an experiment too. I thought you were just experimenting with the different motor driver on stock mechanics
What is your target specification for the X and Y ? When I did stuff like this for work, my mechanical engineers would shudder at using stepper as bearings, but I guess if you can live with linear accuracies worse than .1mm and some compromise on lifetime, then you could get away with it.
I can assure you that steppers are very much more complex than they appear. At first sght they lock so digital, but are in fact very analogue in behavior. All our stepper and stepper driver manufacturers would never specify performance if stepper were ganged together mechanically or if multiple stepper motors were used with a single driver. All our attempts to actually do this resulted in faulty performance, some obvious, but often very random and very hard to find.The costs of testing and refining meant we eventually stuck to the design rules and well within specifications.
Even sticking to the rules we had some big challenges with steppers, because we could not tolerate one lost step per million. Sometimes problems would occur only occur in very specific work sequences due to resonance problems. We sometimes had to resort to servos instead, especially with leadscrew loads.
So if you do push the motors outside the boundaries as you propose, make sure you know your target specification and be prepared to do a lot of testing.
To eliminate the mechanics, I would suggest you replace one motor with a plain bearing just to check, even temporarily. If one motor won't drive the axis under no milling load, then it ain't going to work under load anyway.
Also expect very different performance characteristics from steppers with leadscrews compared to belts
Good luck,
Richard

[Eric Rowen]

Having a stepper at each end and rigidly connected (or not) suggests that if there is any very small difference in the performance of the two motors, even if wired to the same driver (but possibly worse if wired to different drivers) then they will fight each other in a big way, most of these motors are quite powerful and capable of very small precise steps (their whole reason for existence) so having two rigidly connected that are even  a thou out of sync means they will try and twist the lead screw.  The difference could be due to the way they are wired, the way the wiring is run, how long the wiring is and if it is a different length between the two motors if run from the same driver.  If run from different drivers compound everything.  Being rigid the difference could simply be the way they are connected mechanically i.e. imagine one twisted clockwise in the coupler the other anticlockwise in its coupler, this could cause them to be slightly out of sync. 

The case where two motors drive a bed via different lead screws is different, this would cause the bed to raise of lower is a see-saw (or possibly tilted) way that you would not see or see the effect of..........although that is an interesting thought as to a slight defect in say 3D printing !  

Lots of people also have their preferences on couplings too, a subject in itself. 

[Ian Stratford]

I agree with Richard, having two steppers at each end of the leadscrew is asking for trouble. They're probably fighting each other. Are each pair of steppers wired to a single stepper driver? In series, or in parallel? If you've wired them in parallel, they'll be getting half the current, and so half the torque, and I'd expect it to struggle moving a big axis. Either double the current, or wire in series. Also, what microstepping? Increasing the microstepping reduces the torque, and they may fail to move at some points between the steps. Try running them on full/half/quarter/eighth stepping, rather than sixteenth.

Ultimately, it would be much more sensible to get a motor that suits the application. For help working this out, and a good guide to how stepper motors work, see: http://www.geckodrive.com/support/step-motor-basics.html

Ian S.

[Richard Ibbotson]

I am still very much against driving multiple steppers from a single driver, whether serial or parallel. I guess part of this is because talking to proper old school stepper driver designers they were so appalled at the idea. I hope we can be more flexible for needs, but these guys knew their stuff, and when I see some the crap stepper designs today, I do wonder how to balance cheap to nasty.

When you put current probes on even a single stepper the winding current profile is very complex and very dynamically load dependant. When there are two motors then the picture is a whole world of ugly. We could never truly correlate the random failures we were having  to the weird measurements, our suppliers shouted "no way", so we just avoided the problem. Series connecton helps the DC current management to some extent, but you lose on di/dt and they still interact dynamicallyin crap ways

For microsteps, I would suggest it is not required anyways. With a 2mm pitch leadscrew, then 200 steps per rev is .01mm. I doubt the mechanical assembly described will be measurably capable of better than +/- .4mm on the Y axis under a milling load, so not needing microsteps anyways. Microstepping should not actually lose proper steps, but is a waste of processing for no value and suggests a false sense of accuracy.

[Alex Gibson]

All food for thought.

I have taken the machine back as for this and other reasons, it was not possible to guarantee a professional outcome in a short enough timescale, so sorting it out becomes a personal job.

One very prevalent machine drives an axis with 2 motors - the Prusa Mendel.  Here the leadscrews are separate and the connection is electrical. 

As in the Prusa, When you have the 2 steppers wired in parallel and unpowered, if you manually twist both and vary the speed of one, you can feel the assistance given by its generation of electricity in the other.

I *assumed* that in the case of 2 wired in parallel and sharing a leadscrew, there would be the same sympathetic relationship, which would by and large help to keep them in sync.

There would undoubtably be an element of hysteresis, which would add to the noise. although there may also be cases where a nearly missed step in one motor could be avoided by the successful step in the other.  

One positive benefit I was advised of was to avoid the phenomenon of racking by having a balanced system. 

Having the flexible coupler may or may not be sufficient to damp any negative harmonics.  I can only test, once the software side is fixed.  

What I can say from testing to date is that the machine was capable of smooth movement along the axis while driven by 2 motors, and it was hard to manually stop the axis.  So until I can test actually cutting a shape, there is no obvious problem.  

The issue I am looking to solve for now is the weird acceleration behaviour in Marlin, and also putting together a tool chain that works, if necessary ditching Marlin.

Tapped on my mobile phone.

[Ian Stratford]

I think putting a stepper motor on each end of the rod is a bad design, and your problems are nothing to do with Marlin (I've never seen Marlin do this); it's electrical and mechanical. For once it's not the firmware! And it's easy to test; remove one motor, perhaps remove some weight from the axis, and see if it moves correctly. It could also be a bent or misaligned leadscrew, or binding on the leadscrew nut, in low torque situations (ie when accelerating from standstill). The Toshiba drivers are well known for being poor; they work okay with one motor, two in series on unconnected leadscrews (like on the Prusa) just about, but putting two working in tandem is going to cause them problems, particularly the way you've done it. If you're running them in the stock configuration, ie with the current set to around 1A, in parallel the motors will only be getting 0.5A each, so very likely to stall, particularly at high (16x) microstepping.

At best, the motors are fighting each other in low torque situations (eg when accelerating), at worst they're pushing each other and creating back EMF that the stepper driver is having huge problems dealing with. One motor may be stalling, but the other one is pushing it; as you've already noted, when wired in parallel, moving one motor creates enough current to move the other. What do you think the stepper driver does with that, while trying to move both motors?! Wiring in series may help, but I'd still say it's generally a bad idea.

Regarding the actual layout of the router, using a centrally mounted Y leadscrew means you need a VERY stiff X axis, or you'll get racking, and very likely chattering during cutting, as the X axis seesaws on the Y leadscrew. Looking at the video, it looks like a Openbuilds OX, and these do not have a sufficiently strong X axis; it needs to be driven from the ends, not the centre.. Why not just build it the normal way, with a NEMA23 motor on each side, using belts? You'll still have plenty of resolution, and the travel speeds will be much higher. If you really want to use leadscrews, put one on each side to move the Y axis. Use the fourth axis, the extruder, on the electronics slaved to the Y axis (you can do this in Marlin, or use GRBL that Marlin is based on) so you're running each axis with one motor on it. You'll only need one NEMA23 for X.

It just seems you've made a number of poor design choice, presumably based on cost of upgrading to proper motors; shame, as these are otherwise good CNC routers (Buserror has something similar running, and so do I, but mine still isn't complete yet), and you have what looks like a good spindle. And you're having these problems before you even have the extra load of cutting. My advice is to bite the bullet and buy some appropriate NEMA23 motors, and wire them correctly.

Ian S.

[Alex Gibson]

Thanks all for thoughts on the electromechanical configuration – I will be taking all of this on board.

 

In this project there was expected to be some experimentation and customisation to achieve a lot on a small budget – unfortunately some really boring and avoidable issues occurred up front, which foreshortened the time available to experiment.

 

Noting all that has been said about drive choices by experienced CNC users, I’m still pretty sure that the root cause of the behaviour  I initially raised is in firmware.  This could be exacerbated by, or merely hiding, any of the problems you note, but I think it’s a separate phenomenon.

 

The reason for this is that I can recreate the issue:

1)      with only 1 stepper on both X and Y.   The machine will still move (although I can more easily stop the axes moving by hand).  It moves smoothly in the middle phase of movement, but jerking in acceleration and deceleration is extremely pronounced.

2)      On my TVRR!  I have previously seen weird movement like this, it just had less of a pronounced effect.

 

I am currently working (with a lot of help) on testing the same drive setup, with all faults, with different firmware, to see if this has an effect.  The effort has already borne some pretty awesome fruit, TBA following testing…

[Ian Stratford]

It may also be some electrical issue with your drivers, of course. Ask other TVRRUG electronics owners if they see this. As far as I'm aware, no-one else has ever reported this.

Ian S.

[M P]

To be fair, I had traced down a problem with the bresenham algorithm
in Marlin a while back using simavr (that's the bit which decide in
which order pulses to the motors are sent to move the head for a
single movement)

So I know for a fact that unless it's been found and fixed somewhere
else, there is something wrong in there for quite a while.
Unfortunately I was looking into that at the time the project I was
working on got cancelled, and since digging into Marlin makes me want
to vomit more often than not, I dropped the case immediately :-)

M

[Ian Stratford]

That's interesting... we did quite a lot of work at RRP looking at the step pulses of various different firmwares, with a scope/logger on the electronics to record actual step pulses during a set of moves. We tested Marlin, a number of different versions of RepRapfirmware (for the Duet) and a couple of others (I forget which). Marlin tended to provide the smoothest and best step pulses, but it did put in one step right at the beginning of an axis movement, then a long pause (in millisecond terms), then started the movement properly, eg step pulses at sensible intervals for the acceleration. The Duet RepRapFirmware did far worse things! Usually bunching step pulses together with long pauses between the groups as it accelerated, but still somehow managed to move the motor smoothly. However, we think this is what caused us to have to limit the acceleration to less than Marlin was capable of. It did eventually get resolved, with a complete rewrite of the original movement code, and later Duet firmware is smoother. Unfortunately, very little QA checking seems to go into this sort of stuff, and problems remain unresolved for ages.

Ian S.

[M P]

From what I remember of the problem, it was pretty interesting -- the
thing is that the fact the segment weren't 'straight' means that for
any movement, it was creating a source of vibration at a certain
frequency that I'm sure could be visible in the print at the end (like
every vibration on these damn machines ;-))

I'll try to dig out my trace files later... I had made a pulse tracer
in simavr to 'plot' the course taken by the motors with a large
magnification, it's pretty clear when you see that...

M

[al...@alexgibson.net]

So thanks to Bo's help, I already have one OMC running the latest
release of Marlin, which already includes the Toshiba driver support he
got included in the main fork.

I want to see if this still exhibits the same issue or substantially
improves the behaviour, without modifying anything else.

> -------- Original Message --------
> Subject: Re: [TVRepRapUG] Marlin firmware running CNC mill
> From: M P <buse...@gmail.com>
> Date: Tue, May 03, 2016 10:13 am
> To: tvreprapug <tvrep...@googlegroups.com>
>
>
> From what I remember of the problem, it was pretty interesting -- the
> thing is that the fact the segment weren't 'straight' means that for
> any movement, it was creating a source of vibration at a certain
> frequency that I'm sure could be visible in the print at the end (like
> every vibration on these damn machines ;-))
>
> I'll try to dig out my trace files later... I had made a pulse tracer
> in simavr to 'plot' the course taken by the motors with a large

> magnification, it's pretty clear when you see that...ov