New tgFX Pushed

Home Forums TinyG TinyG Support New tgFX Pushed

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #4782
    Riley
    Keymaster

    Hey guys I pushed a new Edge version of tgFX. Meaning that its still being tested. However I added Jogging and a few other fixes. I also fixed a bug that was causing arc’s to mess up. I have not been able to replicate this since I enabled RTS as my flow control method. Here is a pic.

    tgFX build 2404

    Jogging works by mouse over the CNC preview area once connected. Then you just use arrow keys to move. Hold shift and use arrow keys if you want to jog “fast”. To stop jogging just release the key.

    Also, Z jogging is possible by using – and = keys. Again shift will do a “fast” jog on z as well.

    I know there are a few drawing bugs still in the mix (2 new ones I introduced to fix 2 older bugs…ugh)

    Please go to https://github.com/synthetos/tgFX and open issues if you find bugs. Just mention your build number in the issue. Also, lastly! I know my documentation is pretty non existent on tgFX. If anyone has some time and would like to do some wiki editing on the https://github.com/synthetos/tgFX site…Perhaps toss a few photos up etc I would appreciate it a ton! I will go over it of course.

    Right now I think we are mainly missing usage, read that as “how to use tgFX”. But anything is welcome. Thanks for all the help guys/girls. Let me know if there is anything that is “really missing” from tgFX that we need. My next plan is to tackle tgFX updating firmware.

    ril3y

    • This topic was modified 10 years, 11 months ago by Riley.
    #4784
    Makerboost
    Member

    I’m really excited about this new build.

    I will definitely try to help with the wiki in any way I can. Can’t really use my machine reliably at the moment, so I have some time between designs and tweaks for testing out tgFX, and then I might as well take som notes and screenshots 😉

    • This reply was modified 10 years, 11 months ago by Makerboost.
    #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.

    #4789
    Makerboost
    Member

    I got to play a little with the new tgFX version.

    Did not go so well 🙁

    Here’s a video of me just trying it out, pushing some buttons and really showing the UI lag. This is a Pentium 4 machine with Windows XP SP3, 512MB RAM.
    Very unresponsive overall.

    https://www.dropbox.com/sc/lifnyfrrud1h4d6/M2QiXN8dci

    #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

    #4791
    Riley
    Keymaster

    Makerboost,

    I am not sure what is going on with your system. I have only tested this on Win7. Why the preview is not working is because it did not get the axis settings. So it defaults to that little square. If I had to guess it’s lack of memory? Java is a bit heavy.

    I think it would have worked if you were to hit “query” on the axis tabs.

    It should redraw your canvas. However, I am still not sure why it did not get the settings on its own. I am going to code in a “debug” mode which will print all commands (recvd and sent) to a log file. That way i can see what happened. I will try to get that tonight.

    cmcgrath,

    380.08 is master. That is the firmware you should be using. If you are not then there are bugs in your setup. Specifically you have an arc bug. The same bug that was discovered in that “Ford” file.

    Distorted drawing’s are not a true indication that its not working. The preview will “suffer” if your machine is running too fast or your jerk value is very high or travel per rev is off. There are lots of factors for this. Also your feed rates and how small the lines are in the gcode file.

    The preview is suppose to get you close. But unless you have issues (not mechanical 🙂 with milling looking the same as the “off” parts in the preview then I think its fine.

    The reason for this is there is a max to how fast tinyg can report status reports back. All status reports are used to draw the lines on the canvas gui. So in order to not make the motors mess up it sacrifices status reports and makes sure the movements in the motors do not suffer.

    Quite honestly, I should be drawing the whole preview upfront and just using the status reports to say where the cursor is at any given time. However, I am not at the moment 🙂

    Does that make sense?

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

    #4805
    cmcgrath5035
    Moderator

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

    I like what I see.

    #4806
    Makerboost
    Member

    cmcgrath5035: I tried your code, ran perfectly fine for me. (with Coolterm)

    I upgraded my machine with 1GB RAM, and it made no noticable impact on the UI lag.

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

    #4813
    Makerboost
    Member

    I’m going to try tgFX with my Intel i7 950 machine with Windows 7 x64 and 12GB RAM.

    cmcgrath5035: Are you using a dual Y motor solution? You might want to change the $4tr setting to 36.540 mm instead of 360 to make it the same as your other Y motor. Also make sure to set motor 2 or 4 to reversed, depending on your wiring.

    Try to change the following values aswell. It creates a smoother operation with less jerk at end of lines.
    $ja=50000
    $xjm=1000000000
    $xjh=10000000000
    $xjd=0.02
    $yjm=1000000000
    $yjh=10000000000
    $yjd=0.02
    $zjm=5000000000
    $zjh=10000000000
    $zjd=0.05

    Personal preference, but you’ll find your own by experimenting 😉

    #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

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