cmcgrath5035

After $defa=1, the switch type is NC.
That command replaces all parameters with a default set that may/may not match your machine. You have to re-enter all your parameters

You original parameter set looked OK(quick look), although you do have soft limits turned On, which may interact poorly with physical limit switches

From my end, I don’t know how you have implemented “..(and not have a dual Y axis setup),….”.
Did you change parameters?
Did you physically disconnect Motor 4?

Using the parameters you posted on Dropbox above, try this:
From a command console, send $4tr=40.0 command and see the response from tinyG.
Reset tinyG (hit the reset button), run $$ again.

Verify that you see $2tr = 40.0 and $4tr = 40.0.
Now see if you can jog the Y axis motors.

The problem with the Dropbox parameter set is that you have two different definitions for movement of the Y axis, 40mm per revolution and 2.1166 per revolution. When tinyG tries to make calculations for Y movement, it does not know which one to use.

In the beginning, way back when,there was a plan to develop an interconnection between the first tinyG and a second tinyG board.
Not much interest and that capability was overtaken by other time consumers.
The firmware does decode actions for any four of the 6 axes, X,Y,Z,A,B,C.
I have never heard of commercial Gcode generators that do much, but some folks have built custom three axis rotational machines driven by custom Gcode.

If you are really interested in multiple axis machines, have a look at
https://github.com/synthetos/g2/wiki/9-Axis-UVW-Operation.

First, the easy one

– This is the weirdest part: When all 4 stepper motors are plugged in, (1ma=0 2ma=1 3ma=2 4ma=1), and I try to jog the Y axis (which should activate 2ma and 4ma), instead, the 1ma (z axis) will hum but not move. Basically, this means that the Z axis (motor 1) is being activated when I try to jog the Y axis (motors 2 and 4).

What you describe is normal behavior if you have $_pm=2 setting. (_=1,2,3,4)
Usually, $_pm=2 is preferred. When ANY motor is moving, all static motors are energized to hold thei current position.

Two(of many) possibilities for your bigger issue
PWB/mechanical: If you have a multimeter, follow the trace from each output screw block back to it’s respective output pin on the 8825 drier device.
Then measure the resistance from the device lead to the connector screw head. It could be an issue with the connector body.
While you are at it, double check the connections closest to the steppers, most installations have 4 wire 18ga or so cables between tinyG and the steppers, with connectors/splices near the steppers to the 24ga (or so) leads into the steppers. It is easy to bork the connections.

Settings: Grab a parameter dump from a console ($$ command) and post it to a cloud drive (gDrive, etc.) and provide a URL. That will save us several iterations of “what is $blah)

Here is an old thread on similar topic

TinyG with external drivers: J19 (motor3) and J20 (motor 4) don't work

It confirms your observations, not clear if the build parameter tweaks identified actually yielded a working solution.

You could try tinyG Edge build, available here:

http://synthetos.github.io/binaries/tinyg-edge-449.01.hex

Not clear that 449.01 would help here, but does represent the most up to date tweaks in various areas of the code.

• This reply was modified 5 years, 11 months ago by cmcgrath5035.
• This reply was modified 5 years, 11 months ago by cmcgrath5035.

Many have run into the issue, most it seems have figure ways to mitigate.
Work in MM, tweak post processors and the like.

Some have found the current edge, 449.01 better in some situations
http://synthetos.github.io/

The underlying issue appears to be the precision of math done on the path.
mmArcs are always more precise than inchArcs because tinyG does all it’s work in mm internally, so inch mode Gcode goes thru additional conversion math.

mmArcs frequently resolve issues, but not always

8 bit math (microcontroller hardware) is also a contributor