From Melzi to RAMPS: Steppers need caffeine

[seatlanta]

After spending a few weeks with a defective Melzi board, I changed to RAMPS 1.4 from reprapdiscount.

It's installed and it wants to print, but the motors are clearly not set up correctly. The print head goes through the motions, but it moves veeeryyy slowly, and it doesn't move far. It's like everything is compressed. My practice parts are look like blobs of chewing gum from the bottom of a table.

I think the new drivers (on the RAMPS) need different settings. When I manually move an axis 100 mm, it moves about 15mm. And again, it's slow.

For two days, I've studied the firmware files, but I just don't know where to go or what to do. The RAMPS drivers are jumpered for 1/16 steps.

Where do I go from here?

Thanks.
James in Atlanta

[Sean Mitchell]

Hi James,

What do you have in your config.ini of your firmware?  Important things are:

#define DEFAULT_AXIS_STEPS_PER_UNIT   {22.222, 22.222, 2590, 781}  <-- X Y Z and E values, found via calculation and tuning (these are mine).  This may be your issue with not moving 100mm when you ask it to move 100mm

#define DEFAULT_MAX_FEEDRATE          {500, 500, 3, 1200}    <-- X Y Z and E values, maximum mm/s that they can travel.  Whichever is smaller between this number and the feedrate as defined in pronterface is your maximum speed that it will move

When it moves "15mm" instead of 100, does it reliably move 15 every time, or does it sometimes move 14.9 and sometimes 15.5?  If it is reliably 15, then you need to change your steps_per_mm.  The calculation here is 100/15 * 22.222 where 100 is how far you asked it to go, 15 is how far it went, and 22.222 is the current value in your steps_per_unit, which is probably different than mine!

If it is not reliable, then it is probably something hardware-related.

Before trying to print something (and getting very frustrated), you should first calibrate everything.  Then calibrate again, and finally once more for good luck and *then* try to print something.  A good calibration set of steps is here: reprap.org/wiki/Calibration

-sean

--
 
 

--
========
Sean Mitchell
50668 Köln
Germany

echo "zvgp...@tznvy.pbz" | tr '[a-m][n-z][A-M][N-Z]' '[n-z][a-m][N-Z][A-M]'

[Sean Mitchell]

Sorry, that should read configuration.h not configuration.ini 

-sean

[seatlanta]

Sean asked: What [settings] do you have in your . . . firmware?

Here they are. I have made no changes to this section:

ENDING:M501
echo:Stored settings retreived:
echo:Steps per unit:
echo:  M92 X32.05 Y32.05 Z960.00 E176.00
echo:Maximum feedrates (mm/s):
echo:  M203 X500.00 Y500.00 Z5.00 E45.00
echo:Maximum Acceleration (mm/s2):
echo:  M201 X9000 Y9000 Z100 E10000
echo:Acceleration: S=acceleration, T=retract acceleration
echo:  M204 S3000.00 T3000.00
echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum xY jerk (mm/s),  Z=maximum Z jerk (mm/s)
echo:  M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00
echo:PID settings:
echo:   M301 P63.00 I2.25 D440.00

 

[seatlanta]

Maybe the last settings I sent were not what you needed to see. Here's a cut-and-paste from configuration.h:

#define DEFAULT_AXIS_STEPS_PER_UNIT   {32.05, 32.05, 960, 176}  // default steps per unit x,y,z,e
#define DEFAULT_MAX_FEEDRATE          {500, 500, 5, 45}    // (mm/sec)   
#define DEFAULT_MAX_ACCELERATION      {9000,9000,100,10000}    // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.

#define DEFAULT_ACCELERATION          3000    // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  3000   // X, Y, Z and E max acceleration in mm/s^2 for r retracts

//
#define DEFAULT_XYJERK                20.0    // (mm/sec)
#define DEFAULT_ZJERK                 0.4     // (mm/sec)
#define DEFAULT_EJERK                 5.0    // (mm/sec)

Correction
By the way, I erred when I said a 100mm move results in a 15mm travel. The carriage consistently moves a hair less than 35mm. Two 100mm moves cause an actual travel of about 69.5.

James in Atlanta

[Sean Mitchell]

Hmm, that was not quite what I was hoping for, these numbers seem "ok" -- as in with the values it should move with reasonable speed.  

What happens when you move it within pronterface - what are the mm/min values in Pronterface?  If you change them will it speed up or slow down?  Alternatively you can do it using the Gcodes, I think it would be G0 X200 F2000, where X sets the speed.

