[osmanager]

I will try and provide as much info as possible.
Machine is a home built budget machine using recycled printer stepper motors, steel and bearings.
Electronics are Arduino UNO, CNC Shield v3 and DRV8825 Drivers. 36V PSU, Limit Switchs with Octopler buffer for EMI.
CAM produced using Fusion360
CNC Control using Universal Gcode Sender Platform (UGS)

ISSUE - simple polygon with triangle tab fails while same polygon with square tabs passes.

When using triangle tabs it seems to not move the X Axis correctly for 2 of the tabs - thus leaving the X Axis about 6mm away from its home position.
Seems to be a problem with these line -
X61.76 Y13.37 Z-1 F300
X18.958 Y18.66 Z-1 F300

WHY! - CAM files gcode looks fine plus visualise fine. Plus I have tried changing the machine max feed rates from 750mm/min to 500 and 400 and I also tried this within the files but no change.

I also tried a text engraving file and it failed in a similar way.

Any help gratefully received.

See attached picture for output.

See Gcode via these links - https://drive.google.com/open?id=1Zt...-2bg8x9THhUL8M (Triangle Tabs)
https://drive.google.com/open?id=1-X...3YbZTsEuen2Vs- (Square Tabs)

See video via these links - https://drive.google.com/open?id=1Yg...c_G-OF0KW-GzwQ (Triangle tabs)
https://drive.google.com/open?id=15Q...Dn-sji0ftb5s3w (square tabs)

[osmanager]

I also tried changing the number of micro steps but this did not make any difference to the cuts.

[skrubol]

Weird, looks to me like the direction line for X got reversed at those spots. Possibly a bug in the Arduino firmware?

[osmanager]

Hi - UPDATE - Work in progress
Been chating to guy called Gary who ran the job on his machine and it was fine - so not the GCode

I can repeat the issue in exactly the same place each time so not a mechanical issue.

So he suggested this -
'Another thought - I noticed on my test that when it was doing the tabs that the machine/steppers made a lower pitched "noise" than usual. It may have been worse on the last two tabs, where you are having the problem. This made me think of this known issue with GRBL:

https://github.com/gnea/grbl/wiki/Kn...low-step-rates



I'm not clear on whether the issue is on a per axis basis, or overall. If per axis, there might be the possibility of one of the three axes going below that limit in the XYZ move that seems to be having the problem.


It would be an interesting diagnostic test to rotate your tab design say 20 degrees and see what happens.'

This could be the case I plan to look into this tomorrow, If this does not point me in the right direction I will reload GRBL onto the Arduino as skrubol sort of suggests (mind you it is a clone so might not be best for fixing issues on, I have a another I can use if I switch with something else)

Thanks for help will update you all later

[skrubol]

That low step rate article shouldn't apply here, all 3 axes are moving between 1 and 2 units (mm I assume?) in that line of code, and it's set to 300 units/min. I assume your steps per unit is >> 1, so no axis should be anywhere near as slow as 30 steps/min.

[osmanager]

Well I tried some things today but it was freezing in the shed so I did not stay long.

1. I updated the Gcode file and increased the feed rate from F300 to F500 and it made not difference but I did not think it would, lol
2. I downloaded this a ShapeOko calibration file from here (https://forum.shapeoko.com/viewtopic.php?f=7&t=742) and it ran fine up to the point that I realised it would clash with one of my clamps so I killed the job.
3. I copied three of the lines of Gcode and ran them in the Console individually - this produced a Zig Zag pattern but I need more time to properly analyse the results
X24.217 Y14.84 Z0
X20.981 Y17.191
X18.958 Y18.66 Z-1 F300
4. Currently loading GRBL onto my spare Arduino

Quick questions my current Arduino is a clone and looking at the device manager on my windows 10 machine it identified the port as a CH340 - could this be the issue - https://github.com/gnea/grbl/wiki/Known-Issues#usb-to-serial-transmission-errors or would this just produce random errors?
Also in the properties of the USB driver it has a tab with port settings - but the speed is set to default value of 9600 but UGS uses 115000 does UGS override the default values?

[skrubol]

I wouldn't expect this to be a comms issue, as you're running in absolute coordinates (if it was relative coordinates a - move would make sense.) Also, your home (0,0,0) location changes, does it not? To me this indicates it's in issue with the output of the Arduino (step/dir,) not the input (g-code).
USB emulated com ports tend not to care what the baud rate is set at. There's no actual RS232 hardware, so it can sync internally. I'm not sure which speed wins, or if both are disregarded and data is sent at some faster rate.

[awerby]

If single moves work fine but combined moves fail, I'd suspect that your machine doesn't have enough power to run two motors at once. The fact that you're running all this on an Arduino doesn't make me rule that out. How much current do your motors draw individually? How much does your controller put out, totally?

[osmanager]

If single moves work fine but combined moves fail, I'd suspect that your machine doesn't have enough power to run two motors at once. The fact that you're running all this on an Arduino doesn't make me rule that out. How much current do your motors draw individually? How much does your controller put out, totally?

This occurred to me but why would the other 2 of the 5 triangle which use 3 axis movement not be and issue unless its the length of the movement as well.

I have a 36v 10Amp PSU and the steppers which came from an old printer are rated at 24v and 1.5amp, 2.5amp and 3.5amp which should be fine. The controller is Arduino and runs from the power from the USB.

Will be trying another Arduino tomorrow or Monday (unfortunately it is one with a CH340 chip)

[skrubol]

One pattern I just noticed is that the reversed moves are both X - and Z - (and the only moves that are that way that I can see.) If you mirror this before running through CAM does it change the behavior?