cmcgrath5035

Fixxer
What PC OS are you running Coolterm On (Win 8, Win10, MACOS, Linux)?
Coolterm might run somewhat differently on each.

From you description so far, this sounds like a Coolterm issue.
Coolterm is a generic terminal emulation program for sending and displaying characters over serial links. As such, it is a good interface for getting started with the tinyG serial interface.
As SteveD points out, most users find CAM interfaces with CNC centric GUIs, such as Chilipeppr or CNC.js useful when running big jobs.

Are you able to interact with your tinyG from the Coolterm Command line?
Wiki references would be
https://github.com/synthetos/TinyG/wiki/Connecting-TinyG
and
https://github.com/synthetos/TinyG/wiki/Test-Drive-TinyG

A couple years back (before Chilipeppr, CNC.js and others), CTS was suggested to be more reliable by the Synthetos devs, but both CTS and Xon/Xoff remained supported by the tinyG FW.
That “While back” would be before Win10 as well.
And issues that were reported were with file transfer, i.e. sending longish jobs, not individual commands from the CLI.

It is possible that some glitch has appeared with the CoolTerm-Win10 (serial protocols concatenated with FTDI support)-tinyG_FW chain. Most performance users have moved on to buffer based flow control (ala Chilipeppr), so it is almost impossible to know how well certain segments of the connection space are getting tested.

Short answer – move on, but keep a eye out that parameter changes you need are remaining persistent.

This remains an interesting thread, but difficult to comment on without hands on experience.
Since you are tweaking the current drive to your A stepper to achieve the desired effect, I would say for sure that temperature will have some effect on the results. Can better temperature control make for more predictable results? Maybe, maybe not.
Your existing cooling setup sounds like one that is usually adequate in a digital world. By tweaking current, you are really entering a Analog world where minute variations of temperature, voltage, electrical noise, even sunspot activity could affect the repeatability.

Here is a thought experiment, which you may be able translate into a real experiment with conditions appropriate to your setup.

Put a color dot on the pump drive mechanism so you can watch physical rotations.

Create a Gcode Command that moves your extruder 20mm in a straight line while making one rotation of the extruder driver (the A axis)

Send that same command three times, manually from CoolTerm, with an arbitrary pause between.

You will have a 60mm line of extruded material.

Now move the extruder so that it can make a parallel extruded line, and send a Gcode command that will move 60mm with three rotations of the extruder.

In both cases, did the pump rotate three full revolutions?

Compare results to understand the effect of segmenting the process.

Keep in mind that tinyG, specifically the planner, would look ahead in a stream of three discrete move commands and implement what would look like a single move, not stopping/starting the extruder.

I think you understand what I am suggesting.

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

I would say that all settable parameters in the $$ report are (supposed to be) persistent, the fact is one, perhaps 2 cannot be changed (like Serial Numb)and are really read only. For sure motor and axis parameters are changeable and persistent.

A new firmware download will reinstall the default parameters.

Run a quick test
$1tr=new number
Manual (push the reset button) reset; $1tr still = new number?
if so, Power cycle tinyG; $1tr return to default or remain new number?

A typical value of $xjd is 0.01mm for legacy ShapeOko machines, that translates to $xjd = 0.01/25.4 = 0.0004in (approx). Your values are much larger (therefor faster), but not necessarily a problem.

Think of it this way – you want your machine to mill a straight line in the X direction for a bit, then make a 90 degree turn and mill straight in Y direction. To manage the required deceleration of the mass of your spindle in the X direction, TinyG will begin slowing the X Velocity before the spindle reached the 90 degree turn because the spindle cannot be instantaneously stopped and restarted in a different direction.
A larger $xjd (or $yjd) says “it’s OK to start accelerating Y when the spindle gets close to the junction”, thus causing your 90 degree turn to become an arc. A larger $xjd value says that you accept more imprecision in these corners in order to keep you machine in manageable motion, thus reducing the overall time for your job to run.
That is what motion control is all about.

I’ll suspect your Z zero creep is a result of your $_pm=3 setting, you should try $_pm=2, in-cycle. In-cycle says that motor is energized when any axis is moving. You need to keep Z energized to provide holding torque for the spindle as you move X and Y around, so $4pm=2. I’ll guess that X,Y motion is pushing the spindle up (away from) the work surface due to lack of holding torque.
$_pm=3 is really only useful when you have a machine that has no holding torque demands on axes that are not moving.

As for $4tr=1.27in when other identical leadscrews are =0.3, that is just strange, implies that Z motor driver is sending step pulses approx 4 times as often as it should be. Could be wiring (but doubtful), could be corrupted internal parameter, could be a driver defect or short on the board. For example, You have $4mi=8, but if the driver device is stuck at mi=2, tinyG fw would be calling for 4 times as many steps as would be required. Try setting $4mi=2 and see what value of $4tr is required.

Make the $_pm change first to see if that corrects behavior

However, our system currently isn’t set up to do this and I would like to know if there is anything wrong with the method we are currently using?

I believe that G38.2 would move more quickly, but that is a guess and speed may not matter that much.
Reading your outline a pseudo code, you are doing the same job – if it works for you and you like it,it works.

Also, is {mots:null} the best way to determine that motion has stopped? I use that in other cases as well. For instance we have a brake on our A-axis and I want to be certain that motion has stopped before applying the brake after a rotation.

I think so, but a bit hard to say for sure without understanding your overall motion programming strategy in detail.

What you really want, I suspect, is to know that the machine is not currently moving and no motion is planned in the near future (i.e. until I tell you to move some more.)
Perhaps that translates to “(not moving) AND (command buffers empty)”?
Perhaps your coding strategy makes that implicit.

This is the first instance of this particular unit I have seen. It appears to be very robust and from a quick look well documented. You may get lucky and attract some other users who have already implemented this interface.

I’ll comment up front that achieving success will be difficult to achieve without some relatively complex terminology and interface implementation.

tinyG’s spindle control firmware and electronics include On/OFF logic signals, a direction signal (CW or CCW) and a pulse width modulated logic stream on the PWM lead.

Most VFD’s are controlled by analog inputs, a DC voltage input in the range between 0V and 10V sets the output RPM of the spindle. tinyG does not output such an analog voltage, but it is possible to convert the PWM output to an analog voltage appropriate for controlling the VFD with external circuits.

A quick read of https://www.driveswarehouse.com/Assets/Document/WJ200R.pdf, page 43 specifically, implies that PWM control of this particular VFD unit may be possible.
You need to do more research on that topic, PWM control would be more straightforward to implement, but not trivial.

tinyG logic outputs are “3V logic”, the VFD Pulse inputs are specified at 5 to 24V, so at a minimum you will need a logic level translator between the tinyG PWM stream and the WJ200-022SF Pulse train input

Following so far?
Read thru the WJ200-022SF documentation and understand how the Pulse Trail Input operation actually works. That means of control would be the most straightforward to implement.