What happens if you change your 32.05 to a value around 92.23?  This seems very high to me, which either means you have steppers with a smaller rotation per step than me, or different gears or something.  I switched from 1/16 microstepping to 1/8 microstepping, and changed my value from 44.444 to 22.222, according to my calculation (below) you need around 92 steps per mm (very VERY accurate!)

I got the 92.23 from (200/69.5)*32.05.  This should at least put you closer to 100mm moving 100mm

Also important to remember, when playing around never disconnect the stepper from the stepper driver, unless the power is disconnected from the entire system!

-sean

--
 
 

[seatlanta]

From Sean: What happens if you change your 32.05 to a value around 92.23?  This seems very high to me, which either means you have steppers with a smaller rotation per step than me, or different gears or something.  I switched from 1/16 microstepping to 1/8 microstepping, and changed my value from 44.444 to 22.222, according to my calculation (below) you need around 92 steps per mm (very VERY accurate!)

We are thinking along the same lines. I did a calculation and inserted 92.0977. I changed only the x-axis numbers, then uploaded the file, and tried it. No change. The carriage still moved about 35mm. I was expecting a change in distance, either more or less.

mm/min setting in Pronterface is 3000.

 I'm attaching two screen shots, one from Pronterface (Ignore the temperatures; that's another story.) and one from slic3r settings in Pronterface.

James in Atlanta (in my workshop, at the workbench, staring at the Mendel)

[seatlanta]

Wait! Wait!

When I make changes to the configuration.h settings and upload them, then enter M501, the settings are echoing back without changes. Hmmm.

I know the firmware is updating because I changed the date in the opening message strings, and that new date shows up when I connect.

What am I doing wrong?

James

[UK Chris]

James in Atlanta (in my workshop, at the workbench, staring at the

Mendel) and Sean,

I'm suspecting there may be some crossed wires here (not 'lecric
ones); does Sean realize that you have a Mendel, rather than a
Mendelmax? Won't the parameters you are using be very different?

Regards

[UK Chris]

...further to that, the parameter here;
http://brazenartifice.wordpress.com/my-marlin-non-gen6-configuration-h-file/
for a Mendel... are very different.

OK, I only have a little knowledge.

As an aside, my Mendelmax 1.5+ is now so heavily modified, I've
renamed it 'MongrelMax'. Works good though.

Regards

[seatlanta]

Chris said: OK, I only have a little knowledge.

But a little knowledge is better than none, right? Then there's the saying:" A little knowledge is a dangerous thing."

In any event, I'm happy that my heating resistor is no longer warming the entire shop. I grateful that I have not seen any more flames. I'm very pleased that the print head moves around and pretends to print, albeit at an odd scale and a leisurely pace.

My main concern at the moment is why my uploaded firmware changes are not appearing in the Pronterface messages. I can change the string text at the beginning, and those changes do appear. I don't understand why I can't change the configuration.h numbers.

I'm going out to the shop and try to stare at it more intelligently.

James in Atlanta

[Jim Morris]

The problem is it is loading the settings from eeprom, not the default settings inm configuration.h (you can see that in the first few lines in pronterface when it starts up).

You can force it to use the defaults (in Configuration.h) with M502, then restore them in eeprom with M500. Use M503 to see what the current settings are.

I am not sure how you erase the eeprom settings though.

[seatlanta]

Thanks, Jim, for the suggestions.

I'm still a bit confused about this. Several weeks ago, I didn't even know that a configuration.h file existed. Now, I can edit it and upload it. But I don't understand why I can edit and upload it, and the edited version appears (with my text identifier at the beginning), but the stepper settings don't change.

Yet, when I use M92 to change the settings from Pronterface, it works.

I don't get the relationship between the two methods. And I have not yet grasped the idea of "default" settings. I can read the various M codes, and I know I can force things back to their default settings, but I don't know what will happen if I do. What are the defaults? And I really don't understand the value (or danger) of erasing the EEPROM settings.

Thanks again.
James in Atlanta (working toward being a master programmer)

=============================================================

[UK Chris]

James,

