G3 Does not cut circle right (misses an arc) or doesnt cut at all

[rickcaddell]

Attached are two files.

The one called Holes has two holes, one cuts correctly, the other cuts 3/4 of the circle ok, but the third arc is cut as a straight line not an arc.

The other file is one hole that does not cut any arc at all.

Both these programs run on another machine (not a TinyG controller).

Holes.txt Hole.txt

[ril3y]

Rick can we get the firmware version and hardware version you are running?

Thanks,

On Wed, Feb 24, 2016 at 3:21 PM, rickcaddell notifications@github.com wrote:

Attached are two files.

The one called Holes has two holes, one cuts correctly, the other cuts 3/4 of the circle ok, but the third arc is cut as a straight line not an arc.

The other file is one hole that does not cut any arc at all.

Both these programs run on another machine (not a TinyG controller).

Holes.txt https://github.com/synthetos/TinyG/files/145345/Holes.txt Hole.txt https://github.com/synthetos/TinyG/files/145346/Hole.txt

— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/158.

[rickcaddell]

I am using : {r:{fv:0.970,fb:442.04,hp:1,hv:8,id:"3X3566-KBR",msg:"SYSTEM READY"},f:[1,0,0,9343]}

[ril3y]

I pushed a new edge today. 446.19 Can you test this bug against that.

On Wed, Feb 24, 2016 at 7:58 PM, rickcaddell notifications@github.com wrote:

Reopened #158 https://github.com/synthetos/TinyG/issues/158.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/158#event-564681274.

[aldenhart]

I tested it on 446.19. It fails, so don't bother to test.

Rick - what CAM program did you use to generate the files?

[aldenhart]

The reason I ask about the CAM program is that the arcs specified in Holes.txt violate the arc endpoint radius tests. Just barely. In the v8 code base this cases the errors you are seeing. In the g2 code base this condition is trapped and the move is rejected. I'm not sure if it's a good idea to relax these limits. I'll keep looking at this for a solution.

[aldenhart]

I ported the (newer) g2 arc code into edge-0.97 and ran some tests on a slightly relaxed set of endpoint radius tests. Your files work with these changes. I will coordinate with Riley get this into the downloader.

I'm still interested in what CAM program was used to generate the Gcode files, and what settings you may have used.

[rickcaddell]

Thanks for the quick response.

I am using Cut2D by Vetric. I suspected boundry problems, which you confirmed. I would guess they have a rounding problem in their math, that rounds the wrong way, ie. floor instead of ceiling.

Cut2D really does not have any settings to speak of for arcs. I wish they had a cord length and starting point settings, but unfortunately they don't.

I do a lot of small move contouring and Cut2D spits out very small moves. Some of my programs have 50,000 blocks output by Cut2D. The only way to control this in Cut2D is to fiddle with the significant digits output by the postprocessor. I did this by editing the post processor, but this is kind of a kludge, and is more of a coarse control, so in my software I filter out small moves by accumulating the small moves until they reach a limit and then send that move to the machine so the machine runs more smoothly, but it would be nice if the CAM program could be set up for a minimum move or cord length.

It is a pretty good CAM program. Not very salty, but pretty basic. Not many options.

Thanks, Old man

[rickcaddell]

I tried to test 446.19, but after two hours of problems I have given up for awhile. I get the error message : 'Failed to get planner buffer - mp_get_write_buffer ' when I try to run a program, even a simple one like cuting a square. I also have trouble single stepping through programs.

I monitor the status report, queue report and queue report messages to keep track of where the program is executing. These report formats seemed to have changed. Is there a list available of things that have changed from version to version? This would help me find the problems.

[aldenhart]

I'm not sure what you are seeing. What are you using to drive the board - is it your own sender IIRC? As for the formats that appear to be different - are you referring to dropping the checksum from the {r} responses? Are there other differences? Also, please be sure the XON or RTS flow control is set correctly on both ends - that can also lead to problems.

There will be a changelog when edge is published to master, but edge is always experimental.

[rickcaddell]

I have been working with TinyG for over a year. I get my communications rock solid, then a version change often causes problems because something in the messaging has changed. I am not complaining because these changes are all improvements (like packet mode), but it is hard for to me to debug when I don't know what might have changed. I suppose I could only use the master version, but I usually want the new features and fixes like the one for G3, and I don't mind helping debug if I know what is going on.

