Chris S

I’m doing some pretty extensive logging, these commands commands preceed G01X197.00Y128.00Z0.00F5000:

$azb=2
$ej=1
G28.2 X0 Y0 Z0
M02

I’m using the TinyG more as an industrial motion controller than a CNC machine controller so I’m probably executing a lot of non-standard messaging. In trying to further debug this I looked at the computer serial input buffer I get a massive message dump from the TinyG when the G28.2 completes (the buffer swells to > 3,000 bytes) and I think the TinyG is losing it’s mind when that happens.

I think I know what’s happening with that message dump and this morning I’m going to make a change that should reduce or eliminate it. I’ll post back here with the results. I can email you the log file if you want but I don’t think I should post it here.

Thanks.

Regarding 1.00 = ‘1’, I understand. Thanks.

{“gc”:”G28.2X0Y0″} executes the homing sequence. I guess it would be helpful if I explained what I’m trying to accomplish and why…

I have some systems deployed, temporarily, in a high-ESD environment. While I’ve taken every precaution I can (treating the floor and furniture with anti-static spray works surprisingly well, instituted ESD safety rules like smocks and ground straps) it’s been proven inevitable that people are going to shock these machines. When that happens the TinyG resets and my GCode administrator keeps sending commands because it doesn’t detect any error. This often leads to crashes.

I’ve determined that when this reset event occurs the $hom bit is set to FALSE (0). What I’d like to do is be able to query this bit between commands to detect that an error has occurred.

Or something with the same result that tells me the thing has lost its mind.

Thanks.

PS – ideally I’d fix the underlying problem but right now I have no choice but to keep the machines where they are.

Once I slowed down and looked one more time I found the footer array definition in a table here:

https://github.com/synthetos/TinyG/wiki/JSON-Details

{[array_ID/version,status_code,RX_received,checksum]}

It’s all working very well now, 100% functional using this motor/controller/power supply:

Here’s a table of commanded and actual revolutions per minute measured with a mechanically coupled tachometer, seems like it tops out at 10,000 RPM:

Commanded Actual
1000 720
2000 1832
3000 3110
4000 4340
5000 5570
6000 6649
7000 7552
8000 8301
9000 8915
10000 9442
11000 10013
12000 10530

If it’s ever helpful to anyone here are the provisioning commands I’m sending at initialization:

G21 // Set the units to metric
$aAM=0 // Disable the A axis
$bAM=0 // Disable the B axis
$cAM=0 // Disable the C axis
$mt=10.00 // Set the motor idle timeout to 10 seconds
$1tr=31.4 // Set motor #1 (X axis) travel-per-revolution
$2tr=31.4 // Set motor #2 (Y axis) travel-per-revolution
$3tr=31.4 // Set motor #3 (Z axis) travel-per-revolution
$1pm=1 // Motor #1 (X axis) is always powered to hold its place
$2pm=1 // Motor #2 (Y axis) is always powered to hold its place
$3pm=1 // Motor #3 (Z axis) is always powered to hold its place
$3po=0 // Motor #3 (Z axis) polarity is NORMAL
$ST=1 // Set the limits switch type to NORMALLY CLOSED
$XSN=1 // Set the X axis minimum limit switch function to homing
$XSX=2 // Set the X axis maximum limit switch function to kill
$YSN=1 // Set the Y axis minimum limit switch function to homing
$YSX=2 // Set the Y axis maximum limit switch function to kill
$ZSN=1 // Set the Z axis minimum limit switch function to homing
$ZSX=2 // Set the Z axis maximum limit switch function to kill
$ASN=0 // Disable the A axis minimum limit switch
$ASX=0 // Disable the A axis maximum limit switch
$xTN=0 // Set the X axis travel minimum to 0 mm
$xTM=250 mm // Set the X axis travel maximum to 250 mm
$yTN=0 // Set the X axis travel minimum to 0 mm
$yTM=165 mm // Set the X axis travel maximum to 165 mm
$zTN=0 // Set the X axis travel minimum to 0 mm
$zTM=-60 mm // Set the X axis travel maximum to -60 mm
$xLV=80 // Set the X axis homing latch velocity to 10 mm/min
$yLV=80 // Set the Y axis homing latch velocity to 10 mm/min
$zLV=80 // Set the Z axis homing latch velocity to 10 mm/min
$xVM=1200 // Set the X axis velocity maximum to 1200 mm/min
$yVM=1200 // Set the Y axis velocity maximum to 1200 mm/min
$zVM=800 // Set the Z axis velocity maximum to 1200 mm/min
$xZB=2 // Set the X axis homing zero back off to 2 mm
$yZB=2 // Set the Y axis homing zero back off to 2 mm
$zZB=2 // Set the Z axis homing zero back off to 2 mm
$p1frq=5000 // Set spindle PWM frequency to 5000 Hz
$p1csl=0 // Set the clockwise spindle LOW speed to 0 RPM
$p1csh=12000 // Set the clockwise spindle HIGH speed to 12000 RPM
$p1cpl=0 // Set the clockwise spindle LOW phase to 0
$p1cph=1 // Set the clockwise spindle HIGH phase to 1
$p1wsl=0 // Set the counter-clockwise spindle LOW speed to 0 RPM
$p1wsh=12000 // Set the counter-clockwise spindle HIGH speed to 12000 RPM
$p1wpl=0 // Set the counter-clockwise spindle LOW phase to 0
$p1wph=1 // Set the counter-clockwise spindle HIGH phase to 1
$p1pof=0 // Turn off spindle PWM for devices that are not off at 0 phase. This tells the TinyG to comppletely turn off PWM when M5 received.

Thank you for your assistance.

So far, so good. Auto homing works and I’m running X, Y, and Z without issue. The motors are getting a bit warm so I need to figure out why. My new spindle motor, controller, and power supply should be here today.

I’ll post here with results.

Thanks again for the assist.