I’d like to help by giving my version of what I think happens here. I
would appreciate anyone correcting me.
Your Mendel (not Mendelmax) has an Arduino, which is running a program
called Marlin. Marlin is in an executable form (1’s and 0’s) and
lives in the EEPROM (electrically erasable programmable read only
memory), on your Arduino. This is non-volatile memory (it doesn't
forget, when power removed). Meanwhile, you have Marlin + 40
additional files ‘config.h’, ‘pins.h’ etc, which are mostly text files
– which you can alter on your PC. Using the Arduino interface, you
load Marlin.pde and you can alter and save any of these 41 files.
Prior to uploading to the Arduino, you convert all these text files to
an executable version by using the Verify/Compile menu item, from the
Sketch menu. You then upload to the Arduino. This action overwrites
the old executable program held in EEPROM on your Arduino.

I take it you have done all of this, but the steppers are still in
need of caffeine. My previous post asks if you are using the correct
parameters for a Mendel. Are you populating config.h with parameters
for a Mendelmax, rather than a Mendel? Surely this will make a big
difference.

Regards

[vlad]

Chris beat me to it, but let me re-say what he did in bullets:

*Configuration.h creastes your default settings, which you upload to your board, yay
*EEPROM is where your settings that you change on the fly CAN be saved if you ask it to
*uploading new firmware w/ the values changes your "default" settings but does not effect EEPROM
*Sending M92 in pronterface changes your dynamic settings, which are not saved anywhere and get lost on reboot (M503 Tells you current settings being used)
*when you reboot the RAMPS, it reads data from the EEPROM, and ignores yoru default settings
*You can save your current settings to EEPROM with M500
*You can start using hte settings in EEPROM with M501
*You can use the settings from your firmware with M502

[UK Chris]

Vlad,

Thanks for that. James, I was wrong regarding the uploaded program
living in EEPROM - it goes into Flash Memory (see; http://arduino.cc/en/Tutorial/Memory
).

Regards

[seatlanta]

Thanks to all of you.

Chris, the Arduino link was very helpful. And Jim's' comments helped clear up some questions about the Arduino memory.

At this point, I can made distorted prints of simple, small objects. Printing a 20mm cube and measuring the finished product moved me much closer to the correct calibrations for the three axes. I have now memorized the calibration formula, and I sometimes dream about it.

My friend, Will, came over last night and provided a second opinion about some of the remaining problems. He has completed his machine and it prints with nary a problem. Disgusting!

Voodoo
We spent about an hour trying to analyze the E motor and why it quit operating. I plugged it into the x-driver and it extruded when I did an x move. I plugged the x-motor into the E driver, and it moved left and right when I did forward and reverse extrusions. Therefore, the motors function, and both drivers function, but when I plugged everything back as it should be, the extruder didn't budge. I went indoors and thought about it, and when I returned, it worked.

Why Z deserves to be at the end of the alphabet
The last problem to solve (I hope) is the z-axis, which continues to bind. When that happens, one motor stops turning and the other doesn't. This creates a rapidly worsening binding problem that screws the nuts off the lead-screw and slams the x-carriage into the bed on the right side.

When I check my parallelism and perpendicularity (words I like to use), everything is OK. When I move the z-axis manually, it's smooth as silk. But when I home the axis, it usually goes berserk. So it can take a short move, but not an extended move.

Will and I decided the vertical bearings (bushings) at each end of the x-carriage are not aligned in the vertical direction, probably because both fittings broke early in the game and I had to put them back together with super glue. By the way, several of my pieces were very brittle and snapped during construction. At this point, I also have several stress fractures in some other parts. This doesn't seem like the way it should be.

And before anyone asks: Yes, I was very careful during construction and treated everything with kid gloves.

Will is printing two new parts for me. Maybe that will solve the problem.

And on the plus side

• I'm still getting good temperature control
• I'm no longer seeing any smoke or flames.
• The resistor is still green, and not crumbling like charcoal.
  
• The printer is functioning, but has some mechanical issues that I know I can handle.

Best wishes.
James in Atlanta

[UK Chris]

James,

Firstly, I really enjoy your humorous slant on your multitude of
Reprap problems - please keep this up.

Secondly, I suspect that when you transferred from the Dark Side
(Melzi), your Z motors were wired in series - this will obviously
limit the current and therefore the torque to your steppers. As the
RAMPS has pin-outs for two (parallel) Z steppers, consider wiring them
like this and get max torque from each.

Thirdly, once Will has printed the parts you require, swap your duff
Melzi board with his/throw iron filings into his machine - that'll
wipe the smug look off his face.

Regards

[Larry Knopp]

I will throw my humble +1 behind Chris' observations.

And, say congrats!  Your hurdles have been many, and occasionally treacherous.  The fact that your humor has come through it all intact is appreciated.

