cmcgrath5035

Well, you call yourself Rural, so sheep shear is appropriate.
A bit tough on the ‘victims’ this time of year, but I’m sure you have a plan.

What tinyG FW are you currently running?
What version of tgFX are you running?
Running from Linux or Windows7?
A problem you will face sooner or later is that the last release of tgFX was in the 435.10 firmware time period, I believe. Improvements contiue in the buffer and queue management FW, tgFX will fall further and further behind.

FYI, back in the days I ran tgFX and tinyG, each time I ran a new job or even reran a loaded job, I started by resetting tinyG and tgFX and reloading from scratch. It eliminated some issue like yours.

Here is what I understand you to have: A ShapeoOko, with a tinyGv8 (or v7) controller and mechanical endstop/limit switch. You plan on using the switch in NC mode.
Each switch port on the tinyG has a resistor from the port to +3.3V and a small capacitor to ground on the printed wiring board, so when nothing is connected the port is held high by the resistor. When you connect a Normally Closed (NC) switch, one switch terminal to ground (at tinyG) and one switch terminal to the tinyG port, the port will be at ground potential (logic 0) in the switch’s normal state and the port will go logic high (3.3V) when the switch is mechanically operated. No connection to the 3.3V power supply leads is required.
To connect the switch, use a shielded two wire cable(2 wires plus shield), 24 gauge conductors are more than adequate, finer gauge OK but can be difficult to reliably connect (up to you). The drain wire for the shield should be grounded at the tinyG end only, the shield should not be connected at the machine end.

Good luck with your build.

• This reply was modified 9 years, 10 months ago by cmcgrath5035.

It would be helpful(should this behavior continue)if you describe your setup a bit more.
You have mentioned Linux, Win7 and Chilipeppr.
What fw is running on tinyG?
We’ll assume you are using a current Chilippr by running with Force refresh Mode

http://chilipeppr.com/tinyg?forcerefresh=true#

What release of serial-poort-json-server?
Does spjs run on the Linux or Windows computers , or separately?
If separately, on what sort of computer?
What browsers do you use in Windows and Linux?

Hmmmm, a couple things.
First, if you are curious, you can decode the “{“r”:{},”f”:[1,0,19,78]}” to say the Gcode command sent was executed with status=0, == OK.
The “f” structure is discussed here:

https://github.com/synthetos/TinyG/wiki/TinyG-Status-Codes

Perhaps it would help if you posted a set of your parameters, rather than do Q&A one at a time. Posting this way is easier on my end:

https://www.synthetos.com/topics/forum-information-sharing-readme/

Please clarify your comment:

I can’t get any motor to spin at a constant speed through cool terminal

Do motors move at all? You used the term ‘constant’; a G1 X500 F200 command should cause the x motor to ramp up to F200 rotation speed then ramp down to zero speed after it computes that the Xaxis has moved 500mm.
I would call that movement, but not ‘constant speed’.
Or do you mean ‘I want the motor to start up and keep spinning until I stop it…?’

When you send the sample G Code file using CoolTerm, does anything happen?
Do you see green LEDs flicker near the motor connectors?
Do you see streaming position updates coming back via Coolterm as the G code runs?

Do you have your Axes disable by chance?
$xam, $yam and $Zam should all be = 1 [standard]

Have you reviewed

https://github.com/synthetos/TinyG/wiki/Connecting-TinyG#setting-motor-current

I sort of think so, based on your questions, but just checking.
Having just re-read that, I see it as assuming that the motors are connected to your machine. If you run the exercise of trimming current with the motors free spinning, you will want to rerun the procedure once the motors are under machine load.
But, free spinning experiments is a good way to get some experience with minimal downside (like driving an axis into a side rail with an incorrect command)

FYI, there was a quick bug fix and you should install fw 440.14 when you can get to it, but it will not resolve your Y issue. And yes, you will have to reenter your parameters again.

I am not a G28.2 (or homing/limit switch) user, but there have been several rounds of fixes to G28.2 since the 435.xx days.

Motors fail from time to time, diagnosis is difficult for soft failure.
Assuming no mechanical cause (gantry binding, wheels too tight, etc.) it sounds like inadequate torque to get the motor spun up,
Are you sure wiring/connections are good?
You could try frogging (swapping) the tinyG drivers and motors, to see if the issue follows the driver.
What I mean is:
If now “Y1 is M2 and Y2 is M3”, change to “Y1 is M3 and Y2 is M2”. You will have to reverse the $2po and $3po polarity settings if you want the gantry to move the same direction as “+”.
If the same motor, on the new driver, still has an issue, a motor replacement is likely in order. Even if you could diagnose internal issue,I doubt you could fix it. It could be just a bad bearing in the motor, fixable once you find the right one.

Hmmm, I look about a bit.
Now that you mention it, I have not been receiving emails from the system either.
IIRC, this tool only emails when new items post, not responses.
Still , better than complete silence.