how to move # steps not to position…

I am guessing you are the developer of the solar system project.

You are correct, a G0 X100 Gcode command will move the X axis either 100 mm or 100 inches, depending on your units setting. It will make the move of 100 units either to an absolute position (x=100mm) or move 100 mm in the positive direction, depending on the movement mode (absolute, relative).

A good reference point to start at might be here

https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97

Basically, you need to tell tinyGV8 about stepper driver parameters and motion conversion (e.g. gearbox) parameters so that it can calculate the number of step pulses to send to the stepper to achieve the move.

Can we assume you will be hand coding the Gcode for this project? I am not aware of any Gcode generator that would do it for you.
My initial guess might be you would want to use rotational axis commands for your task. For example, G0 A180 would move a stepper, properly configured, one half rotation (180 degrees).

As you read thru and contemplate your coding strategy, keep in mind that that tinyG uses all these parameters to translate a command into an action which sends a number of step pulses to the stepper driver. So the ‘precision’ of an axis is the distance moved with one step pulse.

Be aware that “My final gear will move 1 degree for 100 motor steps.” leaves out some possibly important information about how to set parameters.
For example, a typical stepper has a 200 steps per rotation spec, a step angle of 360/200 = 1.8 degrees per step. That is a physical parameter of the motor. Most stepper driver devices(the electronics) have microstepping capabilities, which use phase offsets between the windings to ‘synthesize’ partial motion, So if microstepping = 2, the driver device will make the stepper appear to need 400 step input pulses for a complete rotation. You might want to read thru a driver device spec sheet to see how this is done.
From you “My final gear will move 1 degree for 100 motor steps.” comment, I would conclude that the stepper drives a gearbox with a 180:1 gear ratio, is that correct?

Another way to look at it: I have a machine where the rotation axis has 16 to 36 reduction (0.4444…) meaning I get 160 deg actuator rotation for each motor rotation. The following settings are the critical ones:
$aam=1 //standard (not rotation) mode. A bit confusing, but at the end, makes life easier
$4ma=3 //motor 4 is rotation axis
$4sa=0.9 // motor degrees per step. I have 0.9, the other common value is 1.8
$4tr=160mm // travel per revolution.

TinyG thinks it is moving 160mm, but it is turning 160 degrees. With these settings, G code mm’s map directly to degrees of revolution.

(I hear Murphy sneaking up behind me).
Here are a few random thoughts/questions that have come to mind after understanding what you need to do.
+ Are you expecting that NEMA 17 (or smaller) motors will be adequate for each of your 22 rotators?
++ tinyG, with 4 on-board drivers, is about as dense as you can get.
++ if you think you will need NEMA23s, you had better come up with a good thermal management plan.
+Am I correct in assuming that this display will operate in somewhat real time, e.g. the earth will rotate around the sun once a year, moon around the earth once a month. Or do you have a ‘millennium evening’ event planned, 100 years between 8 and midnight?
++ question is really how fast the Gcode will need to be delivered to the units.
+what is your current thinking – 6 tinyG’s providing drive for 6×4 = 22 motors?
++ I would be cautious assuming two tinyG’s linked together is a safe plan. The electrical interfaces might be there, I have never seen anyone try it
++At best 2 tinyG’s in series would drive 6 motors, waste 2 drivers. tinyG logically only decodes motion for 6 axes – x,y,z,a,b,c.
++ Hobbyist CNC has moved on since a possible series connection of tinyGs was enabled in the hardware. Most current effort is aimed at 3D printing applications. Newer hardware platforms have been in the works for a while, will appear soon. They will be G2core based.
+ How do you plan to initiate your machine’s motion? In CNC space, some users install homing switches, run homing cycles and set a predetermined starting point for movement. Others just grap hold of the gantry and drag it to a ‘starting point’ then reset tinyG. When tinyG resets, all 6 axes are set to 0 at whatever position they are at. Manually zeroing 22 separate rotators might not be practical.
++ Something is going to fail or glitch. Only you will know if everything is in the ‘correct position’, but why do this if it isn’t correct?

All for now – you have a very interesting project going.

From this

https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#axis-groups

I believe the answer is no, not for what you need anyway.
What you meant to ask, I believe, is can 4 unique rotational axes be defined and decoded simultaneously, for which the answer is no.
It is possible to attach 2 motors to one axis(.g. A axis), such that the two motors follow the G0 Axy command, but that is not much help for you.
X,Y and Z are linear axes, A,B and C are rotational by definition; modifying firmware to change that might be difficult.

Also review this

https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#axis-settings

I think this strategy might work for you:
+ Plan to generate your control program in units = degrees of rotation
+ set $xtr=360 $_tr is travel per rotation,
+ set $aam=$bam=$cam=1, standard rotational, move in degrees
+ set $xvm,$avm, $bvm and $cvm appropriately for how fast you want moves made.

This generates an interesting question, for which I don’t have a definitive answer.
Assume you are in G90, absolute mode.
With the above proposed setting, G0 X270 will move 3/4 rotation. Then sending G0 X0 will reverse direction back to 0.
I can only assume that G0 A270, followed by G0 A0 will behave similarly, although continuing forward 90 steps would get there faster.
In G91, relative mode, G0 X270 followed by G0 X90 and G0 A270 followed by G0 A90 will behave the same a yield one full rotation, I expect.
But after those commands, Xpos will be 360, where as I believe Apos will be 0.
Experiment with your A axis, I don’t have a machine handy at the moment.

Hint – make a flag on the shaft of your stepper with masking tape, keep $avm slow so you can watch what is happening.

• This reply was modified 7 years, 3 months ago by cmcgrath5035.
• This reply was modified 7 years, 3 months ago by cmcgrath5035.

Cool! You are on your way.

Tweaking $afr might work OK, but may only be effective (accurate) for one f-value, e.g. f400. Rerunning “g1 f200 x2 y2 z2 a2” would not be similarly equalized by the $afr value

This wiki might help

https://github.com/synthetos/TinyG/wiki/TinyG-Tuning

Fast forwarding to a future phase where you need to simultaneously drive 6 tinyGs to provide 22 stepper drivers:
tinyG uses an FTDI USB to serial device as the front end interface to the host computer. While it is possible to bypass USB and hard wire a serial interface, finding control computer with 6 serial ports might be a challenge.
Each ftdi device has a unique device ID.
In Linux land, it it possible to force a particular ftdi ID to mount as a specific /dev/ttyUSBx device using UDEV rules.
That way you would have a reproducible interface to your universe upon reboot. That would probably make programming and debugging a bit easier.
I’ll assume this is similarly possible for Windows and macOS, but no experience.

• This reply was modified 7 years, 3 months ago by cmcgrath5035.