Errors running test GCode woth tgFX and TinyG

Home › Forums › TinyG › TinyG Support › Errors running test GCode woth tgFX and TinyG

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • October 8, 2013 at 12:43 pm #4721
    cmcgrath5035
    Moderator

    I have TinyG(hw v7, FW 0.96) connected to tgFX Build 2072 32 bit on a WinXP32 bit machine.
    TinyG is powered by a 12V supply, but no motors are connected, just power and USB.

    I have downloaded the ShapeOko “Hello world” GCode from here

    tgFX starts up. I set all motors to inhibited.

    I set the machine to the middle of the display window, then right clicked the mouse and set the machine location, then I Loaded the Gcode and selected Run.

    The tgFX display proceeds to trace the action of the tool.
    However, I notice in a few locations the green trace does not follow the expected smooth tool path, in some cases a node is completely skipped.
    I have rerun the Gcode several times, the errors appear to occur in the same area of the job, but not always with the identical trace.

    Any ideas on what might be happening? It can’t be thermal – the only component on TinyG even “warm” to the touch is the voltage regulator next to the fan jack. As I said, there are no motors connected.

    My impression is that this is what is happening:
    1. TgFX sends a row of GCode to TinyG .
    2. Tiny G computes movement instructions for the motor drivers.
    3. Somehow the intended results of the motor movements are converted back to coordinates, and that data is sent back to tgFX and displayed.
    4 Next row of GCode.
    Is this even close?
    I suppose it is possible that the tgFX display is actually generated within the PC, by a virtual TinyG emulator of some sort.

    Rather than running my imagination wild, perhaps there is a design-intent document or the like that describes what tgFX is doing?

    I’ll soon have my ShapeOko ready and then can see if it actually draws the same defective traces as I am observing on tgFX.

    October 9, 2013 at 10:10 am #4725
    cmcgrath5035
    Moderator

    To speed the discussion, I’ll add that my errors look similar to those posted by LTMNO in this ShapeOko post

    although in my case “h” and “a” get somewhat mangled as well.

    I interpret from the discussion there that these are somewhat known bugs in tgFX and my assumption is that they still exist in tgFX 32bit build 2072.

    October 9, 2013 at 9:16 pm #4728
    Riley
    Keymaster

    What version of tgFX are you using? Also what is your firmware version.

    2072 should NOT be doing this still. If it is its new to me. Can you elaborate? Also can you attach the file that is messing up?

    Riley

    October 10, 2013 at 9:04 am #4730
    cmcgrath5035
    Moderator

    Riley
    Info requested is at top of first post, repeated here:
    TinyG (hw V7, FW 0.96)
    tgFX is “tgfx_windows-x32 v.95 – build 2072.exe” from dropbox.
    The GCode file is from ShapeOko site

    I’ll try to figure out how to attach it, but at the moment do not see how

    I have run it now on two separate machines
    1. WinXP 32 bit Virtual Machine (VBox on openSUSE 12.3)
    2. Win7 32 bit Virtual Machine (VBox on openSUSE 12.3)

    ((Note that in another post I reported the dropbox 64 bit tgFX build 2072 does not install properly on my 64 bit machines))

    The results are similar on both, mangled S, h and a characters then OK for the rest of peOko. Results slightly different each run. I’ll also note that I do occasionally get a ‘clean’ run of the job.

    Observation: I opened Windows Task Manager (ShiftCtl-Esc) and watched as the GCode is executed. CPU pegged at 98% or more for the entire run. Phys Memory runs around 50%. Something in the java implementation seems terribly inefficient or slow to “get started”? Not at all clear to me why Sha would be more difficult to process than peOko.

    I’d be happy to run some test GCode you might have to compare.

    I would expect you to question the VMs I am running. I am not sure what metric would be helpful, but will comment that both machines (one a desktop, one a laptop) both provide the ‘spiffiest’ response I have ever experienced with Windows.

    The only native Win7 machine I have is 64 bit. I’ll try to run the 32 bit on that, but as I said I believe there is something wrong with the 64 bit build 2072 package on dropbox.

    • This reply was modified 10 years, 11 months ago by cmcgrath5035.
    October 10, 2013 at 7:52 pm #4734
    Riley
    Keymaster

    Ok I will look into this.

    Can you post yor settings?

    $$ output?

    Thanks,

    Riley

    October 11, 2013 at 8:28 am #4744
    cmcgrath5035
    Moderator

    A Putty logfile is here in my dropbox

    Seems better than trying to screen scrape from here using a code block.

    The log window in tgFX seems to be always double spaced (row of output, then blank row), is that intentional?

    Is it possible to capture a logfile (write to log during session) from tgFX?

    October 11, 2013 at 11:02 am #4746
    cmcgrath5035
    Moderator

    Riley – Ignore this for the moment. I realized that the parameters posted at 8:28 am above were defective. I am working on a better set, will repost with updated results.

    October 12, 2013 at 10:07 am #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.

    October 12, 2013 at 12:53 pm #4754
    Riley
    Keymaster

    Check this out.

    https://github.com/synthetos/TinyG/blob/master/firmware/tinyg/settings/settings_shapeoko375.h

    That is the settings we use for Shapeoko setups. Shapeoko V1 of course… I am not sure if this is going to be the same for v2. This is a disclaimer for anyone getting to this post after Shapeoko v2 is released.

    Still working the arc issue bug that you found.

    Riley

    January 15, 2014 at 4:19 pm #5163
    Gopal
    Member

    Hi Riley,
    I was slowly getting into interfacing TinyG to tgFX and last night (around 2am) I even ran the Stepoko test pattern without any distortions. My system parameters are:
    HD ID 1H4973-2YM V8 Firmware 0.96 Build 380.08
    tgFX V 0.96 EDGE build 2404.
    OS Win 7 64bit

    After that I tried to configure the unit as per the Stepoko and then everything went crazy with the preview – no screen trace and XYZ axes do not update even though the preview is enabled.

    I installed your latest version V0.95 2072 – NO CHANGE
    The motors run ok BUT NO PREVIEW or position / Feedrate update

    Also, how do I get into the jog mode – I see it some times but then lose it.

    Thanks in advance
    Gopal

    What have I done wrong –

    January 15, 2014 at 8:34 pm #5165
    cmcgrath5035
    Moderator

    Gopal
    I tested in much the same manner as you are now.
    Review what worked for me at and compare to your settings.
    I am having truble providing a link to my old post, look back in a little while

    • This reply was modified 10 years, 8 months ago by cmcgrath5035.
    January 15, 2014 at 8:41 pm #5167
    cmcgrath5035
    Moderator

    Search for my post on October 18 , 2013

  • Author
    Posts
Viewing 12 posts - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.