Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorUnderstand your goal, have some thoughts but not a working machine to test them on at the moment.
I am not sure there is a numerical solution for what you describe, if I understand correctly. My understanding is that traverse to Zmin has too much momentum when the switch is first contacted to stop and backoff properly.
Unknowns to tinyG and likely a typical user:
Mass of the moving element (in this case, a spindle?)
Strength of the Z axis motor (NEMA 17, 23, ec.)
Current setting on tinyG driver.I think you’ll understand my list – do I understand the issue correctly?
ModeratorHaving not seen reference to G28.4 before, I checked https://github.com/synthetos/TinyG/wiki/Gcode-Support and don’t see it listed, but some quick search and find it defined here for Smoothie http://smoothieware.org/supported-g-codes.
It could be documented somewhere else for tinyG – did you find it somewhere?
ModeratorThe bantam links above look like renamed forks originally owned by OtherMill.
And the entries appear to be ancient.Post this at G2core Issues and see if someone there has done what you are trying to do.
Going back to my original question tough, to your knowledge is there any way to leverage the probing repot information in a command like G10 L2 p2? or even in something like {“g55″”:{“x”:90,”y”:90,”z”:”0″}}?
ModeratorDisclaimer – I am a Forum Moderator, not developer, so am not privy to how Othermill came to market. What follows are some assumptions and best guesses.
When G2 got started, it was a fork of tinyG FW aimed at higher performance and capability ARM based controllers. DUE+ Gshield was an adequate test environment, but tinyGV9 was also created as an enhanced development tool. There were several interested users/developers who likely had an arrangement with Synthetos to obtain tinyGV9’s for inclusion in their projects.
The G2 focus rather quickly evolved from CNC focus to 3D printer capabilities and features. Several development hardware targets evolved for the 3D market, which I generally see as a superset of the tinyG target – 3 axis 4 motor milling machines. The range of (some of the) boards supported can be seen in the list of available downloads /github.com/synthetos/g2/releases/tag/101.03.
My summary: tinyGV9 is no longer the functionality target for G2Core, but the functionality needed to support your Othermill should still function OK, many folks have built around DUE+ for similar custom machines.
I would assume that FW 72.73 had some non-trivial modifications made by the Othermill team, but keyword is assume.
Looking at https://support.bantamtools.com/hc/en-us/articles/115001672154-Othermill-Pro, I see that the Othermill supports many more formats than just GCode, which says there is some CAM level software somewhere in the Othermill machine or perhaps in an Othermill PC application.If your are operating your Othermill using that higher level interface I would dig into just how well in interfaces to build 101.3. Start by fully understanding the switch to Line Mode protocol.
Or, perhaps bypass the Othermill interface and run 101.3 directly via CoolTerm, Chilipeppr, CNCjs or the like.Exercise caution when flipping back and forth between TinyG and G2Core wikis. Much is similar, but you will not see Ver 0.99 backported into the tinyG world for a while, if ever.
I also suggest you review ongoing Probing topics in https://github.com/synthetos/g2/issues, where bleeding edge topics get discussed.
ModeratorThe comment here suggests that attempting changes to $ms will likely have negative impacts.
Is your Gcode created in inch or mm? Inch moves create some inaccuracy dues to conversion calculations, you could try mm but doubtful it will help.
You could also try turning off arc (G2 and G3 moves), which will generate just linear moves with different computations but nearly identical results.It sounds like your Gcode is unnecessarily detailed, can you dial back the precision in the Gcode generator or it’s post processor?
ModeratorIt took me a bit to dig this out of the wiki
CAVEAT: At the current time because of various limitations of the Xmega we recommend waiting for each config command to send a response before sending the next command. This gives allows the system to persist the data to EEPROM, because during that interval the board cannot reliably receive serial input.
Good to review https://github.com/synthetos/TinyG/wiki/TinyG-Command-Line
ModeratorOn startup, tinyG will energize all motors to hold their current position for $mt seconds, then release. Motors will hum when so energised.
LEDs may or may not light during this, depends on what polarity the drive to motors is.
Motors almost never fail.
Are you sure that the lead wires are not broken?ModeratorThis stuff is difficult to read.
I extracted the following sequence from your post above
……
b'[xvm] x velocity maximum 1500 mm/min\n’
b’tinyg [mm] ok> \n’
b'[yvm] y velocity maximum 1500 mm/min\n’
b’tinyg [mm] ok> \n’
…
b'[xvm] x velocity maximum 1000 in/min\n’
…
b'[yvm] y velocity maximum 59 in/min\n’I am also not sure why you are bouncing back and forth between mm and in.
……
I am thinking perhaps I am only seeing responses from tinyG?
How did you set the original parameters?
How do you provide flow control with this scripting?Sending parameters and Gcode to tinyG needs some sort of flow control on the link, not obvious how you are doing that.
If you python script is writing too fast to tinyG, there is a chance that the parameter memory (EEPROM) has been corrupted, but I can’t tell for sure.
I suggest you get a simple, managed interface up and running, such as CoolTerm. Then dump a $$, copy and paste to file and post to a cloud drive – as you can tell, this interface make large files unreadible.
I am looking for something like THIS https://drive.google.com/open?id=1UfFv7x0vAvHA1Zi0dKH5_SssQsyxJXMV
ModeratorCan we assume you have reviewed and are familiar with this Wiki page: https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation ?
Are you running your machine from CoolTerm, Chilipeppr, CncJS, etc?
A full list of your parameter settings may be useful.
Run $$ in a console, copy and paste the listing into a text file, upload the text file to a cloud drive (Gdrive, Dropbox, etc) and provide a URL for reviewing it.When you say the machine stops, is the behavior as if you hit a limit switch, with tinyG stopped and flashing LED?
Are you set to home just X, or X and Y?ModeratorSince you are a Chilipepper user, I suspect that you unknowingly dragged a binary file onto your Gcode widget( an exe or some other non-text file).
The Gcode widget does not check, the statistics say this action will mimic a code download which overwrites your complete FW image with garbage. The continuous blinking translates to: you no longer have the tinyG bootloader, it does the 10 second blink process.So, your tinyG needs a new low level FW image.
If you have access to a Atmel ICE (or equivalent) you can do it yourself, or you can send it back to Synthetos and they will do it.
Have a look here for guidance if you have an ICE: https://github.com/synthetos/TinyG/wiki/SpDir-Continues-To-Flash-Error#re-flashing-tinyg–the-bootloader
If not, send a message to Synthetos at https://www.synthetos.com/contact-us/ , mention that you need a bootloader re-flash and they will provide mailing instructions.
ModeratorI believe that disconnected RTS and CTS default to no flow control, which should not be an issue with low speed traffic.
Chilipeppr does not use hardware flow control.
Did you connect TX to Rx and Rx to Tx ?Describe to me what you see from the tinyG LEDs when you press the reset button
ModeratorI found the part on Amazon.
Best way to connect would be to solder in a 4 pin header then connect with the Dupont wires providedModeratorIt looks like just Tx , Rx and Gnd are needed.
Connect with wire or by bending leads out of the way.
Soldering the interface directly into tinyG could be awkward to deal with.ModeratorBy the way – note on the schematic that RTS/CTS pins are not connected.
That should not affect Chilipeppr, might affect a sender app requiring RTS?CTS
ModeratorFirst and foremost, I don’t have time to dig in to the Moynina spec sheet, up to you to make sure that levels out of the Adapter into the tinyG controller are 3.3V logic.
5V will kill the tinyG.Here is the schematic page you need
https://github.com/synthetos/TinyG/blob/master/hardware/v8schematics/v8h/tinyGv8h%20-%20schematic%20page1.pdfYou want to connect the Moynoia interface to J14 on tinyG.
Just like the FTDI on the tinyG board,
Tx connects to J14 Rx, Rx connects to J14 Tx. -
AuthorPosts