Regarding Voodoo...
I have worked in a land of mystery and magic for many years.

IT

I learned two things long ago that are just as true today, in that land, and in this one of oozing plastic :
1)  The magnetic field generated by the (non-existent) plate in my head often fixes things that others cannot, and does involve anything more than it's proximity to the device in question.
2)  Failing the magic of my plate, 70% of all other problems can be resolved by taking a smoke / beer / food break.  Or, just getting some sleep.

--

[Ross Shannon]

I just talk to the voices in my head - its like having a whole team of individuals working on the same problem

--
 
 

[Triffid Hunter]

On Sat, Nov 17, 2012 at 2:49 AM, UK Chris <hone...@rapro.co.uk> wrote:

Secondly, I suspect that when you transferred from the Dark Side
(Melzi), your Z motors were wired in series - this will obviously
limit the current and therefore the torque to your steppers.  As the
RAMPS has pin-outs for two (parallel) Z steppers, consider wiring them
like this and get max torque from each.

Actually when connected in series, the motors each get twice as much current (hence torque) as when they're connected in parallel... what makes you think it's the other way around?

[UK Chris]

Hi Triffid,

A stepper is simply a bunch of coils which have some resistance
(reactance to changing voltage/current generating back EMF). Put two
in series and you double the resistance and therefore halve the
current and consequently torque. Now, from reading your posts, I
figure you know your stuff, so I'm anticipating opening a large can of
'whoop-ass'.

Be gentle with me.

Regards

[UK Chris]

...Triffid,

one more thing - in addition to my terrific MM1.5+ (it's printing
prototypes every day), I have a Huxley which was supplied with Melzi
electronics (I managed to palm that off on a fella from the
colonies ;)
So I'm replacing the electronics with a Megatronics
http://reprapworld.com/?products_details&products_id=274&cPath=1591_1606
, which I am going to connect today. Like the RAMPS, it has parallel
outputs for the Z steppers and I was going to wire them that way. Why
would both circuit boards have two sets of Z O/P's?

Regards

[Dan Tyrrell]

Hi,

IMO it is because A4988/A4983 or any other stepper motor driver, in
general, is not designed to drive two steppers in any configuration.

Marlin has an option Z_DUAL_STEPPER_DRIVERS which allows use of the E1
socket on a RAMPS as the second Z driver.

Dan

> --
>
>

[UK Chris]

Hi Dan,

Thanks for that - what you say makes sense.

Has anyone any ideas why then, that the RAMPS has parallel outputs for
the Z (as does my new Megatronics), the photos supplied by TL show
parallel wiring and this; http://www.flickr.com/photos/87350090@N03/8192085683/
does too?

I understand the argument that a 'current limited' Polulu is sharing
the current between two parallel steppers, but surely we can just turn
that up to its specified limit.

If I'm doing this wrong, then I suspect lots of other folks are too.

As an aside, I have had much grief with Z vibration (having accurately
aligned it, so many times), until I got rid of the aluminium (spiral)
couplers and replaced them with these; http://www.thingiverse.com/thing:9622
I know, it's old tech and doesn't look sexy - but they dam well work.
Reduced the vibration by 95%, the rest disappeared after a thin
application of PTFE oil. (Wiki says not WD40)

Regards

[Misha]

The way I fixed z-vibration with the aluminum couplers is I just let the threaded rod drop all the way down and sit on the motor shaft.  I still have a bit of flexibility but now it comes from stretching the coupler vs compressing it.

[UK Chris]

Misha,

Thanks, but I tried that - didn't work for me.

Roger, thanks too - so I'm not as stupid as I look!

Regards

[Triffid Hunter]

On Sun, Nov 18, 2012 at 2:15 AM, Roger Dearman <roger....@gmail.com> wrote:

Chris, Triffid, here's the relevant maths.
http://en.wikipedia.org/wiki/Series_and_parallel_circuits

that's relevant for constant voltage supply. 

when you have a constant current supply, it all reverses, and our pololus deliver constant current (subject to microstepping current translation of course)

for example, the pololu is set to supply 1A.

with two motor coils in series, each coil gets 1A, and the pololu must supply double voltage to drive that current.

with two motor coils in parallel, each coil gets half the current - ie 0.5A for a total current of 1A. The pololu drives a lower voltage than the series configuration in order to achieve that current.

SO in series configuration you get more torque, but it drops off more quickly as speed increases. Parallel gives less torque, but it runs faster before the torque drops off.

[UK Chris]

Dear Mr Triffid,

