alden

You might look into the Spindle PWM output. This is settable in SW (use the JSON commands). It would need to be gated for use in a laser cutter. The enable might work as you suggest, or you might need to hack the code a bit more.

There is a lot of info on the wiki about setting up environments, programming, etc. The code is also pretty heavily documented if you get in that far.

Maybe what you are seeing is normal operation. The tool is supposed to slow down going into a sharp corner. I suggest taking a closer look at the Gcode to see what it thinks it’s supposed to be doing.

Let me take a look at this this week. I am traveling now but will be home mid-week to try it.

If you told me the machining (engraving) was not working it would be an issue, but the lights are truly advisory. You shouldn’t care too much about what’s happening. Here’s my take on what’s going on.

There is no simple “indicator light” function on the stepper drivers, so the LED is just wired across one of the motor phases (A phase). The indexer inside the stepper chip decides exactly where the phase outputs are. There are multiple states the phases can be in and still get correct stepping. The indexer can be set to a known starting point by a HOME signal to the chip, but we don’t do this as it’s not necessary for proper operation and would take a valuable IO line to do it. So what you are seeing (I suspect) are the indexers on the 2 Y axis chips being out of sync with each other. This does not affect the stepping, but does affect the LEDs.

Let me see if I can answer your questions. TinyG behaves as “exact path mode” (G61.1) G64 is mapped to G61.1. If a program emits a G64 it should accept it, but it’s treated as an exact path just like G61.1. More of an explanation is provided here: https://github.com/synthetos/TinyG/wiki/TinyG-Gcode-Support#g61-g611-g64-path-control-modes.

You don’t have to control the milling speed, beyond setting the feedrate limits for the machine and doing normal tuning. The joins will be decelerated as needed to keep the tool within limits. The position (path) will not be interpolated – the job should run exactly as the Gcode produced by the CAD/CAM.

It’s not exact stop mode because the tool does not stop between line. The lines between points will be “lines”, not curves, because no curve interpolation is performed by the controller – the Gcode file is executed exactly as it’s provided.

Your question on achievable speed depends on a lot of factors and I’m afraid I can’t answer that other than 80 IPM (~2000mm/min) is quite achievable with TinyG.

I don’t have a good answer for what the best way to test Gcode for excess excursion with the current firmware. This is one reason we are adding soft limits. In the mean time you can use a Gcode viewer to draw the Gcode before sending it to the machine and seeing if it exceeds maximums.

We have not implemented the S curve with linear segment (limited max acceleration, aka “7 segment moves” versus “5 segment moves”) for a variety of reasons. First, it appears that the additional math is beyond the ability of the Xmega to handle; at least handle and maintain the current top speeds that it can achieve. It’s pushing it to handle the simpler case. Second, given the amount of time spent just getting simple S curves running I’d rather not dive into the more complex cases for the incremental performance improvement afforded by going to 7 segment moves. What people have been doing is tuning the machine to the jerk with the maximum acceleration implicit in this tuning. Granted there is a bit more performance that can be eeked out of the machine if linear segments are implemented, but it’s a fairly complex bit of code to bite off for what should be a marginal improvement in performance.

If you are interested in diving an and contributing please let us know.

G64 in tinyg does not round corners like it does on LinuxCNC (it’s not NURBs). What it does is reduce the velocity through corners to keep the machine within jerk and centripetal acceleration tolerance. The exact path is followed. In most cases this makes corners slow down, but not stop.

G64 is most useful when hand coding Gcode. Most CAD/CAM packages generate lots of tiny little lines and some can do the corner rounding for you, compensating for the lack of true G64 on the tinyg.

Hope this helps

You actually have to set the HV – there is no way for the SW to detect this. On the v7 type $hv=7 and it should be OK. It is important that the firmware know the correct version as the IO wiring is a bit different between the versions.