Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

G1-G0-G1 Collinear moves cause skip in S curve planner #262

Open
John-from-AALLC opened this issue Mar 4, 2021 · 2 comments
Open

G1-G0-G1 Collinear moves cause skip in S curve planner #262

John-from-AALLC opened this issue Mar 4, 2021 · 2 comments

Comments

@John-from-AALLC
Copy link

Hello All,

At the recommendation of the forum moderator, I am posting this issue here. Any guidance would be appreciated.

I am using a tinyG v8 in an internally developed 3D printer application. It is set up to drive NEMA23s in X and Y via T8-8 leadscrews, and a pair of NEMA17s in the Z via T6-1 leadscrews. It is supplied with 350w 24vdc power and driven via my own software that feeds gcode to the tinyG via a queue keeping the buffer about 2/3rds full (about 9 out of 32 buffers free).

I've run into a circumstance that consistently generates position errors. To understand the circumstance, please first see the attached image titled "Overview". This is the shape of the layer being printed. Next see the "ZoomedIn" image which shows greater detail in the area of interest. Finally, take a look at the "ZoomedIn with descriptors" image which removes the perimeter vectors for clarity and now shows the length and direction of all vectors (moves) including G0 moves in yellow.

The problem occurs when the system draws the 7.028mm long G1 move. It seems to skip S curve planning and just apply full feed rate to this move. The result is the BOTH the X and Y motors "spin out" (i.e. make noise but do not move) as if they had been given some ridiculously high jerk and/or velocity.

Also attached are the gcode commands fed to tinyG (cmd.log) and its corresponding responses (job.log) as well as the tinyG responses to its setup (setup.log). I've annotated the cmd.log and job.log files to more easily see the moves that correspond to the vectors shown in the ZoomedIn_with_descriptors image where the issue occurs.

As a patch, I modified my code to recognize this circumstance (G1-G0-G1 colinear combination) and add an "elbow" to the G0 (i.e. make it perpendicular for a short distance, then back to the start of the next G1). That fixes the problem... but not very elegantly.

further tinyG details:
firmware build: 440.20
firmware version: 0.970
hardware platform: 1
hardware version: 8

ZoomedIn

Overview

ZoomedIn with descriptors

cmd.log
job.log
setup.log

@ril3y
Copy link
Member

ril3y commented Mar 4, 2021

hey email us @ synthetos [at] gmail.com and we can get in touch there.

@John-from-AALLC
Copy link
Author

Thanks for the quick reply ril3y. I sent a note to "synthetos @ gmail.com" (sans spaces) a couple days ago. You can find my contact info there. I look forward to hearing from you. Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants