cmcgrath5035

Forum Replies Created

Viewing 15 posts - 1,741 through 1,755 (of 1,771 total)
  • Author
    Posts
  • in reply to: XBee serial attachment to TinyG #4904
    cmcgrath5035
    Moderator

    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 luck

    in reply to: New tgFX Pushed #4821
    cmcgrath5035
    Moderator

    Makerboost – 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.
    Thanks

    in reply to: Flash v8 to 380.08 now TinyG not working #4820
    cmcgrath5035
    Moderator

    This 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.

    in reply to: Flash v8 to 380.08 now TinyG not working #4812
    cmcgrath5035
    Moderator

    Thanks 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.

    in reply to: New tgFX Pushed #4811
    cmcgrath5035
    Moderator

    Thanks 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
    ShapeOko Preview

    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?

    in reply to: New tgFX Pushed #4805
    cmcgrath5035
    Moderator

    I finally got my FW updated, reran and created a new Github Issue #26 summary.

    I like what I see.

    in reply to: Flash v8 to 380.08 now TinyG not working #4803
    cmcgrath5035
    Moderator

    areinike
    Try to grab the file from my dropbox

    The 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.
    in reply to: Flash v8 to 380.08 now TinyG not working #4800
    cmcgrath5035
    Moderator

    Sorry, 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.

    in reply to: Flash v8 to 380.08 now TinyG not working #4799
    cmcgrath5035
    Moderator

    OK, 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

    in reply to: New tgFX Pushed #4797
    cmcgrath5035
    Moderator

    Does 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.

    in reply to: Flash v8 to 380.08 now TinyG not working #4796
    cmcgrath5035
    Moderator

    Well, 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.

    in reply to: Flash v8 to 380.08 now TinyG not working #4793
    cmcgrath5035
    Moderator

    I am searching for the correct hex file for TinyG 380.08.
    If I look here

    I 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?

    in reply to: New tgFX Pushed #4790
    cmcgrath5035
    Moderator

    Makerboost

    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

    in reply to: New tgFX Pushed #4787
    cmcgrath5035
    Moderator

    I 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.

    in reply to: Errors running test GCode woth tgFX and TinyG #4751
    cmcgrath5035
    Moderator

    OK, 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.

Viewing 15 posts - 1,741 through 1,755 (of 1,771 total)