Anyway, please considier what I am about to say seriously. I have developed a ton of software for Tinyg and I have had only minor problems concerning TinyG, except one, and I have spent weeks trying to come up with a good solution. And the one I came up with is very complicated, and every time the TinyG communications change I spend hours, sometimes days recovering.

The problem has to do with determining 1. when a GCode block has been put into the TinyG queue,

2. when TinyG starts executing a block, and 3. when TinyG has completed a block.

These are necessary to show the operator what blocks have been completed, what block is currently executing, and updating a drawing to show cutting progress.

I show the blocks in a grid control with a status column that shows if the block is in the queue, is currently executing or has been executed. Finding what blockes are queued has never been a problem, I get a respons message for evey block sent eg. {r:{gc:"N... But finding out when a block completes is difficult. I allow the operator to single step through a program one block at a time, or run continuously. The root problem is that the messages I get back from the TinyG are different depending on if stepping is done or not.

Because the status report is not sent for every block, the line numbers and status in the status report must be analyzed to figure out what block is executing. But I have managed to get this to work, but it is complicated, and any changes are a bear. The latest is that a G20 block by itself sends back a status of InMotion, when previous versions did not. I use InMotion and Stopped to determine when a block has finished, especially when stepping.

The queue report would be much easier, but it is not always correct. The documentation says something to the affect that it reports blocks going into the queue in one parameter and blocks out of the queue in another. This does not work for non motion command like a comment block or a block with no motion command, like M03.

Try the following program

N1 M03 N2 G0 X.01 N4 M05 N3 G0 X.0 N5 M03

If you send the blocks one at a time with a time delay between them, you get a different set of queue reports than if you run them all at once. In the time delay case the non-motion blocks do not appear.

My wish would be that the queue report show all blocks going into or out of the queue including non motion, blank or comment blocks, and no matter what the timing.

My dream queue report (qv=3?) that sends back three paramemter, the number of available queue slots, the line number of the last block queued and the line number of the last block that finished executing. If a block is blank or has no line number then "" would be sent instead of a line number. With this scheme it would be easy to see where the inyG is in the program.

I do not mean to sound like a crank, but I have been frustrated with this for over a year. I appreciate that this is a group effort and am eager to help.

If there is anything you could do, it would be greatly appreceated.

Old Man

[rickcaddell]

I was probably to verbose in the last comment, so here in a nutshell is what I think is a communication issue.

Run the following program : N1 G0 X.01 N2 M03 N3 M05 N4 G0 X.03

These are the resulting queue reports: {qr:31,qi:1,qo:0} {qr:30,qi:1,qo:0} {qr:29,qi:1,qo:0} {qr:28,qi:1,qo:0} {qr:29,qi:0,qo:1} {qr:31,qi:0,qo:2} {qr:32,qi:0,qo:1}

Looks good to me, 4 in 4 out

Run the following program : Same blocks in a different order. N1 M03 N2 G0 X.01 N3 G0 X.03 N4 M05

These are the resulting queue reports: {qr:31,qi:1,qo:0} {qr:30,qi:1,qo:0} {qr:29,qi:1,qo:0} {qr:30,qi:0,qo:1} {qr:31,qi:0,qo:1} {qr:32,qi:0,qo:1}

Same blocks in different order but only 3 in and 3 out

Run the following program : N1 M03 N2 M05 N3 G0 X.01 N4 G0 X.03

{qr:31,qi:1,qo:0} {qr:30,qi:1,qo:0} {qr:31,qi:0,qo:1} {qr:32,qi:0,qo:1}

Same blocks in different order but only 2 in and 2 out

I would like to use queue reports to keep my program in sync with the TinyG but because of the above I can't.

A better way would be to use line numbers. Where the second parameter is the last line number going into the queue and the third is the line number of the last line finised.

Running one command at a time might look like: N1 M03 {qr:31,li:1,lo:1} N2 M05 {qr:31,li:2,lo:2} N3 G0 X.01 {qr:31,li:3,lo:3} N4 G0 X.03 {qr:31,li:4,lo:4}

Streaming might look like" N1 M03 {qr:31,li:1,lo:0} N2 M05 {qr:31,li:2,lo:0} N3 G0 X.01 {qr:31,li:3,lo:0} N4 G0 X.03 {qr:31,li:4,lo:0} {qr:31,li:0,lo:1} {qr:31,li:0,lo:3} <--- Block 2 was not shown because it executed so fast, but that is OK {qr:31,li:0,lo:4}

This would be the ultimate queue report for me. It would solve my syncing problems.

[aldenhart]

Rick, I don't think you were verbose, and your points are well taken. I had not intended to create the changelog for edge until it was pushed to master, but I can see that a running log is needed for you and people in your situation. So if you will go here you will see the start of one. Many items are also linked to wiki pages that we have been attempting to generate as the features are developed https://github.com/synthetos/TinyG/tree/edge-0.97

I will take a closer look at your last post and on that comment later.

Thanks for your support on this project.

[rickcaddell]

Alden,

I am not sure where we stand on the G3 issue. I found why I was having communication issues,

it was a subtle difference in protocol, but I am over that now, but I am still very interested in getting

the queue report either explained, if I don't understand it, or fixed if it isn't working properly.

As for the G3 issue, I understand that you may not want to fudge your code because of a problem

with a CAM system, but have you decided to try it and am I supposed to test the G3 program?

When I do I often get an error message very quickly "Failed to get planner buffer - mp_get_write_buffer "

Once I did not get the error, but the circles did not work at all, worse than before.

Old Man

From: Alden Hart [mailto:notifications@github.com] Sent: Friday, February 26, 2016 8:55 AM To: synthetos/TinyG Cc: rickcaddell Subject: Re: [TinyG] G3 Does not cut circle right (misses an arc) or doesnt cut at all (#158)

Rick, I don't think you were verbose, and your points are well taken. I had not intended to create the changelog for edge until it was pushed to master, but I can see that a running log is needed for you and people in your situation. So if you will go here you will see the start of one. Many items are also linked to wiki pages that we have been attempting to generate as the features are developed https://github.com/synthetos/TinyG/tree/edge-0.97

I will take a closer look at your last post and on that comment later.

Thanks for your support on this project.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/158#issuecomment-189285859 .Image removed by sender.

[aldenhart]

Rick, I test with Coollterm using flow control to make sure there are no machine errors. The holes.txt file works perfectly for me after the g2 arc port (I am still testing all arc cases - which takes a long time).

So I suspect your problem is still in communications somewhere. First, it would be good to verify that you have the code itself working. I'd recommend getting version 1.4.3 of Coolterm and testing to make sure arcs are working for you. (The newer versions of Coolterm unfortunately have problems in sending very rapid files - it doesn't keep up. Something slowed down). Do you compile or do you need a hex file?

Once that's verified it's worth looking at the communications more closely. I don't know why you are getting the buffer error, but it may be due to communications not working correctly.

[rickcaddell]

TinyG Settings.txt

The reason I was having so much trouble getting my software to run on the edge was that the report format is stuck in filtered mode. My software is set up make a decision depending on the line number and status in the same report. That tripped me up for awhile, but I am over that hurdle. I started a new issue on this. I also had quite a bit of trouble with non motion codes like G55 and M03 causing a status of 'In Motion'. I started a new issue on that too.

I worked on these problems pretty much full time the last four days. This is typical when I try a new version of TinyG and it is always the same problem, deja vu all over again. Its trying to sync my software with the TinyG as far as what block is starting and what block is finishing. This is so important to me that I started anothe issue on that. I hope you do not get tired of me bringing up issues, but I really like TinyG and want to get everything working as soon as possible.

As far as the G3 problem, there was not much of a change.

I went over my communications code with a fine tooth comb. I haven't done anything to if for months, but it is always good to review things once in a while. I did find some things that could be improved, but I can almost guarantee it is working correctly. I paid special attention to Xon and Xoff. I can breakpoint in the code where I get an Xoff. With the breakpoint set, I rarely hit it. I ran a countouring program of mine that has 20,000 small moves and it only hit the breakpoint once or twice. I also ran the G3 program and that did not hit breakpoint either. So I think Xoff and Xon are definately working.

Having said that, I still wanted to take communications out of the picture. It is always good to know which half of the room the problem is in, so I slowed down the communications so that only one character is sent every 100 milliseconds, and only send out 15 blocks so there would be no question about overrunning the TinyG message queue.

It always blows on the 7th and 10th block. G03 X2.623 Y1.890 I0.000 J0.938

Obviously there is something different between my test system and your test system. The things that occured to me are :

1.The TinyG settings, I have included a file of these. Could Junction Acceleratio {ja:3937} or Junction_deveiation be the culprit? All axes are set to{xjd:0.0020}.

2.Is there a chance the firmware on the web is not what you are useing. If no. 1 is not the problem, could you download the firmware off the web so we definately know we are using the same firmware and try that?

Old Man