cmcgrath5035

You can, should work OK with NEMA 17s.
You will have to manage reversal of rotation of one of the Motors with wiring. See

https://github.com/synthetos/TinyG/wiki/Connecting-TinyG

I am a bit confused – I am not familiar with 360 but many tinyG users use it successfully. Are you sure you are using the correct backend?

You may also be confusing limits and homing. By design, a Z axis homing cycle moves up (positive) until the switch activates (can be set for homing or homing and limit) and that position is set to Z=0. You are correct that moves into material are in – direction

Some users jog down to the material surface and set Z=0, many use touch plates or in the case of pwb milling, there is a probe cycle that will find the top layer of the pcb material.

I’d dig more into your 360 configuration.
Hopefully someone with 360 expertise will stop by here.

What CAM solution do you use to send and manage your Gcode?

Nice looking machine – home brew or kit of some sort?

I am assuming that the ” a big fan for cooling” was directed at tinyG?
That is always a good idea.

If your issue is thermal shutdown, increasing drive current will likely make matters worse.

Are you running with a 24V supply for Vmot and tinyG?
tinyG is rated at 2.5A max per stepper, but at those currents exceptional cooling is required.

Do the motors get real warm(hot) when running?

Any chance the screw mechanisms are too tight/binding?
That is a relative question and I am not sure of a good way to evaluate it with a screw machine. On a belt machine one can simply slip the belts off the pulley and move things around by hand.

Changing microsteps might help incrementally, but yes, you would loose some ‘resolution’.

At some point it might be helpful to look at your parameter setup, a $$ command listing. Run $$, copy the results to a text file and put it on a cloud drive(dropbox, etc.) and provide a URL.

A possible solution will be to use external stepper drivers, providing additional current capability and improved thermal management.

How long have you had your tinyG?
Do you use it frequently?

You could be experiencing this issue

https://github.com/synthetos/TinyG/wiki/SpDir-Continues-To-Flash-Error

if you tinyG had been sitting on the shelf for a while.
Those with suspect units usually hit the flashing SpnDir fairly quickly (one or two runs).

Are you sure the boot up response you are seeing is from tinyG, not SPJS?

With earlier versions of Windows it was reported that some folks needed to track down an FTDI driver for windows. (FTDI is the USB to serial device use on tinyG)
I run Win10 (in a virtual Machine) and it ‘just works’ without additional drivers.

In case you want to try it anyway, here is a link:

http://www.ftdichip.com/Support/Documents/InstallGuides/AN_396%20FTDI%20Drivers%20Installation%20Guide%20for%20Windows%2010.pdf

When you load SPJS (version =?), SPJS actually interfaces to tinyG from the Win10 environment. I have run SPJS (ver 1.86) on Win10 successfully with no additional drivers.

Try this – shutdown SPJS,then reboot your windows machine.
Plug in tinyG to USB port.
You should see a Com port enumerated for the new FTDI device (that is what Win sees).

Of course it depends on what you believe the “usual problems” are.

UGS is what I would call and ‘enhanced basic’ Gcode file sender.

Chilipepper is, on the other hand, a bleeding edge evolving CAM solution.

The web tool is sort of limited, which is why I suggest URL only.

I’ll pass along the “snowflake corner.gcode” to see if it helps in resolving.

Do try mm mode Gcode, it frequently resolves the issue

• This reply was modified 7 years, 11 months ago by cmcgrath5035.

I imported your Gcode to Chilipeppr 3Dviewer, CAMotics (was OpenSCAM) and the CAM backend of QuadCAM, my 2D CAD tool and all look similar and , I’ll assume, correct per your comments.

It is not exactly clear what “snowflake corner.gcode” does – I am assuming you created this as a subset of the larger file for quick testing?
Does this file actually fail when you run it, or to be clear – can this file be used as a test case?

My suspicion is that the failure is caused by a somewhat known but elusive bug in tinyG FW related to ARC (G2 and G3) processing. It has been elusive for the Devs to fully squash. Based on your pictures, it is apparent that the failure is dependent on how the repeated corner pattern is rotated.

Please confirm that “snowflake corner.gcode” when run by itself actually displays the failure.

Possible work arounds while the bug is being worked:
1. Generate Gcode without arcs, if that is an option (no G2 or G3 commands). It will be a big file.
2. You could play with the design by rotating it some random angle around the center of the snowflake and regenerate the Gcode, possibly finding a sweet spot where the computations don’t fail. Perhaps try that with the shorter file first?
3. I just noted that you generated this in inch mode, G20. Try regenerating the design in mm mode. TinyG does all it’s work in mm, making conversions from inch as needed on the fly. The loss of precision in making those conversions sometimes contributes to these errors.

If an option, generate your Gcode with line numbers – makes for easier reading and referencing.

Your use of the Dropbox folder is ideal and easy, skip pasting the long file into this forum interface – copy and paste from here is difficult and makes navigating multiple messages difficult.

• This reply was modified 7 years, 11 months ago by cmcgrath5035.