cmcgrath5035

I have no applicable experience with lead screw machines, but would offer the following comments.

Question1 – Not clear what you are using for a spindle. You’ll need a lot of torque to make cutting speed in plywood, for sure in Al. Torque generally translates to mass, which raises the question of strength of the X Axis cross member.

Questions2 – Your description translates to likely long runs due to relatively slow lead crew movement, for sure in AL. Longs runs translate to potential heat build-up in the drivers. I have seen references suggesting that higher voltage (I believe it is 36V max) is better under high load conditions. I’d search about, hopefully someone with applicable experience will stop by and comment. Be mindful of your thermal design.

Question3 – Yes, some form of computer will be required to continuously stream the GCode. TinyG has a limited code buffer.

Sounds very interesting, be sure to post a picture when you are done!

• This reply was modified 10 years, 8 months ago by cmcgrath5035.

It is reasonable to assume that the Dual Y tinyG config file would work, but better to confirm with a dump and post – always possible that the configs did not get properly saved by tinyG, I suppose.

Can you expand a bit on your comment

They are wired up just like the 17 motor but still won’t work.

I have found there to be nothing standard about NEMA wiring and color codes, etc. So can you expound on what “just like” means?.

For example, if only one phase was actually connected, it would probably just buzz.

How many wires for each motor? My Nema 17s are simple, just four wires.
But a NEMA 17 from a different supplier had radically different color coding.
I have also seen motors with 6 or 8 leads as well (center taps, two “half” windings)

Have you tried both the X and Y NEMA23s?
It is possible the two Y motors are fighting each other, of course X is all by itself.
For X and Y, you might want to slip the belts off the pulleys (remove load) until you get some spinning happening.

So is this not normal? Should I try to send back the Tinyg or do you think it will be ok in the future.

Normal – no, I don’t think so.
Send back – no, you should be good to go now.

CoolTerm – I am not sure what your issue might be – I don’t use it. Perhaps someone else will add some flavor.

Now that you are up and running, time to configure tinyG to interface to your machine.

When you get a chance – what FW build was in your tinyG? What tgFX build you running?

Good luck with your first cutting job!!

Try a $[CR] in the command window, to see if you can grab the tinyG FW version from the short status report. Or look on the tgFX Machine Tab.
You might also try the reset button (on tinyG), in case, perhaps, of an un-clean powerup.

I have not experienced this behavior.

Hmmm, perhaps I am out of sync a bit; where did you find tgFX build 3259?

Anyway, build 3256 (or probably 3259) should work OK.

First off, when you start tgFX, before you select connect, are you selecting the Comm port?

When starting tgFX, after selecting connect, wait until you see tinyG respond in the scroll window, lower left of display.

When you think you are connected, enter a $ and CR, or $$ and CR in the command line window, bottom left corner.
You should see the tinyG response scroll by.

In all likelihood, I think it’s probably a parameter that I mistyped and didn’t spot the error on my double checking.

For a while, I was in config mess myself. If interested, I built on some prior work over at Google Groups to improve the capture and management of configs.

https://groups.google.com/forum/?hl=en&fromgroups=#!topic/devtinyg/2tp6cSC943E

A challenge is that the parameter sets have been in some flux with the more recent releases of tinyG FW; the spreadsheet I built may now be out of date

Hmmm, better, I suppose, to not know what was wrong but to be “all is fine” than to not know what was wrong and to still be having issues.

Let’s hope for continued good luck..

Yes, tgFX uses JSON but will accept either on the tgFX command line.

I’m not exactly sure what you mean by this:

I’ve tried the latest tgFX stable and experimental for 412.01 firmware.

Better to use build number for a while yet, the terms stable and experimental are in frequent flux.

Can I assume you mean you have tgFX_windows – Stable – x86 x64 build 3259 – v0.97.zip loaded?

I have run it on a Win7_64 machine (it is actually a 32 bit application) with tinyG build 412.01. No issues like you are reporting.

From where did you get tinyG build 412.02?

tgFX might be complaining that it does not find 412.02 on any list of builds it knows about; that is a guess on my part