You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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!
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
cmd.log
job.log
setup.log
The text was updated successfully, but these errors were encountered: