Rhinofart

Factory reset, and then re-configuring made everything work perfectly. No longer getting that slow movement to the cutting area. My lotsoshapes GCode file now takes under 2 minutes to do with no changes to the GCode. Pretty darn happy with this TinyG, and OX configuration. ;0) Time to make some sawdust!!!

Yes, I’m running from a 12v supply right now. I have no problems going up to a 24v unit. I think I’ll actually pick one up. The 12v supply was just me being too cautious I think. But, as it stands right now everything is working since I changed my power wire going to the TinyG. I am definitely going to upgrade to a better powersupply. Need more volts & amps! ;0)

I have $[xy]vm at 10000, and $zvm at 1000, and everyone is doing max velocity G0 moves now with no problems.
Thank you guys so much for the help. I hope that I soon become knowledgeable enough to help pay it forward.

Rhino.

Hey guys.
Those settings in the config file are what I was running during the tests.
I did do a bunch of testing with the velocities, and feed rates on all 3 axis. I would adjust the Max Velocity, and Feed rate Velocity up by 1000 increments. Then I did a G1 f(insert number from 2000 – 10,000) x300 then G1 f(insert number from 2000 – 10,000) y500 and then G1 f(insert number up from 200 – 1000) Z29
Every single test worked perfectly fine all the way up to 10,000 even with my spindle attached. But, when I go and do a G0 command on ANY of the axis, it starts to move, motor makes a weird noise, and it looses all the steps. I have no clue as to where it is getting the velocity speed for the G0 command. I’ve gone through the $$ “printout” from within Coolterm, and tgFX. Seeing as I have a capture of the config file for reference, I may do a “factory reset” and try it all again. I’ll do up a quick little video showing what I did for the testing, and post it up. You guys would likely know by the sound of the motors and such what they are doing. I also did the AMP calibration on the motors as well.

The $[xyz]vm is velocity maximum correct? Also, I’m not sure about the jerk rating. I’ve not been able to find a good explanation of what that kind of jerk is.

The 50 mm/min velocity value is unknown to me.

The lead screw to coupling is good and tight. It’s not spinning out at all.

Just out of curiosity, how easy should the gantry be able to move? Mine has a little bit of resistance to it, but I don’t think it’s too bad….

Wow! What a novel!

Sorry for the long response time. Work got busy for me. I’ll try to address your questions in order. ;0)
400 step per rev motor? I really don’t know. It’s just what was sent to me when I ordered off the parts list that they provided.

Yes, it’s basically a direct drive for the Rod. There is a flexible coupling that attaches to the motor shaft, and then to the threaded rod.

For the Z movement, that is what I was able to calculate based on a few internet “calculators” that took into account degrees per step, rod pitch, etc. I’m really new to this, so I’m trying to learn everything at the same time. The details on the threaded rod I have are:
•Tr8*8 No idea what this means
•4 Start No idea what this means
•Pitch 2mm Used in my calculations along with motor info.
•Lead 8mm Used in my calculations along with motor info.
But, yeah. I see what you mean. 1 complete revolution of the rod shouldn’t go 16mm now that I think of it. But strangely, when I do distance measurement testing, all 3 axis are spot on with the numbers I’ve entered.
When I was testing and calibrating the movement on the X and Y, that was the only number that got me accurate for my movement tests. Yes, my feed rates are a lot slower when it’s “performing it’s cut” I don’t have my spindle attached yet.

I’ll upload the quick little G-Code I created in Sketchup / Sketchucam to my drop box.

Squirly Z. Well, when I start a job, It brings the Z axis up, moves over into the work area (It does this really really slowly I might add. It takes a few minutes to move the gantry. Slowly ramps up to a velocity of 50mm/minute until it gets to where it needs to drop the spindle) Then the Z goes down into the workspace, but goes down way too far, and bottoms out on the bed. If I pause the job, manually move my Z up, and resume, it goes about it’s business fine. I figure it’s got to be some sort of weird configuration / faulty end user issue, but I’m at a loss of where to start. I have some limit switches enroute, but they won’t be here for about a week. I plan to use them as limit, and limit/homing sensors. Do you think that would help my cause out?

Thanks a bunch for the help.
Rhino