Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorHow long before I hear back from support? Any way I can know if they even received my request? Thanks
I will ping them
ModeratorThe motor $_pm=2 looks good on all 4 motors.
All four motor LEDs (green) should flash on for $mt (= 2 seconds) on startup.Sounds like you might have a bad M1 driver, send a message to https://synthetos.comcontact-us and they will suggest a replacement strategy
ModeratorWelcome to CNC.
First recommendation would be to recheck the motor wire connections between the steppers and the tinyG terminals.
It is fairly easy to push the wires too far into the terminal block, then clamp down on the insulation, not making connection to the leads.
It is also easy to break the very fine wires it the stepper end.If still no success, run a $$ parameter report, scrape the screen to a text file and upload that text to a cloud drive, posting a URL here.
Next suggestion will be to swap leads at the tinyG end between the two (as I read it) X to see if the problem appears too be tinyG or perhaps a motor motors.
Also, describe what you see on the tinyG LEDs when you power up the board.
ModeratorGlad it worked.
ModeratorQuick thought (it’s late)
I think $xfr=800 is limiting in X , not $xvm
Give it a try
ModeratorOdd behavior indeed.
What Gcode sender you use?Please run $$ report and copy all results to a cloud drive, post the URL here.
That will provide a good basis for understanding your setup.
ModeratorChilipeppr adds a lot of user control to the basic tinyG interface, much of which depends on a well running tinyG.
Cnc.js provides a similar user environment, but may not help since something seems flaky with your base machine.I’d suggest you head to the tinyG wiki and then
then the Coolterm option. Experiment with just sending Gcode a line at a time from the command console directly connected via USB.
Do you have limit switches on your setup?
If not, are limit inputs properly disabled?The behavior you describe suggest tinyG is resetting as a result of movements. Noise on limit switch lines is a possible cause.
A dump of parameters may help this discussion.
Run $$ in Coolterm, copy the results to a text file, post it to a Cloud drive and provide a URL for a review.ModeratorYou may have seen these items on the topic
It appears some items are addressed in a version of G2core (see third reference)
ModeratorI am going to ask a developer to weigh in on this.
It is not 100% clear the full RS485 network functionality was completed.
The references you provide (thanks) are very old.
There may be some undocumented ways to achieve your goal.ModeratorEEPROM can be corrupted if too many sequential parameter updates are sent too quickly. It often takes a lot of back and forth chat to find it, figured we would jump to it. Some of the parameters written to EEPROM are not viewable, so it can be hard to diagnose.
Easier than doing a FW reload, and EEPROM more likely to get corrupted than flash.
You will have to reload parameters after FW re-load as well.
Make sure your Motors are enabled, by the way.
$m1=2
$m2=2
etc.If still no work, copy your $$ parameter list to a cloud drive and post a URL here.
I’m sort of running out of ideas.ModeratorI am thinking perhaps something is corrupted in EEPROM.
Send a $$ command, capture the resulting parameter list in printout or ascii file.Send a $defa=1 command to clear and reset EEPROM to a ‘factory default’
There reset all parameters, one at a time ,., from a command line interface.
Reboot tinyG (power cycle) and see if situation has improved.
ModeratorI am a forum guy, not a developer and am aware of the RS485 link, you are only the second in 5 years I have had show interest/ask questions. The other individual needed 6 motor drivers. I have never seen a reference to networking 1000 axes, so not sure what application was intended. Send me a link if you still have it.
Each instance of tinyG FW can decode up to 6 axes of motion, but only 4 of six can be connected to stepper drivers, the on-board ones or external.
ModeratorRe-read a few items.
Other ideas.Jog: It is fairly easy to configure Chilipeppr jog to request jogs that are too small to actually generate motion.The minimum specified jog that will move the machine the distance of one microstep. If you request a jog of microstep/2, you will have to send 2 jog commands. TinyG accumulates requested motion that is less than a microstep, adds that to the next request.
Motor LEDs. each motor has one LED connected to one of the two stepper windings. Run a continuous stream of G code and you see flashing lights, cool something is happening. But the LEDs toggle based on winding polarity and randomly when the specified motion calls for reverse polarity the LEDs do not flicker. So the LEDs are not a precise indicator of step by step motion.
Most folks adopt one or more Gcode sequences that they run and look for
1.expected results
2. If codded to start from X1,Y1,Z1 and return to X1,Y1,Z1 an end of sequence, does that actually happen?As for the strange behavior you see with the TESTx commands, you might get some help from posting here https://github.com/synthetos/TinyG/issues
ModeratorSounds like you resolved your issue, cool.
BTW, I use a simpler Gcode generator.
Has and option “Use Arcs Y/n”ModeratorThe tinyG wiki is here, it might come in handy
https://github.com/synthetos/TinyG/wikiTinyG firmware only recognizes 6 axes names
X,Y,Z which are linear motion
A,B,C which are rotational (but can be spoofed to do linear motion)Since you have two boards, I’ll talk to your issue referring to Board 0 with axes X,Y,Z and A, and Board 1 with axes X1, Y1, Z1 and A1.
I’ll assume you are generating your Gcode manually with commands for X,Y,Z,A,X1,Y1,Z1 and A1.
Whatever your Gcode sender is, you will have to separate commands for X1,Y1,Z1 and A1 axes, rename them to X,Y,Z and A before sending those to Board 1.
I am not sure how much coordination you need among the 8 axes, you may need to generate the Gcode such that Board 0 commands run, then Board 1 commands run for every move, it will be slowThe tinyG motion planner might get in your way as well. Basically, the firmware reads ahead several Gcode moves and computes third order polynomial inertia modified (jerk) motion equation to traverse that continuous path while maintaining accurate adherence to the specified path.
I’ll stop here and see if this makes any sense to you
-
AuthorPosts
