cmcgrath5035

Look at it this way, you learned a lot of the dark corners, the experience will help into the future.
Enjoy

So a $defa=1, the full reconfiguration, fixed it?

Interesting.

What OS are you using?
What interface are you using to enter and maintain parameters? ChiliPeppr, CoolTerm, ?

Leaning on this stuff goes on forever.
Hang around the forums and see other folks solve issues.
It is somewhat amazing the variety of machines and projects that flow through.
And experiment, experiment, experiment.

Very strange indeed.

At $1tr=60, you are off by x12
At $1tr=6, you are off by x10
So we can’t blame something like a bad micro step provisioning .or other ‘digital’ defect, or the multiplier would be constant.
The obvious suspects are bad motor or perhaps a bad driver device on tinyG.

Let’s try this:
First – objective, run Y axis with only one motor
step 1 – Set parameter $3pm=0 (disable the second Y motor)
step 2 – Set $1tr=60 (back to what we think it should be)
step 3 – Try the Y axis 10mm move – still good? it may be a bit jerky with only one motor running
step 4 – Verify that G1 X10 still moves 120mm or so.

Second – Objective: connect the Y motor to motor(driver) 1 and the X axis to motor(driver) 2.
step 1 – At tinyG terminal strips, unwire Motor one and motor two, then reconnect them motor two and motor 1
step 2 – execute a G1 X10. The Y axis should move, ideally 10 mm
step 3 – execute a G1 Y10. The X axis should move, ideally 10mm.

What do we get now?

• This reply was modified 9 years, 8 months ago by cmcgrath5035.

The display in the middle of your CP screenshot is a rendering by the simulator of a Gcode file that auto loads with CP.
If you go to the Gcode widget, that Gcode will be sent to tinyG when you select the “run” [right arrow] icon.

Looking at your screenshot, on the left, in the Serial Port Console widget, all the lines of commands that have been sent that have yellow checkmarks – they have not been executed and responded too.
When they execute, they turn green.

On the right side, the 77 under tinyG confirms that tinyG is not respoonding to commands.
I believe this is 77 commands waiting response.

Are you sure that COM11 is tinyG?

For your second post, simple answer, no, changes to tinyG parameters is immediate IF the change is executed. In coolterm, you have to look for the response message.
The only exception to this is $p1frq, the pwm frequency – that does require a reset.

Or try this:
$1tr=10
$1tr (this will read back the value of $1tr, should be 10
$1tr=20
$1tr (do you get a $1tr=20 response)?

Cool calculator, but tinyG does not work like that.

You provide $xtr = 60 mm (=20 teeth * 3 mm pitch) , Travel per Rotation
You provide $sa=1.8 (=200 steps per rotation)
You provide $xmi = 8 microstep setting
And tinyG computes the distance that each step ‘tick’ moves, which would be 60/(200*8) mm, for internal use.

So you need to fix your $xtr, $ytr and $ztr

I would stick with the chilipeppr logo Gcode that auto loads for early experiments,.

Don’t run Gcode until you can jog the correct distance reliably.

In first post your wrote:

what I need now is how do I configure my tinyg to understand my machine and its limits , distance. for arguments sake my first attempt to drive just the X drive from one side to the next using chilipepper to jog it chilipepper reports that the x axis travel is 9cm when in fact it is 60cm.

Keep in mind that tinyG has no idea where you gantry actually is, what is does know is how many microsteps it has commanded from the 0,0,0 location. It calculates the movement per microstep from the parameters, $_tr, $_mi and $_sa,.

You report of 60cm (600mm) when tinyG reports 9cm (90mm) does not makes sense.
Don’t mess with limits and homing until you get your parameters correct.
Zero the gantry in the middle of the work area, then work your parameters until commands G1 X10, a G1 Y10 and G1 Z10 move the correct distance in the correct direction.

I highly suggest you go the extra mile (or two) and code your system to wait for a response rather than simply waiting longer. I have seen responses that take longer than 50ms on occasion, don’t know why.
It is also easier to debug, since you will have a better idea of where the communication actually stalled.

Lets say your second Z axis, I’ll call it ZA axis, has its stepper directly connected to a 2mm pitch lead screw. To move 10mm, you would need 5 revolutions.
So, a G1 A1800 (5×360 degrees=1800) Gcode command would move your ZA axis 10mm. You have to experimentally determine if you want a G1 A1800 or G1 A-1800 to move in the direction you want

I am not aware of any Gcode generator that would generate this for you, you will have to hand code.