Forum Replies Created
-
AuthorPosts
-
cmcgrath5035Moderator
Just a thought for you to contemplate until Riley or Alden pop in.
In fixing something in the most recent build of tgFX, Riley had to change flow control to RTS/CTS, away from Xon/Xoff. Since your problem sounds like buffer over run, perhaps you can experiment on that path?
That would be $ex=2.
Good luckcmcgrath5035ModeratorMakerboost – Good catch, yes I am building a doubleX ACME doubleY machine, extended but not as large as yours.
I thought I had caught all those parameters – so many numbers….I will revisit your suggestions when I am doing real drawing/milling; for now just getting comfortable with the tool chain as I finish the build.
Thankscmcgrath5035ModeratorThis is total speculation on my part – perhaps avrdude on windows expects a .txt file for it’s hex to binary processing to work properly?
I left Windows a long time ago for Linux and have forgotten some of the unusual rules regarding handling binary files.Anyway, sounds like you are up and running.
Might I suggest to check around for CoolTerm – it seems to be a popular low level interface useful for communicating with a TinyG.
I use Putty myself, primarily because it is available Linux and Windows.As for tinyG, review this thread
I am seeing some good results with this latest EDGE (== beta) version that Riley is working on.
cmcgrath5035ModeratorThanks for that! I’ll try it. When it flashed it said it was flashing 204K so it probably didn’t convert correctly if it’s supposed to flash 100K right?
You are correct, that number looks bad – I flashed 102724 bytes.
Was that with your file or my file?
What version of avrdude do you have.
I ran with 5.11.1 on Linux.cmcgrath5035ModeratorThanks for the check out, I am now having fairly consistent good success running Prevues with TinyG 0.96/380.08 and tgFX EDGE 2404 as well.
Here are the current parameters I am using
Here are the results
Riley thinks he knows where the intermittent lead-in bug is, otherwise looks very good.
IMHO, your P4 may not be enough horsepower to run this java app. Can you try it with a P5 or higher to test your setup?
cmcgrath5035ModeratorI finally got my FW updated, reran and created a new Github Issue #26 summary.
I like what I see.
cmcgrath5035Moderatorareinike
Try to grab the file from my dropboxThe size should be close to 282.2 KB, may not be exact because of differences between Linux and Windows interpretation of “K”.
If , in running avrdude, you see
avrdude: writing flash (102724 bytes):
you will probably be good.
Good Luck
Just reread your post – 283K is probably the right Windows size.
You could read it, so it is probably ASCII.
My guess is that avrdude does the ASCII–>Hex conversion before sending to the bootloader- This reply was modified 11 years, 1 month ago by cmcgrath5035.
cmcgrath5035ModeratorSorry, too late to edit prior post.
I should have commented that wget is most likely available in OSx, not IOS in addition to Linux.
A quick Google search on “wget windows” finds several free downloads for a similar utility, should someone wish to experiment.
cmcgrath5035ModeratorOK, now I see the error in my ways.
In Linux, the easiest way to get such a file is the cli command
wget https://raw.github.com/synthetos/TinyG/master/firmware/tinyg/default/tinyg.hex
Probably same in IOS, sorry, not sure for Windows.Ran Avrdude 5.11.1
avrdude -p x192a3 -c avr109 -b 115200 -P /dev/ttyUSB0 -U flash:w:tinyg.hex Connecting to programmer: . Found programmer: Id = "XBoot++"; type = S Software Version = 1.7; No Hardware Version given. Programmer supports auto addr increment. Programmer supports buffered memory access with buffersize=512 bytes. Programmer supports the following devices: Device code: 0x7b avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9744 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "tinyg.hex" avrdude: input file tinyg.hex auto detected as Intel Hex avrdude: writing flash (102724 bytes): Writing | ################################################## | 100% 11.23s avrdude: 102724 bytes of flash written avrdude: verifying flash memory against tinyg.hex: avrdude: load data flash data from input file tinyg.hex: avrdude: input file tinyg.hex auto detected as Intel Hex avrdude: input file tinyg.hex contains 102724 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 9.42s avrdude: verifying ... avrdude: 102724 bytes of flash verified avrdude done. Thank you.
On connection via Putty, I get
$ [fb] firmware build 380.08 [fv] firmware version 0.96 [hv] hardware version 8.00 [id] TinyG ID 9H3906-P2T [ja] junction acceleration 100000 mm [ct] chordal tolerance 0.001 mm [st] switch type 0 [0=NO,1=NC] [mt] motor disble timeout 60 Sec [ej] enable json mode 0 [0=text,1=JSON] [jv] json verbosity 4 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose] [tv] text verbosity 1 [0=silent,1=verbose] [qv] queue report verbosity 0 [0=off,1=filtered,2=verbose] [sv] status report verbosity 1 [0=off,1=filtered,2=verbose] [si] status interval 250 ms [ic] ignore CR or LF on RX 0 [0=off,1=CR,2=LF] [ec] expand LF to CRLF on TX 0 [0=off,1=on] [ee] enable echo 0 [0=off,1=on] [ex] enable flow control 1 [0=off,1=XON/XOFF, 2=RTS/CTS] [baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400] [gpl] default gcode plane 0 [0=G17,1=G18,2=G19] [gun] default gcode units mode 1 [0=G20,1=G21] [gco] default gcode coord system 1 [1-6 (G54-G59)] [gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64] [gdi] default gcode distance mode 0 [0=G90,1=G91] tinyg [mm] ok>
Looks like I live to fight another few hours, at least.
Big day: Ready to connect my ShapeOko
cmcgrath5035ModeratorDoes that make sense?
I understand, I think, what you are saying and for sure would agree that driving the motors as accurately as possible is top priority.
This discussion causes me to pause and rethink the “ideal” workflow target. My assumption was that tgFX would be a combination GCode verifier (visual confirmation), GCode sender and TinyG setup/parameter manager. I am not sure of the usefulness of the “Prevue” window if it is possible/probable that it will display errors that will not be present in the machined result. I need to think about that some more.
What would seem to make sense would be to have an ‘accurate’ Preview mode that could be optionally run with the motors inhibited and the TinYG processing slowed to ensure accurate presentation of the GCode result, then run ‘at speed’ for production purposes.That is sort of easy to write here, I have no idea what the internals of the Atmel device permit you to do. Is that what you have in mind when you say “drawing the whole preview upfront and just using the status reports to say where the cursor is ” ?
It is really not clear what the value of drawing on the screen is during a production run, particularly if it is not guaranteed accurate. It would be useful to display some metric on progress, such as “% of GCode lines processed” or something like that.
I guess the good news here is that a small arc bug was found and fixed as a result of this dialog. It is not 100% clear if that bug would have affected motor movements as well as the display drawing but good to know it is fixed.
A VERY USEFUL addition to this forum would be a Topic Pinned to the top that announced new TinyG FW file availability, similar to the Topic that displays the current tgFX files. That location catches your eye when you enter the forum.
It was not real clear that TinyG was at all involved in the fixes you pushed as tgFX EDGE build 2404.cmcgrath5035ModeratorWell, that’s too bad.
I downloaded that TinyG.hex file to my Linux system, then ran avrdude 5.11.1. My results are the same areinike, a flashing brick.avrdude -p x192a3 -c avr109 -b 115200 -P /dev/ttyUSB0 -U flash:w:tinyg.hex Connecting to programmer: . Found programmer: Id = "XBoot++"; type = S Software Version = 1.7; No Hardware Version given. Programmer supports auto addr increment. Programmer supports buffered memory access with buffersize=512 bytes. Programmer supports the following devices: Device code: 0x7b avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9744 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "tinyg.hex" avrdude: input file tinyg.hex auto detected as raw binary avrdude: writing flash (204800 bytes): Writing | | 0% 0.00savrdude: butterfly_recv(): programmer is not responding
It would be helpful if Alden could post what version number avrdude the downloader was tested against, since there is not a clear answer as to which version of avrdude is made available with the arduino (referenced on the wiki)
The good news is I still have your address in my Priority Mail address book, you will be seeing my TinyG V7 soon for reprogramming, I don’t have a programmer.
cmcgrath5035ModeratorI am searching for the correct hex file for TinyG 380.08.
If I look hereI see a tinyg.hex in default and Debug, nothing in Release
The two .hex files are not the same (different length.Which is the one to download and install?
cmcgrath5035ModeratorMakerboost
Can you try to run a Prevue (Motors inhibited) of the ShapeOko hello-world Gcode found at
I have been having issues (distorted characters) with it, and I wonder if your configuration parameter set is better than mine.
If it works, can you post your current $$ dump?
Thanks
cmcgrath5035ModeratorI posted some first round observations in a GitHub Issue – #25.
I’ll help as I can with the Wiki, but see we are starting from a true blank sheet of (virtual) paper. Do you have an outline in mind?
I also found that my TinyG is no longer ‘most recent’ as I am at FW 0.96/380.05. I am not going to try to move to 0.9??/380.08 until Alden replies to overnight install issues from Makerboost and others.
cmcgrath5035ModeratorOK, I have done a bunch of research across the Synthetos and ShapeOko forums and wikis and come up with some new results.
First – What I have
TinyG HW ver 7, FW 0.96
tgFX build 2072 32 bit running on winXP32bit (VBox VM openSUSE 12.3)
ShapeOko I am building a Dual Y (Motors 2 and 4) with the ACME Z axis upgrade, distance per rotation values I believe are consensus correct but I am somewhat unclear on appropriate jerk and velocity TinyG settings.The settings file is here
I ran the ShapeOko GCode file
And get these results (4 runs, moved 0,0 with G0 commands)
The issues with S and sometimes h are obvious, as are more subtile errors with a.
Also note that sometimes the Z axis starts cutting before the X and Y reach their destination on short horizontal moves.I will continue my research and tweaks, would appreciate your eagle-eye on what might be incorrect or sub-optimal settings.
-
AuthorPosts