G2 arc code freeze #106
Comments
|
It works well if I send commands (in JSON format) line by line from the Console widget. You can try it manually: However, if I send the whole in a batch, things goes wrong just like you said - straight instead arcs. I will do a test on Chillipeppr and check for differences. |
|
Here is my output with |
|
My firmware build is 78.02. It didn't work for me when running this G-code program on Chilipeppr's TinyG workspace as well. Sometimes G2 goes straight line with random moves and unexpected result, not sure if it's related to these issues. Hi @jarretluft, Do you have chances to test the G-code program with TinyG2 on Chilipeppr? |
|
I made a firmware build 100.12 from G2 edge branch, and it still cannot work correctly on both cnc and Chilipeppr. |
|
??¡ I with Chilipeppr have not problems. With Chilipeppr it make a fluid circle, not problem. It do a good round corners in squares too. |
|
Dear Cheton, dear Gendebeat, I observed the same behavior using arcs (G2 and G3 commands), even with the latest firmware 100.15. The problem seems to be the handshake protocol of the TinyG2 controller. G2 and G3 commands may lead to a buffer overflow of the planner buffer, because these commands fill the planner buffer directly. I tried to modify the code due to the description of the communication protocol. 1) send a command to the controler 2) wait for a receive (ack - send as r: 3) send next command. This didn't work with arc commands, because these commands fill the planner buffer with a lot more than one value and the qr response is to slow. If you send more commands when the planner buffer gets filled by the G2/G3 commands, the controler crashes (??) I tried to program around this issue, but I don't know if it is the best implementation using the status report of the controler when a motion command is finished. (sr: line: #) The commands will be checked before sending and generate line numbers. If a G2/G3 command is sent, the sender will wait until the planner buffer has some free space and motion command is completed. I tested it with some different programs and looks quite good. You will find the modified files as attachment. Best Axel |
|
@amx1 I will do some tests for your code. Thank you so much for your help. |
|
Hi, I tested the codes of the example directory, e.g. jsdc.gcode, g2-arc.gcode, ... Some examples like the helical and the 3D print codes don't work, because the commands (E... and 3D arc) are not supported by TinyG2. Best Axel |
|
Thank you for the information. I did experience some problems with v100.15 and cannot figure out what went wrong. I will try your solution with v100.17 and keep you updated. |
|
Dear Cheton,
i contacted the developers of TinyG2. It is very simple now with V100.17 and „simple linemode“ it works like a charm. I attached the latest version. BTW it is not working with V100.15.
Best
Axel
Von: Rob Giseburt [mailto:notifications@github.com]
Gesendet: Sonntag, 8. Januar 2017 02:02
An: synthetos/g2 <g2@noreply.github.com>
Cc: Comment <comment@noreply.github.com>
Betreff: Re: [synthetos/g2] Random GCode Lines Skipped & Stopping in the middle of a Cycle. (#209)
I think we're seeing a lot over over-complication on the sender side. A lot
of this is due to historical protocols getting mixed up with the current
protocol. Let me explain.
The simplest way to send to a g2core machine is to simply send lines. You
have to honor when to OS blocks, but that's usually just a setting when you
open the buffer. We'll call this the "blasting" technique.
The main down side of that "blasting data" technique is that the buffer on
the host side becomes large and you can't send a feed hold. Also, some
hosts (small Linux machines in particular) don't handle large send buffers
well and use more processor than they should (probably in paging the buffer
to/from RAM).
So, the next simplest way to send to a g2core machine, and the simplest
with a very responsive feed hold, is to:
1) send a line
2) wait for the {r} response
3) go to 1 if there are more lines to send
4) done
We'll call this "simple line mode."
There is one problem with that technique in that some moves are extremely
brief, and may take longer to transmit than to execute. So to avoid jerky
motion in this case we "prime" the channel with a few lines. Four seems to
work well.
0) Count how many lines you have to send (IOW, in the gcode file, etc) and
put that in lines_in_file. Set lines_to_send=4
1) while (lines_to_send && lines_in_file) { send_next_line();
lines_to_send--; lines_in_file--; }
2) read lines from serial, counting {r}s. For each {r}, set
lines_to_send++. (Error checking and status report processing goes here.)
3) if lines_in_file > 0 the goto (1)
4) done
It's best if 1 and 2 are run asynchronously, either in different threads or
event driven, but that's not strictly necessary.
We'll call this "complete line mode."
Notice that in none of these do we care about queue reports (which are
deprecated, btw), or do we care about characters sent, etc. I did gloss
over the error handling, which is parsing the lines coming back paying
attention to the {sr:{stat:...}}, error reports in {er:{...}}, and non-zero
status in the response footer {r:..., f:[...,status,...]}. Non-zero status
is generally non-fatal and can be ignored.
As you can see, you can't "blow out" the g2core receive buffer. It'll just
back up on the host side.
We deprecated queue reports (qr) just for what amx1 was saying about how
some gcode lines (like an arc) can fill an empty queue all by themselves.
There's no clear relationship between a "line" and a "queue entry," and it
was way too hard to keep track of them.
On Sat, Jan 7, 2017 at 6:11 PM amx1 ***@***.*** ***@***.***> > wrote:
@aldenhart <https://github.com/aldenhart>, @giseburt
<https://github.com/giseburt> and all the others working on this,
it is the first time I am posting and therefore I would like to thank you
all for your amazing work first.
Maybe I can also help a bit by providing some experience I made. I have
some problems to use chilipeppr because I dont have a permanent internet
connection in my workshop and thats why I played a bit with the CNC
Software of Cheton Wu (https://github.com/cheton/cnc). The implementation
of the TinyG2 protocol in chetons code is not working without problems and
I tried to fix it.
The update to V100.17 changed the behaviour of the controller very much.
It is now working much closer to the described protocol ( "r" handshake aka
linemode), but I also saw the errors of dropping lines or even crashing the
controller especially with ARC (G2 G3) or S.. or M commands also. You will
find my modified subroutines of chetons code in the attachment. Take it as
an example for the implemented state engine. The problem for me was, that
that the controller sends an {r: ..} always after receiving the command
independent of the status of the planner queue which leads to a buffer
overflow if you dont check QR. Simple commands and linear moves only
generate one entry in the planner queue, but arcs and other commands could
generate more entries automatically. Therefore checking the qr state before
sending against a "low water mark" only is not sufficient. I implemented a
wait state for the "complex" commands which stops the sender until the
controller issues the next sr: line report. From my timing log, it seems
that the controller sends the sr: line statement when starting the
execution of the specific command. It has then enough space for the next
arc or linear move, if the planner queue is not filling (qi == 0 or qo >
qi). Up to now it is running pretty smooth with all my test cases.
The challenge for me is, that the complex buffer chain and the variable
reporting makes it very difficult to synch with the controller, if you want
to fill the planner queue as much as possible. Chilipeppr was the benchmark
for me. The "handshake" behaviour changed significantly from V100.16 to
V100.17. The attached version only runs with V100.17 only.
An ideal solution for me would be, if the controller send the {r:..} as an
acknowledge stating that it is ready to receive the next command
independent of the type of the command and the status of the planner queue,
because the simple handshake protocol: send a command wait until {r:..} and
then send next command floods all buffers and crashes the controller even
in V100.17.
All test were made with Arduino due, V100.17, a custom grbl Shield and a
CNC3040
Best
Axel
TinyG2_V100.17.zip
<https://github.com/synthetos/g2/files/691778/TinyG2_V100.17.zip>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<synthetos/g2#209 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXj0UigGdNcJK7aZ_8HOBB2zx-WccpNks5rQCnJgaJpZM4LV7xj>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <synthetos/g2#209 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AXqtvMV9gS8ledvPnx7YUIuQGd8MWb1lks5rQDWQgaJpZM4LV7xj> . <https://github.com/notifications/beacon/AXqtvLv364IXGiOYF03-7iseyq8IO88Kks5rQDWQgaJpZM4LV7xj.gif>
|
|
Note that I made some code changes to the controller interface in v1.8.13. If you want to merge with new changes, you need to update your code with new initialization parameter and the 'load' command callback. this.sender = new Sender(STREAMING_PROTOCOL_SEND_RESPONSE);'load': () => {
const [name, gcode, callback = noop] = args;
const ok = this.sender.load(name, gcode);
if (!ok) {
callback(new Error(`Invalid G-code: name=${name}`));
return;
}
log.debug(`[TinyG2] Load G-code: name="${this.sender.name}", size=${this.sender.gcode.length}, total=${this.sender.total}`);
this.workflowState = WORKFLOW_STATE_IDLE;
callback(null, { name: name, gcode: gcode });
}, |
|
I upgraded my Arduino Due firmware to g2core v100.19 and tested several gcode files (e.g. "jsdc.gcode") with your code, but it didn't report machine position and all stopped from the beginning.
May I have your terminal output to compare the differences? You can run
|
|
I created a g2core branch (https://github.com/cheton/cnc/tree/g2core). You can try it with v100.17 on an Arduino due board. |
|
Ok, we worked in parallel. There were a lot of left overs in my old
version. I cleaned it up and made an update to 1.8.13. You might try it. I
included a diff as patch input to see what I changed. The jsdc example runs
smooth. I attached the log. I am on nvm version 7.3.0 and npm 4.0.5.
After some exchange with aldenhart the main issue was using JSON stringify
for sending gcodes. This is not forseen and leads to an error (104) and
bypasses the planner queue - but executes the commands.
There is one open point left: running codes in imperial coordinates, e.g.
the circle-inch.gcode The controller reports the work coordinates in inch
but the machine position still in mm. I did not find the position in the
cnc code where to fix it. The log is attached.
2017-01-09 10:34 GMT+01:00 Cheton Wu <notifications@github.com>:
… I created a g2core branch (https://github.com/cheton/cnc/tree/g2core).
You can try it with v100.17 on an Arduino due board.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#106 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AXqtvNvU_MvaQqekds6eCX22B2UupHIVks5rQf8sgaJpZM4LITGq>
.
|
|
The machine position is always reported in MM, and in absolute (machine) coordinates with no offsets. This is to provide UIs with the ability to always display a graphic position without having to track the units more or state of the offsets (which can get complicated). Update: I realize this could be clearer in the status reports page, so I updated it: |
|
Hi amx1, I cannot see your attachment, could you upload files again? BTW, please let me know if you are interested in becoming a project collaborator, I can add you to the collaborator list, and you can push commits to the g2core branch for verification. |
|
Hi Cheton,
ok,
2017-01-09 15:43 GMT+01:00 Cheton Wu <notifications@github.com>:
… Hi amx1,
I cannot see your attachment, could you upload files again?
BTW, please let me know if you are interested in becoming a project
collaborator, I can add you to the collaborator list, and you can push
commits to the g2core branch for verification.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#106 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AXqtvACZJ8jw1jWEKPIiq7bSZmXdGVDzks5rQkd4gaJpZM4LITGq>
.
|
|
Invitation sent |
|
The firmware TinyG2 for arduino due had some issues suddenly stopping the job, but the problems should be solved now. Aldenhart and Giseburt will include the changes in the next few days in the edge branch. You might test the FW branch dev-209b... synthetos/g2#209. I had no errors since then. I also updated the TinyG controller part of cnc. Thank you cheton for inviting me and setting up a separate branch, but I hope it is fixed now and I will leave to you to include the changes into your dev branches. I think we don't need a separate branch for this now. There is one point left: The performance of the GUI depends very much on the power and the OS of the machine running the browser. My setup: the controller is connected to a X86 PC running Ubuntu 16.04 64bit. The front end is a dual boot laptop dell x86 Windows 8.1 or Ubuntu 16.04 64bit, Wifi. The GUI is quite slow and the updates of the positions of the machine are stuttering on Windows 8.1 either with chrome or firefox. On linux it is very smooth in both cases even on the same Laptop! The controller is not loosing any commands or steps in all cases. It is mainly a GUI problem. Attached you will find the updated version based on v1.8.15. It implements the simple linemode protocol with a low / high water threshold to throttle the sender in case of very fast jobs. Otherwise you might get not updates of the position. See discussions with fw developers synthetos/g2#209 |
|
I just patched the 1.9.0 alpha version to support the latest g2core FW on Arduino Due @cheton I had to change the init sequence, because you can't split the sr sequence in two parts. The first one will be overwritten on Arduino Due. There is a buffer limit of 254 chars, so I implemented a compression hack. |
|
Thank you for your efforts! I will make a test by tomorrow. |
|
Thanks for the information. I took a look at synthetos/g2#209 and made several tests, the result of my experiment confirms the same thing as @giseburt said in synthetos/g2#209 (comment), sending In addition, I'll also remove the help query (?) from my init commands, as it will turn subsequent status reports to standard text output, not in JSON format. That might be the actual reason why I chose to use Hi @giseburt, After upgrading to g2core firmware build 100.19 for my Arduino Due, I faced two issues as listed below:
reported an error of "159: Arc specification error - endpoint is starting point" This error doesn't happen with firmware version 0.98 (firmware build: 87.01). |
|
@cheton I saw also the effect of the missing reports of line, feed, etc. The problem is, that you split the configuration of the report in 2 parts from v1.8.15 to 1.9.0 during init. All switches not set to true, will be set to false by default. Therefore the first part is ignored. You can overcome this and the limitation of 254 character by compressing the commands using t instead of true. It will give you some extra space. With this option the whole configuration could be send in one line. If you take a look at my version, you can see that I put everything in one command and used a .replace after JSON.stringify. It was the fastest way to implement it. Take a look at the sent commands in the log marked as: "[TinyG2] > Init: ...." |
|
I've reduced the init command as below within the limit of 254 characters, so it should not be a problem of serial buffer overrun: The strange thing is that my g2core firmware build 100.19 reported error code 159 for the line 2: I also noticed that we have one minor difference in the fbs string: "100.19-16-g80bf-dirty" vs. "100.19-12-gb6995" May I tried using your built firmware? Either .elf or .bin is fine. Thus we can make a test on the same basis. Thank you! |
|
@cheton |
|
looking at {"r":{"n":2},"f":[1,159,17]}, the controller takes this command as line number 2 because of "n":2. Which sender routine are you using? The original one or mine, because the original one checks only the f statement which means no error, my version waits for the correct line number. The {"r":{"n":... This is sent when the command is processed. |
|
I just tested your firmware build and it ran without problems. I remembered that I checkout edge branch for g2core, but forgot to checkout the edge branch for the Motate submodule. Would it be the problem? |
|
@cheton am@PC-LAB:~/workspace/git/TinyG2/g2core$ git branch -l
|
|
I also noticed that yesterday, it's fixed in this commit: |
|
"pos (IOW posx, posy, etc) are always in mm.
"mpo" (mpox, mpoy, etc) are in the current units.
Also, the current unit is in the "unit" value. 0 is inches (G20), and 1 is
mm (G21).
These can all be put into the SR. (Note you can't add a group to the SR, so
you have to add mpox, mpoy, not mpo.)
…-Rob
On Fri, Feb 3, 2017 at 12:49 AM amx1 ***@***.***> wrote:
Perfect!
There is one thing left for jobs with imperial coordinates. The controller
return the wpos, vel and feed in inch but the machine pos always in mmi
dont know where to implement this conversion
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#106 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXj0ewMczRulNlxzzrscvfA2_2x7OWCks5rYs3ygaJpZM4LITGq>
.
|
|
Actually, it's the other way around. The reason for this is that DROs usually need pos responses, and graphics displays usually need mpo responses. |
|
@cheton |
|
For the GUI performance issue you mentioned earlier, I will remove the list view from the G-code widget in 1.9. Each time when receiving new state update from server, it will re-render the list view again, and therefore cause significant performance drop on auto scrolling.
You can check if you have a performance gain after removing G-code widget from your workspace. |
|
I checked the latest master branch, sorry to say, the G2 error is back again. I tried both parameters: complete line mode and simple line mode. see test and log files. I think the complete linemode is not needed, because the USB connection is fast enough. The idea of CLM is to "burst" the first 4 lines to fill the planner buffer and then loop in simple linemode, but it has the risk that even the first 4 lines scramble the input buffer. I will check the code. I think I saw the problem already. I had a different issue with GUI performance. It is related to the update of the position of the tool in the 3D graph. It is not due to your 3D implementation. It is due the concept of the software of the controller for very fast moves. It is clear that the controller has to prioritize the different tasks. The control of the steppers has to have the absolute priority. Therefore status reports are delayed or postponed in the case of very fast jobs (series of very fast moves). The only feedback is the ACK of a received command, {r: You can see this effect even in the attached log files. You send a lot of commands without receiving a status update of pos, vel, feed, ... You will have no information to update the position of the tool in the 3D widget. The tool is "jumping" with very large steps. It doesn't influence the correct function of the controller. The cnc machine is running properly, but the display doesn't look nice. My approach was to implement the simple linemode, with a throttling when the planner buffer is full. I stop the sender if qr =4 and restart the sender when e.g. qr=6. This will give some headroom to receive an update of pos, vel and also line. You can see the different behaviour in the log files. I attached also the log for my actual version for the same test case Test_20170204.zip |
|
Thank you for your detailed and clear explanation. I'm not aware the effect of delayed status reports for a very fast job. The reason why I tried not to watch queue reports since it will be deprecated as mentioned earlier by @giseburt. G2 and G3 arcs did work when I tested yesterday, but now it happened again after I made several code changes. I think the G2 error might be caused by refactoring the workflow state (877b674). I will take a closer look at your attached logs for further investigation. |
|
I tried to implement my first idea. It is running, but I did not finish
checking yet.
amx1
2017-02-04 17:38 GMT+01:00 Cheton Wu <notifications@github.com>:
… Thank you for your detailed and clear explanation.
I'm not aware the effect of delayed status reports for a very fast job.
The reason why I tried not to watch queue reports since it will be
deprecated as mentioned earlier by @giseburt <https://github.com/giseburt>
.
G2 and G3 arcs did work when I tested yesterday, but now it happened again
after I made several code changes. I think the G2 error might be caused by
refactoring the workflow state (877b674
<877b674>).
I will take a closer look at your attached logs for further investigation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#106 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AXqtvCl7ZIvK9lrJvwo6XL2AUMC5CLXJks5rZKmdgaJpZM4LITGq>
.
|
|
the sending routine seems to work, but the control of the workflow: start, pause, stop, resume is still buggy, I implemented the renumbering of gc lines also, because I like the display of lines sent and compare it with lines processed. you will find errors of the gcode a bit faster |
|
quick and dirty solution with line numbers and throttling for fast jobs |
|
thank you for fixing the imperial coordinates for 3D view, it is ok now. There is still a difference in the axes widget. The machine position is ok, the work position is to small by the conversion factor
|
|
I changed a bit to your work, most were some name changes and refining if-else statements, you can checkout the master branch and do tests again. BTW, the work position was corrected in this commit 2bac497. |
|
I did a quick check. It looks really good now. I didn't find any critical issues yet. Thank you very much! We should thank also @aldenhart and @giseburt for their quick responses. |
|
the "pulldown" options of the TinyG widget are really cool, what do think of implementing this also for the G-code widget to show the gcodes, because in some error cases it might be helpful to see the actual gcode line. |
|
How about adding a button that opens a new window to show the gcode? |
|
Dear cheton,
yes, perfect, this is the best idea, because it will be needed only for debugging.
BTW: it runs perfect now. I am thinking about a soft reset sequence, because in case of an gcode error, it is quite inconvinient to find the right sequence of commands to stop the workflow, sender and clear the controller.
Von: Cheton Wu [mailto:notifications@github.com]
Gesendet: Montag, 6. Februar 2017 12:32
An: cncjs/cncjs <cncjs@noreply.github.com>
Cc: Mention <mention@noreply.github.com>
Betreff: Re: [cncjs/cncjs] G2 arc code freeze (#106)
How about adding a button that opens a new window to show the gcode?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#106 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AXqtvFiUAG44EuBVQmPmr67V5ndXX5OVks5rZwSzgaJpZM4LITGq> . <https://github.com/notifications/beacon/AXqtvGy9Thk_akTuknhoH77vmQgvQhIeks5rZwSzgaJpZM4LITGq.gif>
|
|
I checked the actual master branch, with the following errors /home/am/workspace/git/cnc-master/showdown.js |
|
I applied https://cnc.js.org yesterday and integrated showdown into the post build process to generate a html page under /docs. It's fixed in the master branch. |
Hello. i think this programs is great!
I use it for a year and I like it more than the web of chilipeperr.com,It is comfortable and visually pleasing
I use now tinyg2, de 100.x branch.
i use vectric aspire and when i generate gcode with arcs, g2 or g3, the tinyg2 freeze or make bad arcs.
First i think was a tinyg2 issue, may be the configuration. i try other earlier versions but not resolve the problem.
But yesterday i try to send the same gcode through chilipepperr.com, and woilaa, it works correct.
When i use this program to send gcode like this:
the program stops o make bad desings (like straigth instead of arcs).
some times in one point. sometimes in other.
may be the problem is with the J besause,
when i send code like this:
Can it be a problem sending the gcode through the json server?
thanks
The text was updated successfully, but these errors were encountered: