New queue report that reports every queue and/or dequeue of commands

[rickcaddell]

I am planning on turning over the source of an application to Synthoes that runs a milling machine using TinyG, however there are two issues that I really think need to be addressed before I can do that. I want to test these before turning over the source. Both issues have been submitted but nothing has become of it. One issue is G02 and G03 not working all the time. Please see issue #174.

I have never been able to reliably keep my software in sync with the TinyG as far as what blocks have been executed. What I need to know is when a block is put into the queue, and when a block is finished executing. The queue report is supposed to do this but it does not. Non movement commands like M05 are not reported as executed.

My application has a macro interpereter that is G code extended to have branching, looping and functions like trig functions, and system function like reading a file. Because of some of the things I want to do with the interpreter like breakpointing and stepping I need this feature.

I propose a new queue report type {qv:3}

The first parameter would be the same as {qv:2} (available slots) the second parameter would be the last line number going into the queue and the third would be the line number of the last completely executed bock by TinyG.

Running one command at a time (stepping or breakpointing) 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}

Note that block was not shown in the queue report, but that doesn't matter because I know the kast block is 3, so I can take care of 2. This would happen so quickly an operator would not notice anyway.

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

I can't say enough about how much trouble I have had trying to keep in sync with the TinyG. I am probobly doing things others don't do, like allow stepping through a program, which is one of the things that is hard to sync, but being able to step through a program to prove it out, or if there are problems, is invaluable.

Old Man

[chilipeppr]

ChiliPeppr keeps in sync by just asking for the Gcode line number to come back and I have found that to be spot on. You have to ask for that data in your SR request so it comes back. BTW, you can step thru your lines in CP.

[rickcaddell]

John,

Thanks for the reply. I am using the block numbers in the status report, but they are not always right.

The problem with the status report is that it is on a time basis, so some blocks can get skipped.

I tried using the queue report but it doesn't report non movement blocks either.

Try running this program and look at the messages going back and forth. Notice that the line number 2 never shows up in a status report.

That's because the machine was already at X0 so block 1 and 2 were executed before a status message went out. Because the

status report is on a time basis, line numbers can randomly be missed. That is why I have asked for a new queue report, so the

syncing can be more accurate.

N1 G0 X0

N2 M05

N3 G0 X0.05

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:3.039,posz:5.182,mpox:0.025,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:1,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.001,posy:3.039,posz:5.182,mpox:0.013,mpoy:77.191,mpoz:131.623,vel:0.91,stat:5,coor:1,unit:0}}

{"gc":"N3 G00 X0.05"}

{r:{gc:"N3G0X0.05",n:3},f:[1,0,22,4290]}

{sr:{line:1,posx:0.000,posy:3.039,posz:5.182,mpox:0.000,mpoy:77.191,mpoz:131.623,vel:0.00,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.002,posy:3.039,posz:5.182,mpox:0.060,mpoy:77.191,mpoz:131.623,vel:4.31,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.017,posy:3.039,posz:5.182,mpox:0.429,mpoy:77.191,mpoz:131.623,vel:11.84,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.036,posy:3.039,posz:5.182,mpox:0.914,mpoy:77.191,mpoz:131.623,vel:11.47,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.049,posy:3.039,posz:5.182,mpox:1.235,mpoy:77.191,mpoz:131.623,vel:3.45,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.050,posy:3.039,posz:5.182,mpox:1.270,mpoy:77.191,mpoz:131.623,vel:0.00,stat:3,coor:1,unit:0}}

If you run the following program, with a very short move sometimes line 2 shows up, sometimes not

N1 G0 X0

N2 M05

N3 G0 X0.001

Here is a case where it did.

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:1.000,posz:0.200,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.207,mpoy:77.191,mpoz:131.623,vel:0.90,stat:5,coor:2,unit:0}}

{"gc":"N3 G00 X0.001"}

{sr:{line:2,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.00,stat:3,coor:2,unit:0}}

{r:{gc:"N3G0X0.001",n:3},f:[1,0,23,8182]}

{sr:{line:3,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N4 M30"}

{r:{gc:"N4M30",n:4},f:[1,0,16,5082]}

{sr:{line:3,posx:0.001,posy:1.000,posz:0.200,mpox:6.221,mpoy:77.191,mpoz:131.623,vel:0.51,stat:5,coor:2,unit:0}}

{sr:{line:4,posx:0.245,posy:3.039,posz:5.182,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.00,stat:4,coor:1,unit:0}}

Here is a case where it didn't.

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:1.000,posz:0.200,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.208,mpoy:77.191,mpoz:131.623,vel:0.91,stat:5,coor:2,unit:0}}

