Machine not following gcode, crashes

Home › Forums › TinyG › TinyG Support › Machine not following gcode, crashes

Viewing 15 posts - 1 through 15 (of 20 total)
1 2
  • Author
    Posts
  • April 23, 2016 at 12:13 am #9576
    Vex
    Member

    Finally had my first cut today on my tinyg powered sherline mill. Long story short i have a problem and it goes like this:

    When using chilipeppr and entering gcode in the terminal it functions flawlessly. No issues. When I load up a gcode to run a part, it will read some gcode correctly and others not so much. In particular when doing a 2d facing operation it transverses both the x- and y-axis simultaneously when only the x-axis should be operating. Later on the mill will spontaneously plunge when it should be doing an incremental step down and clear function (it had previously completed 3 or 4 such operations prior to plunging).

    Needless to say I’ve reviewed the gcode generated by fusion360. I have noticed some oddities, namely there are instances in the facing operation which are missing the g1 and feed rate. This leads me to believe that the tinyg is ignoring the calls and just transversing between g3/g2 calls. Here’s a code snippet:

    G18 g3 x2.0687 z0 i-0.0125 k0
    G1 x2
    X0
    G17 g2 y-1.8259 i0 j0.0588
    G1 x2

    Since the feed rate is missing on all the g1 calls, I’m wondering if the feed rate is being pulled from an earlier call… but i don’t see anything close to it.

    As for the plunging, my reviews show no large calls to run a big step on z. Could i be overflowing the buffer on chillipeppr? I’ve left all the defaults in place and would think that shouldn’t cause any issues with the buffer, but my code is 103000 lines. Well outside the stated 25000 in the wiki…

    Anyone have any ideas on what to check?

    April 23, 2016 at 12:16 am #9577
    Vex
    Member

    Follow on: another problem as to why I’m posting here as opposed to another location/board os that both fusion360 amd chilipeppr simulate the gcode as intended. This leads me to believe that the tinyg post processor from fusion needs some fixin’ to bring the gcode generation into compliance with tinyg hardware. Just would like some confirmation before pursuing that route.

    April 23, 2016 at 7:35 am #9578
    cmcgrath5035
    Moderator

    When you say

    When using chilipeppr and entering gcode in the terminal it functions flawlessly. No issues.

    I assume you mean a line at a time in the Serial Console.

    With the limited info so far here, I’ll SWAG that you are experiencing “arc issues”, which seem to hit many folks using Fusion for Gcode generation.
    Step one, try regenerating you Gcode in mm (I am guessing it is inch), that frequently helps/solves.
    Step 2 might be to regenerate your Gcode with no arcs, only G1 moves.

    With all this, I am assuming you have $fb=440.20 loaded and a sane set of setup parameters.
    Perhaps post your parameters ($$ dump) to a cloud drive and post a URL.

    Based on info so far, this smells like tinyG issue, not Chilipeppr

    There is a new build, with focus on arcs, of tinyG currently being intensely tested by the devs.
    They may want access to your Gcode file as a test case.

    April 23, 2016 at 1:35 pm #9579
    Vex
    Member

    Hello cmcgrath,

    Your assumption is correct. I am putting a line at a time in the Serial Console (I’ve also done a line at a time in coolterm–but not during this run).

    Guess number 2 was right on the money. It was generated in inches. I’ve gone ahead and regenerated it in to mm.

    When testing the metric gcode; it appears that it works where the original code didn’t behave correctly; however it lost connectivity during one of the operations. When I re-connected and told it to restart from the beginning it did the face operation without issue, but when it moved on to the first pocket clearing it didn’t helix in at all. Retraction didn’t happen either. It was as though it missed the code that would tell it to retract to tool height (however it did retract to the correct height on the first run through prior to losing connection). Now that I write that out I’m about 99% sure that’s what happened. Could this be an issue with ChiliPeppr and the size of the gcode I’ve loaded? I’ve noticed that the response during jogging isn’t what it normally is.

    Yes, 440.20 is loaded. Parameters I assume are sane–they worked with all the onboard tests.

    Here are the requested files:
    https://drive.google.com/folderview?id=0Bx6o1FtzhQNZZnNCaHpUaVZaRHc&usp=sharing

    April 23, 2016 at 6:06 pm #9580
    cmcgrath5035
    Moderator

    Screw machine, I presume?

    Do you have a Axis?
    If not, I suggest set $4pm=0 to disable it.

    If you get a chance – please switch to mm mode when dumping $$
    TinyG is native mm, highly recommended that you enter parameters in mm.
    I keep a few comparison files around and use diff to compare too user files – helps separate the needles from the hay.

    It is not clear to me if all your testing in the big paragraph above was CP or a mix.
    There are some practical limits on size of file that can be loaded into CP.
    I don’t have much experience there.

    did you reset your jog distance after switching units?
    A jog of 0.1 is units agnostic, it will jog 0.1″ in inch mode, 0.1 mm in mm mode.

    Sounds like you are on the path to success

    April 24, 2016 at 3:11 pm #9587
    Vex
    Member

    Your presumption is correct.

    I currently do not have an A-axis but I do plan to incorporate one in the not-too-distant future. I have turned it off in the meantime.

    I have switched it to mm mode for the dump. Please see the previously linked folder to find the new file.

    My testing was to verify the program operated as intended when switched to mm. Which it appears that it does. Everything else related to CP sort of came out in the wash. I’m planning on trying once more today–changing the number of programs I have operating concurrently on my laptop while I run it–in hopes of seeing if it is able to complete the code. In the event that it is does not complete successfully I may attempt it once more using coolterm. Are there other programs from which to execute gcode that may prove useful? I find that I may be in need of a standalone version of CP; or even tgFX (although no longer supported/updated)… but I may just be out of luck on that front. Are there any other programs I should look into?

    As for Jogging: Yes, I verified I was using the appropriate units for a jog. The issue; as far as I’ve been able to tell is that the actual response from my button press to CP to Tinyg is lagged. Sometimes significantly to the point where it doesn’t register at all. Key press to CP seems okay most of the time, but CP to TinyG tended to be a little bit lack luster.

    As it does to me; I really appreciate your help/support in this troubleshooting session. Hopefully I have more success this time around.

    April 24, 2016 at 3:49 pm #9588
    Vex
    Member

    Okay– results from the last test: I am hitting the maximum line count on CP when the trouble starts. This is leading me to believe that my issues are now a result of the CP interface.

    The symptoms of it are around 12000 lines into the code the machine will suddenly stop updating/behaving similar to a dwell command on simple x- y- movements. After some time about 40~ commands will be sent to TinyG which responds and executes those 40 some odd commands–however CP does not fill the void thus the machine waits.I got tired of waiting for this process as it seems to occur for a good 10-20 minutes every time with no resolution or indication that it is a temporary effect.

    April 24, 2016 at 9:31 pm #9590
    cmcgrath5035
    Moderator

    I have not personally had your experience.
    Most CP users break up their jobs.

    Maybe just take your mm job back to CoolTerm?

    April 24, 2016 at 10:03 pm #9591
    Vex
    Member

    That was going to be my ‘last ditch’ effort to try and get it to work. I’ve done some digging and more testing as it relates to CP and large gcode files. My testing shows that it works (executed in excess of 120k lines of code).

    The solution for me was:
    1) Update java to latest version
    2) Allocate 2gigs to Java
    3) Disable the 3D viewer in CP

    In summary for the answers to this horribly phrased question in the OP are as follows:

    The issues with arcs is resolved by converting the generated gcode from imperial (inches) to metric (mm). To resolve the issues with CP allocate more ram to java and disable the 3D viewer (updating Java doesn’t hurt either).

    Again, thank you cmcgrath. You rock!

    April 25, 2016 at 6:10 am #9592
    cmcgrath5035
    Moderator

    Great to hear you are up and running.

    I am curious, though, about anything having to do with Java helping.
    Chilipeppr is all JavaScript, not Java.

    Browser (what do you use, Chrome?) of course supports Java. Perhaps by allocating more to Java directly, the browser has to provide less?

    Anyway, happy milling!

    May 23, 2016 at 7:37 am #9692
    kkannan
    Member

    I am having similar issues, and googled for days looking for a solution. My setup is belt driven tinyg V6 (yeah, it’s old) connected to Vista. It is not spindle noise since I don’t have one and it is not shielding issue either. A small program which cuts tabs and slots in 52 lines and the SP stops exactly in the same place, that is at line No. 11. Fiddling the settings to multi line and increasing delay does push this limit to up or down, but the job never completes.

    It seems when the machine is executing a long traverse line, CP dumps all gcodes and says job is completed while the extra lines are ignored by tinyg.

    Tried coolterm and it also ruins the job, machine goes crazy after 10 or 15 gcodes. XON is enabled as the doc says and $si is to 100ms. This is the snippet of gcode I am running and at the last line machine stops moving. Interestingly the planner indicates this line number and gcode indicates all 52 lines are sent.

    G90
    G21
    G00 Z-7.0
    G00 X10.363 Y75.708
    G00 Z-22.0
    F1000.0
    G01 X10.363 Y298.998
    G01 X40.637 Y298.998
    G01 X40.637 Y268.103
    G01 X29.637 Y268.103
    G01 X29.637 Y253.603

    if i hit the stop and g54, the machine goes to home position without fail.

    Can somebody help me resolve this issue ?

    Thanks in advance

    Kannan

    May 23, 2016 at 9:15 am #9693
    Vex
    Member

    It’s curious that it has the same issue in both CP and coolterm. My issue was a compound of having insufficient current for my Z-axis as well as memory issues using CP. If the issue is the latter, follow the above listed steps (updating java, allocating additional ram, and disabling the 3d viewer in cp). That should remedy any possible issue with CP… however, I do not believe your issue is precisely what I was experiencing and may be an indication of something else. Have you tried regenerating your Gcode in G91? It would provide another data point for review.

    May 23, 2016 at 4:20 pm #9697
    cmcgrath5035
    Moderator

    kkannan:
    I am surprised CP works at all with you V6 – CP aggressively uses enhancements to the communications protocols in tinyG.
    What FW rev you have loaded?
    I saw you query to Riley w.r.t. boot loader.

    I have a very up-to date ($fb=440.20) tinyGV7 that works fine.

    You are actually the first V6 user I have seen.

    I guess I am also a little surprised that CP runs on Vista – what browser you running?

    May 24, 2016 at 12:25 am #9700
    kkannan
    Member

    Hi vex & cmcgrath,

    Thanks for the replies, originally the machine was running RepRap which I use it to cut low density foam, plotter style using hot needle. I’ve written a java program using rx/tx lib which looks for ok> before sending the next gcode. This setup worked so well that I didn’t bother to change the boards which was Duemilanova with 3 separate stepper drivers.

    The reason I want to change it to Tinyg was speed and microstepping. I’ve two v6 boards which I want to use it. Setup went really smooth and looked a lot neater with less wiring. This time, my program started looking for tinyg [mm] ok> for end of execution of the previous cmd. But, I discovered that due the planner and everything, the response is not one to one. After few gcodes, the response comes in bulk or not at all. The machine stuck with the last cmd and does crazy things when it eventually receives a new gcode. That is the reason why it is going diagonally instead of straight line pattern in the gcode list, it simply missed the corner.

    After many experiments later, gave up on CP trying tinyg, old, tingygg2, line mode, idmode. The working setup in coolterm is 1000 ms for files with large line segments and 100 ms for short segments. My program breaks circles, arcs into small line segments. Though it works now, as you can see , a new program may still wreck havoc with the job. Foam material so cheap I can afford to waste it. Here’s my $sys params,

    [fb] firmware_build 338.02
    [fv] firmware_version 0.93
    [si] status_interval 0 ms [0=off]
    [gpl] gcode_select_plane 0 [0,1,2]
    [gun] gcode_units_mode 1 [0,1]
    [gco] gcode_coord_system 1 [1-6]
    [gpa] gcode_path_control 2 [0,1,2]
    [gdi] gcode_distance_mode 0 [0,1]
    [ea] enable_acceleration 1 [0,1]
    [ja] junction_acceleration 100000 mm
    [ml] min_line_segment 0.080 mm
    [ma] min_arc_segment 0.100 mm
    [mt] min_segment_time 5000 uSec
    [ic] ignore_CR (on RX) 0 [0,1]
    [il] ignore_LF (on RX) 0 [0,1]
    [ec] enable_CR (on TX) 0 [0,1]
    [ee] enable_echo 1 [0,1]
    [ex] enable_xon_xoff 1 [0,1]

    Any documentation to query the planner buffer and status could be helpful. IMHO, tinyg should not rely on third party for basic operations, there should be a basic Gcode sender however small and featureless it is.

    Thanks
    Kannan

    PS: Chrome on Vista Home premium

    • This reply was modified 8 years, 6 months ago by kkannan.
    May 24, 2016 at 3:04 am #9704
    kkannan
    Member

    finally a pseudo scientific approach that works. I calculated the absolute length of each segment from the previous one (ie. G00 or G01) and multiplied that with 75 and use it as line delay. This rule is applied to all segments below 15 mm, and above that a flat 1000 ms line delay is applied.

    I modified my old java program to calculate the length and delay on the fly and it seems to work smoothly without starving the planner buffer.BTW this applies only for Feedrate 1000 mm/min which is my default.

    I can live with this solution for now.

    Thanks
    Kannan

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 20 total)
1 2
  • You must be logged in to reply to this topic.