Thanks for taking the time - I reckon many folks benefit from your
explanation....and you were sufficiently gentle.

Any idea why so many circuit boards have parallel o/p's and the widely-
used circuit I referred to shows them in parallel. I think Z needs
torque rather than speed.

Regards again

[Triffid Hunter]

On Sun, Nov 18, 2012 at 7:34 PM, UK Chris <hone...@rapro.co.uk> wrote:

Any idea why so many circuit boards have parallel o/p's and the widely-
used circuit I referred to shows them in parallel.  I think Z needs
torque rather than speed.

because it's simpler. parallel outputs still work if you only connect one motor. https://picasaweb.google.com/lh/photo/ciL6GieVuEhJBWeNckmTONMTjNZETYmyPJy0liipFm0 is a bit much for some folk ;)

One of the interesting effects you get from changing from parallel to series is that when hooked in parallel, the Z motors are electrically interlinked- turning one by hand causes the other to turn when the driver is disabled. When you change to series, this interlinking becomes significantly weaker.

[UK Chris]

Triffid,

Thanks again... I'm going to give it a try.

Regards

[UK Chris]

...well, I'll be...

Have a look here; http://reprap.org/wiki/RepRapPro_Huxley_wiring#Extruder,
under the heading; Technical note on how the currents are regulated.

...and I thought it was 'ornery 'lectric!

Regards

[Larry Knopp]

"...then never talk to you again."

I hate it when that happens.
;)

--

[Dan Tyrrell]

Triffid,

Are you sure about that? From what I can see there is no voltage
regulation function in these chips.

The A4988/A4983 applies the full (Vbb) voltage to the outputs (stepper
coils). The current in the coil is set to constant (average) value by
PWM.

Steppers in series each coil will have Vbb/2 applied to it.

Steppers In a parallel configuration each coil will have Vbb applied to it.

In any case IMO these drivers are not designed to drive two stepper
motors in any configuration. I am not denying it works well though.

Cheers,

Dan

> --
>
>

[Triffid Hunter]

On Mon, Nov 19, 2012 at 8:49 PM, Dan Tyrrell <d...@dnt.com.au> wrote:

Are you sure about that?  From what I can see there is no voltage
regulation function in these chips.

no there isn't.

The A4988/A4983 applies the full (Vbb) voltage to the outputs (stepper
coils). The current in the coil is set to constant (average) value by
PWM.

yep that's correct, however don't confuse the average power dissipated by a PWMed resistor with the actual relatively constant current achieved by high frequency PWM of an inductor. Inductors keep the current flowing all by themselves, we just have to top it up every so often, and they won't let full current flow straight away, we have to leave them on for a little while to let the current build up.

SO if we turn the switch on after some fixed interval, then turn it off when the current reaches some set level, and the fixed interval is relatively short compared to the inductor's ability to shed power then the inductor current will remain relatively constant with a triangular profile near our set point. If the set point changes, our current peak switch-off circuit ends up leaving the switch on for longer or shorter periods of time as a natural function of its operation.

Steppers in series each coil will have Vbb/2 applied to it.

yes.

Remember that the effect of the winding inductance dominates when we're driving with high frequency PWM, and inductors in series/parallel follow the same rules as resistors.

Since di/dt=V/L it'll stay on for approx. twice as long per PWM cycle as with a single motor, and approx. 4x longer than parallel motors to achieve the set current.

Steppers In a parallel configuration each coil will have Vbb applied to it.

yep, so the PWM cycle will stay on for approx. half as long as a single motor, and 1/4 the time of two motors in series to achieve the set current.

If you want something a little more in-depth to chew on, see the fast/slow/mixed mode decay profiles.

In fast decay, during the "off" time, the motor winding is reverse-connected to the supply which forces it to charge the decoupling capacitors. Since it's generating a (relatively) large voltage, the current decays rather quickly. This mode is best used when we're in the second and fourth quadrants of the microstepping current profile where the current decreases each step, especially when approaching the zero crossing.

In slow decay, during the "off" time, the motor winding is shorted by connecting both sides to ground. Since it's generating a small voltage (whatever it can manage to develop over the FETs' Rdson), the current decays slowly. This is best used in the first and 3rd quadrants of the microstepping current profile when the current is increasing. It means we have to inject less power each pwm cycle to maintain or increase the current.

In mixed decay, the driver chip does fast decay for a portion of the off time, and slow decay for the remainder. This is best used near the start of the 2nd and 4th quadrants when the current drops only a little bit with each step.

