Machine not following gcode, crashes

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.

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

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.

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.

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!

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

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.

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

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