{"gc":"N3 G00 X0.001"}

{r:{gc:"N3G0X0.001",n:3},f:[1,0,23,8182]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.00,stat:5,coor:2,unit:0}}

{"gc":"N4 M30"}

{r:{gc:"N4M30",n:4},f:[1,0,16,5082]}

{sr:{line:3,posx:0.001,posy:1.000,posz:0.200,mpox:6.214,mpoy:77.191,mpoz:131.623,vel:0.90,stat:5,coor:2,unit:0}}

{sr:{line:4,posx:0.245,posy:3.039,posz:5.182,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.00,stat:4,coor:1,unit:0}}

There are other problems with using the status report. I have written a macro interpreter that is an extension of G Code

to allow branching and functions. The block numbers going to the TinyG are not going to be contiguous, so this adds

another complication.

Old Man

From: John Lauer [mailto:notifications@github.com] Sent: Sunday, May 01, 2016 11:21 PM To: synthetos/TinyG Cc: rickcaddell; Author Subject: Re: [synthetos/TinyG] New feature request (#175)

ChiliPeppr keeps in sync by just asking for the Gcode line number to come back and I have found that to be spot on. You have to ask for that data in your SR request so it comes back. BTW, you can step thru your lines in CP.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/175#issuecomment-216098716 Image removed by sender.

[chilipeppr]

Hmm, yeah, perhaps I recall writing a method that if a line number went from something like 2 to 4 i still generated an event for line 3 to fill in the gaps. I don't totally remember though.

There's a command you can place in a comment now in your Gcode in the CP world called (chilipeppr_pause arg1 arg2 ...) and at that line the code will stop executing and when it hits that line gives a callback so folks can branch and do all sort of fancy things. The Pick and Place stuff is being done that way.

On Sun, May 1, 2016 at 10:11 PM, rickcaddell notifications@github.com wrote:

John,

Thanks for the reply. I am using the block numbers in the status report, but they are not always right.

The problem with the status report is that it is on a time basis, so some blocks can get skipped.

I tried using the queue report but it doesn't report non movement blocks either.

Try running this program and look at the messages going back and forth. Notice that the line number 2 never shows up in a status report.

That's because the machine was already at X0 so block 1 and 2 were executed before a status message went out. Because the

status report is on a time basis, line numbers can randomly be missed. That is why I have asked for a new queue report, so the

syncing can be more accurate.

N1 G0 X0

N2 M05

N3 G0 X0.05

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:3.039,posz:5.182,mpox:0.025,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:1,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.001,posy:3.039,posz:5.182,mpox:0.013,mpoy:77.191,mpoz:131.623,vel:0.91,stat:5,coor:1,unit:0}}

{"gc":"N3 G00 X0.05"}

{r:{gc:"N3G0X0.05",n:3},f:[1,0,22,4290]}

{sr:{line:1,posx:0.000,posy:3.039,posz:5.182,mpox:0.000,mpoy:77.191,mpoz:131.623,vel:0.00,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.002,posy:3.039,posz:5.182,mpox:0.060,mpoy:77.191,mpoz:131.623,vel:4.31,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.017,posy:3.039,posz:5.182,mpox:0.429,mpoy:77.191,mpoz:131.623,vel:11.84,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.036,posy:3.039,posz:5.182,mpox:0.914,mpoy:77.191,mpoz:131.623,vel:11.47,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.049,posy:3.039,posz:5.182,mpox:1.235,mpoy:77.191,mpoz:131.623,vel:3.45,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.050,posy:3.039,posz:5.182,mpox:1.270,mpoy:77.191,mpoz:131.623,vel:0.00,stat:3,coor:1,unit:0}}

If you run the following program, with a very short move sometimes line 2 shows up, sometimes not

N1 G0 X0

N2 M05

N3 G0 X0.001

Here is a case where it did.

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:1.000,posz:0.200,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.207,mpoy:77.191,mpoz:131.623,vel:0.90,stat:5,coor:2,unit:0}}

{"gc":"N3 G00 X0.001"}

{sr:{line:2,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.00,stat:3,coor:2,unit:0}}

{r:{gc:"N3G0X0.001",n:3},f:[1,0,23,8182]}

{sr:{line:3,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N4 M30"}

{r:{gc:"N4M30",n:4},f:[1,0,16,5082]}

{sr:{line:3,posx:0.001,posy:1.000,posz:0.200,mpox:6.221,mpoy:77.191,mpoz:131.623,vel:0.51,stat:5,coor:2,unit:0}}

{sr:{line:4,posx:0.245,posy:3.039,posz:5.182,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.00,stat:4,coor:1,unit:0}}

Here is a case where it didn't.

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:1.000,posz:0.200,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.208,mpoy:77.191,mpoz:131.623,vel:0.91,stat:5,coor:2,unit:0}}

{"gc":"N3 G00 X0.001"}

{r:{gc:"N3G0X0.001",n:3},f:[1,0,23,8182]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.00,stat:5,coor:2,unit:0}}

{"gc":"N4 M30"}

{r:{gc:"N4M30",n:4},f:[1,0,16,5082]}

{sr:{line:3,posx:0.001,posy:1.000,posz:0.200,mpox:6.214,mpoy:77.191,mpoz:131.623,vel:0.90,stat:5,coor:2,unit:0}}

{sr:{line:4,posx:0.245,posy:3.039,posz:5.182,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.00,stat:4,coor:1,unit:0}}

There are other problems with using the status report. I have written a macro interpreter that is an extension of G Code

to allow branching and functions. The block numbers going to the TinyG are not going to be contiguous, so this adds

another complication.

Old Man

From: John Lauer [mailto:notifications@github.com] Sent: Sunday, May 01, 2016 11:21 PM To: synthetos/TinyG Cc: rickcaddell; Author Subject: Re: [synthetos/TinyG] New feature request (#175)

ChiliPeppr keeps in sync by just asking for the Gcode line number to come back and I have found that to be spot on. You have to ask for that data in your SR request so it comes back. BTW, you can step thru your lines in CP.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub < https://github.com/synthetos/TinyG/issues/175#issuecomment-216098716> Image removed by sender.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/175#issuecomment-216106198

[rickcaddell]

John,

I have never tried Chilipepper because I use my own software, but from the pictures I have seen it looks quite professional.

I tried to send you a PDF file that describes my application but it came back as undeliverable.

If you want to look at it please send me an e mail at rickcaddell@epbfy.com and I will send it to you.

I am going to be sending the executable for my application to Kirby and Alden, if you want I can send you a copy.

Old Man

From: John Lauer [mailto:notifications@github.com] Sent: Monday, May 02, 2016 1:17 AM To: synthetos/TinyG Cc: rickcaddell; Author Subject: Re: [synthetos/TinyG] New feature request (#175)

Hmm, yeah, perhaps I recall writing a method that if a line number went from something like 2 to 4 i still generated an event for line 3 to fill in the gaps. I don't totally remember though.

There's a command you can place in a comment now in your Gcode in the CP world called (chilipeppr_pause arg1 arg2 ...) and at that line the code will stop executing and when it hits that line gives a callback so folks can branch and do all sort of fancy things. The Pick and Place stuff is being done that way.

On Sun, May 1, 2016 at 10:11 PM, rickcaddell notifications@github.com wrote:

John,

Thanks for the reply. I am using the block numbers in the status report, but they are not always right.

The problem with the status report is that it is on a time basis, so some blocks can get skipped.

I tried using the queue report but it doesn't report non movement blocks either.

Try running this program and look at the messages going back and forth. Notice that the line number 2 never shows up in a status report.

That's because the machine was already at X0 so block 1 and 2 were executed before a status message went out. Because the

status report is on a time basis, line numbers can randomly be missed. That is why I have asked for a new queue report, so the

syncing can be more accurate.

N1 G0 X0

N2 M05

N3 G0 X0.05

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:3.039,posz:5.182,mpox:0.025,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:1,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.001,posy:3.039,posz:5.182,mpox:0.013,mpoy:77.191,mpoz:131.623,vel:0.91,stat:5,coor:1,unit:0}}

{"gc":"N3 G00 X0.05"}

{r:{gc:"N3G0X0.05",n:3},f:[1,0,22,4290]}

{sr:{line:1,posx:0.000,posy:3.039,posz:5.182,mpox:0.000,mpoy:77.191,mpoz:131.623,vel:0.00,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.002,posy:3.039,posz:5.182,mpox:0.060,mpoy:77.191,mpoz:131.623,vel:4.31,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.017,posy:3.039,posz:5.182,mpox:0.429,mpoy:77.191,mpoz:131.623,vel:11.84,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.036,posy:3.039,posz:5.182,mpox:0.914,mpoy:77.191,mpoz:131.623,vel:11.47,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.049,posy:3.039,posz:5.182,mpox:1.235,mpoy:77.191,mpoz:131.623,vel:3.45,stat:5,coor:1,unit:0}}

{sr:{line:3,posx:0.050,posy:3.039,posz:5.182,mpox:1.270,mpoy:77.191,mpoz:131.623,vel:0.00,stat:3,coor:1,unit:0}}

If you run the following program, with a very short move sometimes line 2 shows up, sometimes not

N1 G0 X0

N2 M05

N3 G0 X0.001

Here is a case where it did.

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:1.000,posz:0.200,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.207,mpoy:77.191,mpoz:131.623,vel:0.90,stat:5,coor:2,unit:0}}

{"gc":"N3 G00 X0.001"}

{sr:{line:2,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.00,stat:3,coor:2,unit:0}}

{r:{gc:"N3G0X0.001",n:3},f:[1,0,23,8182]}

