cmcgrath5035

Thanks for the post, we get many folks trying to solve this, I’ll be sending them here.

As drawn in the above, the circuit is a low pass filter followed by a unity gain amplifier, Gain – R2/R1.
Your stated solution, R2=22.5K, would have gain of 2.23.
Likely adequate for most VFD inputs.
As you point out, R2=30K would yield a gain of 3 and higher output at PWM=1.0.

Good stuff

$xjm=1905 would not be a problem, and probably translates to a more ’round’ number in inches.
$xjh=51 is very low, but you don’t home the machine so this value never gets used.

Turn off all home/limit switches that you don’t want to be active.

To my knowledge, there is not a Synthetos ‘suggested’ parameter set for screw machines, so you are on you own to collaborate with others.
If you do find one, send me a link.

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.

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

Did you enter your speeds in In mode?
[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

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.

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:

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.

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.

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

My first suggestion would be to repeat what you tried to do in your video using the Serial Port COnsole Command Line, directly entering the commands, or try CoolTerm

Your results are certainly not typical of tinyG users, but your methods of movement (from video) use some rather recent enhancements of ChiliPeppr.

If you wish to pursue, A dump of your tinyG parameters would help, put in a Cloud folder with a URL.

Can I assume you have seen this diagram?

https://github.com/synthetos/g2/wiki/Arduino-DUE-Pinout-for-tinyG2

I haven’t played much with G2 in a while and unfortunately most of my files on the topic are on my other computer, where I am not.

I vaguely recall these being debug signals, useful for logic analyser input while tinyG2 was running.
Since GRBL does not run on DUE, I think any reference to GRBL is unlikely.

I would probaly assume gblxxx–> globalxxx, ??

I am not Synthetos, just a Forum lurker/moderator. I do see the requests to the Contact URL, I can’t recall if I saw yours or not. When did you send in your query?

Some background that might help:
The thread you referenced that started way back in 2014 had origin in a Lock Bit setting that was blocking flashing of the device, IIRC. Unless you have a very old tinyG, that is not likely your issue.

In late Dec 2015, a small batch of tinyGs were factory programmed incorrectly (again, fuse or lock bit programming) that made the tinyG overly protective of low VCC voltage, resulting in self destruct that corrupted both the tinyG FW and the bootloader FW. The recent references you post above, about how to use the MKII to reflash, are aimed at that firefight.

You obviously have a functioning bootloader, based on your terminal logs above.

What version of SPJS do you have loaded on your Pi2B?

OK, so you are a linux guy (me openSUSE), I wanted to know your Desktop OS so I could point you down the correct path for bypassing SPJS and using avrdude from the command line. You already figured that out.

I am a bit stumped
Your flash log looks OK, except of course for the verification error.

For the moment, I am fixated on your avrdude version 6.2-5.
Where did you get that from?

My openSUSE has avrdude 6.1 in the repositories. Works OK directly from desktop.
Chilipepper is actually using avrdude 6.0.1 in the SPJS implementation.
I vaguely recall downloading an avrdude version 6.2.something at one time, which did not work with tinyG. That could be your issue.

Here is a wild guess as to what may have happened when binary data got sent down as Gcode:
In addition to the user parameters you see with $$ command, there are other parameters in the EEPROM that are used by tinyG internals. Something in the command stream may have caused tinyG to corrupt EEPROM, then crash. The best way to fix that corruption is to relaod FW, which rebuilds EEPROM parameters as part of the install process.

I am actually somewhat surprised the bad command stream ever got sent – the ChiliPeppr Gcode widget and SPJS are very Gcode knowledgeable. Hard to predict how your binary file got interpreted.

See if you can find an avrdude 6.1 for your Ubuntu system and try that

Wow, it has been a long time since I ran the file.

Turns out it has no real setup code, such as a G21 to say it is mm code.

So if you were in G22, inch mode at the time, it took off for 6″ when it was authored for 6mm. Good thing it hit a limit – It would have headed for 1 inch deep next.
Sorry about that.
The code was actually developed to run on the original, rather small, ShapeoOko1.

It did not have an M03 to turn on the spindle either, sorry about that too.

I edited the file to add a G21 and Mo3 at front end, M05 at end.

Try your Gcode file first with SPJS 1.88

Redownload the ShapeOko file, run in air.

By the way, things always run better with tinyG in mm mode at the moment.
Consider regenerating you Guitar file in mm.

Sorry, buffer status (actually, the number of buffers left available for use).
It is a maximum of 32, if SPJS is doing it’s job keeping tinyG filled the number of available buffers will be low.
If SPJS stops streaming commands, the available buffers may spike up, a pause (stutter) occurs then streaming of data continues.