Home › Forums › TinyG › TinyG Support › New tgFX Pushed
- This topic has 11 replies, 3 voices, and was last updated 11 years, 1 month ago by cmcgrath5035.
-
AuthorPosts
-
October 16, 2013 at 1:04 am #4782RileyKeymaster
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.
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 11 years, 1 month ago by Riley.
October 16, 2013 at 2:05 am #4784MakerboostMemberI’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 11 years, 1 month ago by Makerboost.
October 16, 2013 at 10:17 am #4787cmcgrath5035ModeratorI 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.
October 16, 2013 at 3:48 pm #4789MakerboostMemberI 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.October 16, 2013 at 5:17 pm #4790cmcgrath5035ModeratorMakerboost
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
October 16, 2013 at 6:13 pm #4791RileyKeymasterMakerboost,
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?
October 16, 2013 at 11:40 pm #4797cmcgrath5035ModeratorDoes 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.October 17, 2013 at 9:40 am #4805cmcgrath5035ModeratorI finally got my FW updated, reran and created a new Github Issue #26 summary.
I like what I see.
October 17, 2013 at 2:44 pm #4806MakerboostMembercmcgrath5035: 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.
October 17, 2013 at 3:59 pm #4811cmcgrath5035ModeratorThanks 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?
October 17, 2013 at 4:12 pm #4813MakerboostMemberI’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.05Personal preference, but you’ll find your own by experimenting 😉
October 17, 2013 at 10:42 pm #4821cmcgrath5035ModeratorMakerboost – 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 -
AuthorPosts
- You must be logged in to reply to this topic.