{sr:{line:3,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N4 M30"}

{r:{gc:"N4M30",n:4},f:[1,0,16,5082]}

{sr:{line:3,posx:0.001,posy:1.000,posz:0.200,mpox:6.221,mpoy:77.191,mpoz:131.623,vel:0.51,stat:5,coor:2,unit:0}}

{sr:{line:4,posx:0.245,posy:3.039,posz:5.182,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.00,stat:4,coor:1,unit:0}}

Here is a case where it didn't.

{"gc":"N1 G00 X0.000"}

{r:{gc:"N1G0X0.000",n:1},f:[1,0,23,9217]}

{sr:{line:1,posx:0.001,posy:1.000,posz:0.200,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.01,stat:5,coor:2,unit:0}}

{"gc":"N2 M03"}

{r:{gc:"N2M3",n:2},f:[1,0,16,1214]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.208,mpoy:77.191,mpoz:131.623,vel:0.91,stat:5,coor:2,unit:0}}

{"gc":"N3 G00 X0.001"}

{r:{gc:"N3G0X0.001",n:3},f:[1,0,23,8182]}

{sr:{line:1,posx:0.000,posy:1.000,posz:0.200,mpox:6.198,mpoy:77.191,mpoz:131.623,vel:0.00,stat:5,coor:2,unit:0}}

{"gc":"N4 M30"}

{r:{gc:"N4M30",n:4},f:[1,0,16,5082]}

{sr:{line:3,posx:0.001,posy:1.000,posz:0.200,mpox:6.214,mpoy:77.191,mpoz:131.623,vel:0.90,stat:5,coor:2,unit:0}}

{sr:{line:4,posx:0.245,posy:3.039,posz:5.182,mpox:6.223,mpoy:77.191,mpoz:131.623,vel:0.00,stat:4,coor:1,unit:0}}

There are other problems with using the status report. I have written a macro interpreter that is an extension of G Code

to allow branching and functions. The block numbers going to the TinyG are not going to be contiguous, so this adds

another complication.

Old Man

From: John Lauer [mailto:notifications@github.com] Sent: Sunday, May 01, 2016 11:21 PM To: synthetos/TinyG Cc: rickcaddell; Author Subject: Re: [synthetos/TinyG] New feature request (#175)

ChiliPeppr keeps in sync by just asking for the Gcode line number to come back and I have found that to be spot on. You have to ask for that data in your SR request so it comes back. BTW, you can step thru your lines in CP.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub < https://github.com/synthetos/TinyG/issues/175#issuecomment-216098716> Image removed by sender.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/175#issuecomment-216106198

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/175#issuecomment-216106544 Image removed by sender.

[rickcaddell]

Is there any TinyG developer that would want to implement this new feature request? It would be greatly appreciated. It is important for me to finish my application Chip (see https://github.com/rickcaddell/Chip)

[dgtlmoon]

Please change the title of this feature request , "feature request " is a terrible title. just something short and concise please

[rickcaddell]

I agree and have made the change. The reason that I used 'feature request' is that there did not seem to be a way to mark it as an enhancement rather than an issue. Do you know of a way? If so please describe.

From: dgtlmoon [mailto:notifications@github.com] Sent: Thursday, February 16, 2017 2:19 PM To: synthetos/TinyG Cc: Rick Caddell; Author Subject: Re: [synthetos/TinyG] New feature request (#175)

Please change the title of this feature request , "feature request " is a terrible title. just something short and concise please

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/175#issuecomment-280430442 , or mute the thread https://github.com/notifications/unsubscribe-auth/ALKosd2WNRyY1x5h3zdixrbIbw4FFd6yks5rdKE2gaJpZM4IVFw5 .Image removed by sender.

[aldenhart]

You can use the labels for that. I just marked it.

Thanks for your work on this.

[rickcaddell]

Alden,

Thanks, did not know how to do that.

Old Man

From: Alden Hart [mailto:notifications@github.com] Sent: Friday, February 17, 2017 10:45 AM To: synthetos/TinyG Cc: Rick Caddell; Author Subject: Re: [synthetos/TinyG] New queue report that reports every queue and/or dequeue of commands (#175)

You can use the labels for that. I just marked it.

Thanks for your work on this.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/175#issuecomment-280684762 , or mute the thread https://github.com/notifications/unsubscribe-auth/ALKoselKZdWnuHhIi-GIHuVlSLK9nvF5ks5rdcB2gaJpZM4IVFw5 .Image removed by sender.

[aldenhart]

Rick, You should know that we have deprecated queue reports, and at some time are planning to remove them - or at least disable them as a compile-time option.

Short answer: To get your sender working reliably we recommend using the line mode protocol. Send 4 lines to "prime" the receive buffer, then send a new line every time a response {r:...} is received.

Long answer: If I read your post correctly you are trying to keep an accurate record of what Gcode blocks (moves) have executed, so you can synchronize communications to that and possibly also display that in the UI. Please correct me if I'm wrong.

The basic problem we are faced with (and the reason the status reports work the way they do) is that when you send a file with a lot of very short moves the processor and communications channel cannot keep up with both the planning & step generation and the reporting & communications load. Something's got to get throttled back, and we prefer that to be the reporting.

Take for example a 3d print file, which can have a new Gcode block every millisecond or so - in some cases less. Or a CNC CAM file where an arc was generated by the CAM to a very tight chordal tolerance. Or a laser raster operation being fed a stream of tiny Gcode blocks that change the laser power along with the movement. These are typical cases.

To deal with this, the code limits the rate at which status reports are generated by the status-interval value (SI). This means that the latest report contains all information that has changed since the previous report, and it aggregates this information across multiple Gcode blocks in that interval. Hence the line number "skip".

Now to queue reports. These were introduced as a way to synchronize the sender with the planner queue for fine-grained control of the queue. We have since introduce the line mode communications protocol, which is simpler to run and more accurate to prevent queue starvation. The fact that the queue reports are generated for each queue insertion and dequeue runs into the same resource issues as status reports, although not quite as much as they tend to be shorter.

[rickcaddell]

Alden,

Thanks for taking the time to let me know what is going on, but I think you misunderstand the problem I am having.

The UI in my software shows the cutter paths for a part program, and as the paths are traversed, the UI shows the path in a different color to show progress. This works fine when I am running a program without interruption. I understand the timing of the status report, and that if several commands get executed between status reports that they will not be reported on. In other words the line numbers get skipped because the status report is running on one time base and the TinyG on another. I have accounted for this. For example if I see a status report with line no. 100 then the next report has line no. 103 I just draw all the blocks from 100 to 103. No problem.

However, my software allows single stepping of commands, optional skipping of commands and break pointing. I do a lot of inlays which are complicated and these features help me to debug my part programs. Here is where I am having troubles. Some commands get skipped altogether. I cannot step, or skip or breakpoint on these lines because they do not always get reported. I was hoping that a queue report that reported every line executed could be done, but I see you are going in another direction. Not a criticism, just an observation.

There is a case though that you may want to fix. When the last command is an non movement command, no more status reports are sent. And that last line number may or may not have been in the last report. I suggest that in that case another status report be sent showing that last line number.

I really have had no trouble with communications and keeping the TinyG fed. I have two internal queues, one for program commands, and one for special commands like cycle stop, which are sent ahead of program commands. I can keep 10 to 20 steps ahead of the TinyG. Every time I receive an 'r' response I see if more data needs to be sent. Having said that, I do a lot of contouring and most of the time the TinyG cannot keep up, even when it has several blocks. I can program in a feed rate of 30 in/min. but probably average about 1 in/min or often less. I do not think that switching to the mode protocol would help in this case. I don't even know if the version I have has mode protocol (see below). I would really like to speed up contouring. Any suggestions?

I have done a lot of microprocessor work in the past and am well aware of the timing and resource balancing. I have a suggestion that you may want to entertain. I understand juggling is tough. One idea I had is to be able to change the frequency of the status report on the fly. My software can tell when it is about to do a lot (sometimes thousands) of small moves and could change the report period to once a second, fine for showing the cutter path on the UI, then back to a higher frequency for long moves so I can show that progress throughout the move. I have it now set at {si:100}. Since this is a setting that gets stored in non-volatile memory, I do not think this can be done on the fly. Correct me if I am wrong.

One very confusing thing is that when issues are responded to, it sounds like new things are happening, but I if I look at the firmware download page, nothing has changed in what seems like a year. The following is the last version I downloaded, many months ago and this is still shown as the latest. Is this the current one? If not how do I get the current one?

Firmware Version : 0.970

Firmware Build : 440.20

Hardware Version : 8

ID : 3X3566-KBR

I am contemplating going to TinyG2, in fact I have bought the shield, but haven't had the time to try it out. Will I have a lot of trouble porting the a TinyG communication to the TinyG2? Will the TinyG 2 contour faster?

I really like that you have gone to an Arduino platform. I do have a question. One of my machine has two drives per axis on X and Y. Can two shields be mounted and configured so that I have basically a three axis machine with 5 axis? There are two rows of pads for pins, one populated with pins. I am not sure what the second unpopulated row is for (please explain), but If I replace the existing pins with pins that have a socket on top, so another shield can be stacked on, and on the top board only have power, ground, step and direction pins populated, can I drive two motors (for example the X axis), one from the bottom shield and one from the top shield? If so, what else would have to change?

Thanks again for the response.

Rick

From: Alden Hart [mailto:notifications@github.com] Sent: Saturday, February 18, 2017 8:18 AM To: synthetos/TinyG Cc: Rick Caddell; Author Subject: Re: [synthetos/TinyG] New queue report that reports every queue and/or dequeue of commands (#175)

Rick, You should know that we have deprecated queue reports, and at some time are planning to remove them - or at least disable them as a compile-time option.

Short answer: To get your sender working reliably we recommend using the line mode protocol. Send 4 lines to "prime" the receive buffer, then send a new line every time a response {r:...} is received.

Long answer: If I read your post correctly you are trying to keep an accurate record of what Gcode blocks (moves) have executed, so you can synchronize communications to that and possibly also display that in the UI. Please correct me if I'm wrong.

The basic problem we are faced with (and the reason the status reports work the way they do) is that when you send a file with a lot of very short moves the processor and communications channel cannot keep up with both the planning & step generation and the reporting & communications load. Something's got to get throttled back, and we prefer that to be the reporting.

Take for example a 3d print file, which can have a new Gcode block every millisecond or so - in some cases less. Or a CNC CAM file where an arc was generated by the CAM to a very tight chordal tolerance. Or a laser raster operation being fed a stream of tiny Gcode blocks that change the laser power along with the movement. These are typical cases.

To deal with this, the code limits the rate at which status reports are generated by the status-interval value (SI). This means that the latest report contains all information that has changed since the previous report, and it aggregates this information across multiple Gcode blocks in that interval. Hence the line number "skip".

Now to queue reports. These were introduced as a way to synchronize the sender with the planner queue for fine-grained control of the queue. We have since introduce the line mode communications protocol, which is simpler to run and more accurate to prevent queue starvation. The fact that the queue reports are generated for each queue insertion and dequeue runs into the same resource issues as status reports, although not quite as much as they tend to be shorter.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/175#issuecomment-280845065 , or mute the thread https://github.com/notifications/unsubscribe-auth/ALKosQMO7J3QQSynrqdDQ4yxutKFWBvDks5rdu-XgaJpZM4IVFw5 .Image removed by sender.