Vex

Thanks for getting back to me!

A couple of things that look strange (not necessarily ‘bad’) in your parameters:
You have a Z axis homing switch, yet Zmin=0 and Zmax = 254mm (really?)
By convention, if you home Z axis with a homing cycle, Zhome=0.(=Zmax)
Zmin should in your case should be -254mm, Zmax=0.0
If you don’t home Z, should not be an issue but then suggest you set $zsx=0.

I currently don’t home my machine (no home/limit switches). It is on my to-do list, but would like to be able to machine the mounts. I’ll go ahead and set $zsx=0

Most folks run microstepping=4 on axis with very small $_tr

Wouldn’t that make the location inaccurate, IE if I’m running a 10 TPI screw and adjust it to 5 TPI with the same decrease in microstep?

Did you enter your speeds in In mode?

Yes

[zvm] z velocity maximum 635 mm/min
[zfr] z feedrate maximum 457 mm/min
would suggest that, unless 635 mm/min is special to you.
There have been issues with parameters entered in in mode,
mm mode highly recommended

I don’t quite follow? Are you suggesting I adjust feedrate and velocity to some other value?

This entry
[xjm] x jerk maximum 1905 mm/min^3 * 1 million
[xjh] x jerk homing 51 mm/min^3 * 1 million
and the Y axis entries look very unusual as well.

You appear to have a really fine thread ball screw machine(?)
$_tr=1.27mm.
Not clear what the correct jerk setting are for such a machine, but consider that on a typical SH2 belt machine ($_tr=40 mm), $zjm=5000 and $zjh=10000 to 20000.

If I remember correctly I based it around this, and fine tuned by ear. Are these values incorrect?

Unexplainable parameters like
[xsv] x search velocity 406 mm/min
frequently are the result of corrupted EEPROM (the parameter store).
If you can’t explain 406, as opposed to 400, or don’t remember explicitly setting it, I would suggest the following:

I don’t recall ever adjusting this value away from default–I may have, but it’s been awhile.

1. use your Gdrive file as a guide, write down what you think parameters should be, based on whatever setup guide you might be following.
I have never seen a guide that suggested [xsv] x search velocity 406 mm/min.

2. from the CP Serial console command line, enter $DEFA=1 command
This will reset tinyG parameters to factory defaults, likely nothing close to what is right for your machine.

3. Grab another $$ parameter dump and mark it up with the values you believe are correct for your machine.

4. Enter G21 in the serial console to ensure tinyG in mm mode.

5. Now enter parameters that need to be changed, one at a time, in the Serial Port console CLI. I suggest avoiding the configuretinyG widget, it seems to have contributed to corruption for some users, but not others.

When done, save your $$ list for future reference.

Now rerun your job, maybe in air first, to see if it behaves more sanely.

Sounds good. I’ll run through it next chance I have to carve out some time.

If not, reports results, and this time better explain what you mean by Z axis “stalling”. Just not moving, stopping but making a lot of noise, etc, etc.

Yeah, I must apologize for the lack of that descriptor. The Z-axis stepper stalled out (I heard the noise and saw that the coupler wasn’t moving). Tested the z-axis after that without issue.

BTW, if you do have a screw machine, double check the set screws on your motor couplings as well.

Yup. Tight as can be and not slipping.

Okay– results from the last test: I am hitting the maximum line count on CP when the trouble starts. This is leading me to believe that my issues are now a result of the CP interface.

The symptoms of it are around 12000 lines into the code the machine will suddenly stop updating/behaving similar to a dwell command on simple x- y- movements. After some time about 40~ commands will be sent to TinyG which responds and executes those 40 some odd commands–however CP does not fill the void thus the machine waits.I got tired of waiting for this process as it seems to occur for a good 10-20 minutes every time with no resolution or indication that it is a temporary effect.

Hello cmcgrath,

Your assumption is correct. I am putting a line at a time in the Serial Console (I’ve also done a line at a time in coolterm–but not during this run).

Guess number 2 was right on the money. It was generated in inches. I’ve gone ahead and regenerated it in to mm.

When testing the metric gcode; it appears that it works where the original code didn’t behave correctly; however it lost connectivity during one of the operations. When I re-connected and told it to restart from the beginning it did the face operation without issue, but when it moved on to the first pocket clearing it didn’t helix in at all. Retraction didn’t happen either. It was as though it missed the code that would tell it to retract to tool height (however it did retract to the correct height on the first run through prior to losing connection). Now that I write that out I’m about 99% sure that’s what happened. Could this be an issue with ChiliPeppr and the size of the gcode I’ve loaded? I’ve noticed that the response during jogging isn’t what it normally is.

Yes, 440.20 is loaded. Parameters I assume are sane–they worked with all the onboard tests.

Here are the requested files:
https://drive.google.com/folderview?id=0Bx6o1FtzhQNZZnNCaHpUaVZaRHc&usp=sharing