cmcgrath5035

Hmmmm, not what I was saying.

Motors work fine and I can jog all over the place as long as I don’t hit a limit switch. If I do: flashing SpDir and unresponive motors.

What you quote is correct.
What did you expect?
Think of hitting a limit switch as a fatal, non-recoverable error.

Unfortunately, your experiments are not much help without more context.
For example, when you connected the A4988s, what commands did you send and from what control system?

I assume you tried to measure current with the ammeter function of a VOM, not a voltmeter. That really won’t work, most of the current in these systems is narrow pulses that cannot be read with a Multimeter (VOM).

My best suggestion – mechanically disconnect one or all of your motors from the Machine, connect tinyG and use CP or Coolterm to send some moves to spin each motor. Report results.

hlfshell – Please copy your $$ dump to a cloud file (dropbox, gdrive, etc.) and post a URL here – much easier to read.

You parameter look a bit strange to me.
They show X,Y,Z and A axis all active, with same $_tr = 1.25mm, which sort of says you have a 4 axis screw machine. Is that correct?
We don’t see many 4 axis screw machines here, but of course they exist.

Are you able to manually rotate any of the axes?
It is possible that your ballscrew bearings are adjusted too tight.

To debug, you could mechanically disconnect a motor, say the Z axis motor, then see if a jog or G0 Z10 command will spin the stepper.

Note that with $mt=2 secs, all motors should energize at their current position(and hum) for 2 seconds after hitting tinyG reset, then go to standby low power mode(nohum).

If you have a Voltmeter, also check that 24V remains solid during the reset process. We have seen some supplies with defective current limiters drop output voltage when loaded.

When you report back, also describe your control computer.
Windows/Mac/Linux?
Running SPJS (version = ?) on same machine?
Also note that tinyG has an onboard hardware termination for the USB link – an FTDI device. So you computer may report seeing the USB link UP even when tinyG FW is not running or has crashed. And, the FTDI device has been known to look ‘sane’ to a connected PC when it is powered by much less than 3.3v, its normal Vcc.

That sort of detail(depth) is beyond the scope of what goes on here in this forum.
You might want to snoop around here, where the developers hang out and folks ask deep questions

https://github.com/synthetos/TinyG/issues

It will not address you specific question, but many of the items have pointers to how-its-done

This is the first I have seen of this idea, have to seriously doubt it is supported because there is nothing, as I see the system, to differentiate between Motors assigned to the Y axis.

It probably could be supported in FW, buy it is unclear how one would properly zero Y1, then Y2. The whole idea behind using two Y motors is to minimize drag with only one side of the gantry being energized. The potential drag would be accentuated if one side of the gantry was connected to a motor that was de-energized but still parts of the mechanical ‘circuit’.

IMHO, zeroing Y with both motors energized mechanically averages any differences between drives to Y1 and Y2.

Just my thoughts, your thoughts welcome as well.

Strange.
Perhaps a bad connection from switch into tinyG?

Best way to communicate settings is $$ command, scrape results to a text file and post to a cloud drive, then URL here.

good luck on next steps

The parameter sets are not the same when poste d to the forum and then to dropbox.
One clear difference is microsteps = 4 vs microsteps = 8.
Which parameter set applies to your issue?

WHat you describe would imply that one motor was in fact not working properly.
Can you disable one Y motor, then the other, to see if one motor is just not working?
Disabling would release the holding flux causing movement to ‘rack’ the axis

What you describe, y axis racking, seems to imply one Y motor is stuck holding position while the other is moving. Could be wiring, could be defective hardwre, no likely firmware (known to work OK by others)