cmcgrath5035

I am not a dev, will guess “maybe”, depending on what exactly the ‘big easy drive’ needs, but would be a lot of reprogramming of tinyG internals, plus you would have to figure out how to feed your reprogrammed logic with a command string.
Due would seem a more straightforward path, to me anyway. There is good code build support for the G2/DUE combination.

Sorry, I missed the fact you were already XXYZA.

I have seen, somewhere, shield like boards and code to drive steppers from a RazPi.
If you are a Chilipeppr user and already have a Pi, that might work for you.

There has not been traffic here on this topic that I recall.

Your topic is clearly identifiable, perhaps will attract some attention.

I compared your parameters to a set I last used form my SH2 belt machine.
I have $fb=83.09, whereas you have 87.01. I don’t think that is an issue.

The other differences are $_pl, $_tr and the jerk values, all different due to different mechanical configs. Again, I think $yjm=50 might be on the low side for you, but believe you have already experimented with $yjm=100 or perhaps 200.

I have no hands on experience with your mechanical setup, but sort of understand the adjustments you are speaking of.

I might suggest mechanically disconnecting the Y axis motor from the ballscrew, then observing the motor when you issue the move command. Based on your video, the secondary ‘jump’ at end of travel should be visible if it is tinyG related.
Perhaps you can just back out the ballscrew side setscrew(s) on the coupler and run the move?

Please post your entire parameter set to a cloud drive with URL – answers a lot of potential questions ($fb, $_pl, etc).

Video is odd, for sure.
Any chance there is some residual binding in the drive train – if $mt=1, perhaps the additional jump is due to motor release after 1 second

If you energise the Y motor, can you manually push the gantry, overcoming the holding torque?

Same result if you make the y move at half the velocity? Twice?

The body of knowledge for FW 338.02 is sort of lost now – hard to comment on parameters. CoolTerm was the defacto ‘simple’ Gcode sender back in that time frame. RTS/CTS flow control generally worked better than Xon/Xoff, but both seemed to have driver dependencies and platform dependencies – not enough CPU to respond in a timely manner.
Most users seem to have different priorities than yours – they want to run long, intricate jobs and get maximum performance from tinyG.

Then, of course, there have been a whole lot of bug fixes and incremental feature enhancements to tinyG. The wiki has expanded a lot in the areas of status monitoring, queue management, etc, but frankly I am not sure there is a good way to tell you what might apply to 338.02.

Since you are a Java guy, you might want to look at Goko.com (google goko cnc), it is a new Java based project, again third party. Perhaps there is some knowledge there that will help you. I have no knowledge or experience, it showed up in a recent Forum post.

I’d highly recommend you shift your fw base up to build 440.20.
Virtually all the effort on fixes, and working knowledge of the community, is focussed on that build for now, and will be moving on toward further integration with G2 functionality.

kkannan:
I am surprised CP works at all with you V6 – CP aggressively uses enhancements to the communications protocols in tinyG.
What FW rev you have loaded?
I saw you query to Riley w.r.t. boot loader.

I have a very up-to date ($fb=440.20) tinyGV7 that works fine.

You are actually the first V6 user I have seen.

I guess I am also a little surprised that CP runs on Vista – what browser you running?

I have a V9k version, thru hole pins.

If you want external drivers, why not run G2 on a DUE?

I have never heard of Goko, so have no idea what it is attempting to do.
The errors are likely tinyG applying Gcode arc specification rules that the Gcode generator has ignored.

Is your Gcode in inch mode or mm mode.
If inch, regenerate in mm.
Sometimes the small errors in converting inch back to mm is enough to trigger these errors.
TinyG does all it’s work in mm, converting from inch when it has to.
Running mm Gcode bypasses that conversion overhead.

Have you tried running the Gcode with CoolTerm or Chilipeppr?
Does it run OK there?
Neither of those Gcode streaming tools act on error messages returning from tinyG.