Forum Replies Created
-
We never heard back from member themij so I assumed something fixed it.
I recently used avrdude ver 6.1 to upgrade to 438.02 from my Linux system.
Some perhaps useful lines in the update log:
avrdude -p x192a3 -c avr109 -b 115200 -P /dev/ttyUSB0 -e -U flash:w:tinyg-edge-438.02.hex 2>flash_err.log ......... avrdude: verifying ... avrdude: 117552 bytes of flash verified avrdude done. Thank you.Did you use the -e option on your avrdude command line?
My upgrade failed without it, but did not write anything without it so a different failure signature than yours.
I WAS updating (from 425.something), so perhaps a “reflash” of 438.02 has a different signature.This seems to confirm that build 438.02 loads 117552 bytes to flash.
If -e option does not work, you’ll have to consult the Synthetos folks.
4. The X-Axis does not pass the manual test. Even swapping the X and Y limit switches at the board to test known good switches (Y) on the X axis does not trigger on the board.
This seems to imply that the port pin is shorted to ground(same as NC),
Can I assume that you are probing the screw in the connector?
With no switch connected to the X limit connector, does the pin float high?
Make sure the screw is turned in to the empty connector position, or put your meter probe into the opening where the wire would go.
There is a 2.7K pull-up to 3.3V on each pin.
Flip look carefully at the board for solder overrun, etc from trace to gnd
ReferenceHowdy
Some quick items from visual scan of configuration:
1. Values of $xtr and $ytr look a bit unusual. NEMA 17s are usually 36.5ish, NEMA 23s usually 40.0ish (fine tune with good scale or micrometer)
2. You might want to set $xvm,xfr,yvm and yfr to something like 800 while you are in ‘bring up mode’, to give you time to react after issuing a move. Reset them to 16000 when you are satisfied everything is operating, or increment back up and keep checking machine dynamics while running some test GCode.But Neither of these comments directly addresses your limit issue.
By the way – if you machine bangs into a side, you can also hit the tinyG reset; which ever button is closer(reset or Emergency Stop). Either will stop the motors.
– Mechanical limit switches, or magnetic?
– When you say “Metered switches for open/closed”, was that at the switch or at the tinyG terminal block?
– Are you sure that the switches operate when X and Y are at the limits? You could simultaneously test the mechanical setup, the limit switches and your wiring by measuring the voltage on the tinyG pin with a voltmeter while you manually slide the axis toward the limits. If necessary, issue a $md first to release all motors. You should measure 0V when the machine is in the active area, 3.3V when a limit is hit.
– Your xsn, xsx, ysn, ysx, zsn and zsx parameters are sort of all over the place, I suspect you snapped this parameter set while experimenting. The suggested manual switch test above does not care about settings. Get limits working before trying homing.
– If all the switches pass the manual test, as measured at tinyG, set $xsn=2, $xsx=2, $ysn=2, $ysx=2. Zero your machine in the middle of the workspace. I usually manually move the gantry to where I want a zero point, then hit the reset button, zeroing the machine and re-enabling the motors. If your configs are correct, you will have about +-100mm in X, +-140mm in Y to play with while safely staying away from the rails. Now issue a G21 G1 X50 F100 command. This should initiate a slow(F100) move from the zero location to X=50mm. While the axis is moving,manually operate the X Limit switch, which should stop the gantry. Repeat for X-50, Y50, Y-50. After each quadrant test, you have to reset your zero.See if all these tests work.
OK, now understand the backlash discussion.
In addition to belt tension, another contributor could be motor “relaxation” between commands.
Depending on your motor power management settings, and the mechanicals of your machine, when the machine is stopped and the motors de-energized, there could be some movement of the system as the motors de-energize, if they were pulling against some tension in the machine.
I have a bit of this issue with my Xaxis due to some residual forces exerted by a non-ideal drag chain install.A test technique might be to run a series of test steps with the motors fully on, then repeat them with the motors de-energized between steps by executing
$md $mebetween each Gcode command. This will de-energize then re-energize all motors.
Good luck! Have fun!