See Figure 7 Enlargement A in the Allegro A4988 datasheet for graphs of the currents in fast, slow and mixed decay modes.

Our pololus automatically choose between slow and mixed decay modes, however our printers go through conditions that make it advantageous to use mixed mode all the time. Permanent mixed decay mode is activated on our pololus by shorting R4, the resistor closest to the DIR pin. Nophead has posted a blog entry about this at http://hydraraptor.blogspot.com.au/2012/04/stepstuck.html

I've tried this mod myself, and it sure does make my printer more musical :)

In any case IMO these drivers are not designed to drive two stepper
motors in any configuration.

concur

 

I am not denying it works well though.

seems to work well enough for Z, wouldn't want to try on X, Y or E though :)

[bluecoast]

Dan, you're correct. The coils are inductors; they do not average the full-scale PWM voltage they see in any way, and the coil current is not directly related to the coil voltage because it is not a resistor (indeed that's why we want constant current drive).

[Dan Tyrrell]

Triffid,

I read the datasheets. I was simply interested in this statement:

> With two motor coils in series, each coil gets 1A, and the pololu must supply double voltage to drive that current.

> with two motor coils in parallel, each coil gets half the current - ie 0.5A for a total current of 1A. The pololu drives a lower voltage than the series configuration in order to achieve that current.

i.e. The A4988/A4983 somehow changes the supply voltage.

And this:

> SO in series configuration you get more torque, but it drops off more quickly as speed increases. Parallel gives less torque, but it runs faster before the torque drops off.

Is this based on testing or theory? I think parallel might give better
torque - I need to test...

I do think that given the issues I see with Z friction and binding
that for most builders separate drivers might be best.

Dan

On 19 November 2012 22:19, Triffid Hunter <triffid...@gmail.com> wrote:
> On Mon, Nov 19, 2012 at 8:49 PM, Dan Tyrrell <d...@dnt.com.au> wrote:
>>
>> Are you sure about that? From what I can see there is no voltage
>> regulation function in these chips.
>

>SO in series configuration you get more torque, but it drops off more quickly as speed increases. Parallel gives less torque, but it runs faster before the torque drops off.

> --
>
>

[Triffid Hunter]

On Mon, Nov 19, 2012 at 10:54 PM, Dan Tyrrell <d...@dnt.com.au> wrote:

I read the datasheets. I was simply interested in this statement:

> With two motor coils in series, each coil gets 1A, and the pololu must supply double voltage to drive that current.

> with two motor coils in parallel, each coil gets half the current - ie 0.5A for a total current of 1A. The pololu drives a lower voltage than the series configuration in order to achieve that current.

i.e. The A4988/A4983 somehow changes the supply voltage.

you've completely missed the point I tried to make in my last email.. it changes the duty cycle into the winding inductance to achieve the target current. effective voltage is not directly measurable and isn't at all relevant (until it becomes equal to supply voltage) but if you're determined to think in terms of voltage then yes the effective voltage is altered by the machinations of the PWM output and current feedback systems in concert with the winding inductance, winding resistance and rotor speed of the motor itself.

Let's play with some simple resistors, and ignore inductance and PWM for the moment. We'll say that we have some 1 ohm resistors and a 1A constant current supply, like a battery charger.

With one resistor on the 1A constant current supply, ohm's law says that 1 volt will appear across it and of course it will carry the full supply current of 1A.

With two resistors in series, ohm's law says that we'll have 2v appear (1v across each resistor), and each resistor will carry the full 1A of current since it must go through both of them.

With two resistors in parallel, we'll have only 0.5v appear, and each resistor will carry half of the current - ie 0.5A each because they share it between them.

The situation with the motor windings is similar, but of course has several more elements involved, such as the winding resistance being merely a parasitic loss of efficiency since the inductance alone can do all the current limiting we need.

And this:

> SO in series configuration you get more torque, but it drops off more quickly as speed increases. Parallel gives less torque, but it runs faster before the torque drops off.

Is this based on testing or theory? I think parallel might give better
torque - I need to test...

mostly theory. I currently have one printer with series Z motors and one printer with parallel. Both move at a maximum of 3.5mm/s which is very interesting since the one with series motors has 1mm pitch and the one with parallel motors has 2mm pitch, so the series motors must move twice as fast to achieve the same Z feedrate which fits perfectly with my hypothesis.

I can't say this confirms it or even supports it because the printers are too different for direct comparison- a before/after test would be much more useful.