Synthetos Shop

TinyG/CoolTerm crashing solved

From the original Synthetos forum (2011–2025)

Started by tomking505 on in TinyG Support. 15 replies, last activity Feb 28, 2014.

tomking505 #

I have repeatedly mentioned the problem of TinyG taking off on its own after a job is cancelled in CoolTerm. It turns out that neither TinyG nor CoolTerm are malfunctioning. It's the documentation that is incomplete.

CoolTerm isn't at fault. When cancelled in the middle of a run, CoolTerm simply stops transmitting. That's why clearing the CoolTerm buffer does not help. The problem is partial commands that have already been sent to TinyG.

Here is how to stop crashing when cancelling a job being sent with CoolTerm.

1. Press "cancel" in the CoolTerm progress dialog. (The CNC machine will continue moving, because TinyG is still processing commands in its buffer.)

2. In CoolTerm, press the exclamation point (!). This halts TinyG.

3. In CoolTerm, press the percent key (%). This clears TinyG's input buffer. TinyG will not take off on its own when you enter additional commands.

If these instructions had been in the documentation, it would have saved me a huge amount of time and materials in the past three months.

I can't actually guarantee this solves the problem, but since I started doing this, I have not had a crash. I hope this info helps someone else.

Tom King
[email redacted]

tomking505 #

As I said, I can't prove this works, but it seems to. If my idea turns out to be right, someone might consider adding this to the TinyG documentation. Maybe the Grbl board, too.

Tom King
[email redacted]

RileyStaff #

Tom,

That is how jogging work in tgfx. I say make a move (a large one) then when the key is release it sends that exact byte sequence.

This is a TinyG specific thing. Grbl would not do anything with those bytes. (unless they are using the same thing as us?)

It is in the docs.
https://github.com/synthetos/TinyG/wiki/TinyG-Feedhold-and-Resume
However that does not state "how to stop a job in coolterm" which is what I think you meant by not in the docs?

ril3y

tomking505 #

I am talking about ! stopping TinyG, and % clearing the buffer. Since you also make a GrblShield with relatively similar function, I thought it was a possibility that ! and % worked similarly.

tomking505 #

New data point:

I have been issuing a "!%" every time I cancel a job sent to TinyG via CoolTerm. (I am still using CoolTerm because I have posted here several times that I cannot update my firmware, but I have received no response, so I plod along with CoolTerm.)

Since issuing !% every time I cancel CoolTerm, my TinyG has not galloped off on it's own, until just now. It is possible that the ! and % need to be issued separately, or that I a wrong about what makes TinyG flip out.

Here is the output from CoolTerm:

(cutting a 24 mm circle)
posx:-12.243,posy:-4.627,vel:199.995
posx:-11.932,posy:-5.381,vel:199.995
(hit cancel on the CoolTerm dialog)
tinyg [mm] ok> 
tinyg [mm] ok> 
(machine keeps cutting, because there are commands TinyG buffer)
posx:-11.572,posy:-6.114,vel:199.995
posx:-11.170,posy:-6.823,vel:199.994
posx:-10.713,posy:-7.519,vel:199.995
posx:-10.224,posy:-8.172,vel:199.995
posx:-9.694,posy:-8.792,vel:199.995
!%
posx:-9.128,posy:-9.380,vel:199.995
posx:-8.905vel:0.000,stat:3
(TinyG stops cutting)
(I manually type Z0 to raise the cutter)
z0
<strong>tinyg [mm] err: Arc specification error: z0 </strong>
(TinyG sends my router in the positive X direction)

The last line is an arc spec error, meaning that CoolTerm was interrupted while sending an arc command. Sending a !% apparently didn't clear the TinyG buffer, because Z0 is not an arc. So there must have been a fragment of my circle-cutting gcode still in the buffer.

But here is something strange. The code does nothing except cut a 24mm circle. No straight lines at all. But when TinyG took off on its own, it began moving the cutter straight in the positive X direction!

My supposition has been that fragments of code remain in the TinyG buffer, and they get executed when I issue a command. But there is no fragment of the circle cutting gcode that would issue a positive X. Here's the code.

G1 F333.0 Z-0.5
G3 F200.0 X-6.545 Y11.3363 I-13.09 J0.0
G3 Y-11.3363 I6.545 J-11.3363
G3 X13.09 Y0.0 I6.545 J11.3363

G1 F333.0 Z-1.0
G3 F200.0 X-6.545 Y11.3363 I-13.09 J0.0
RileyStaff #

Hey Tom,

TinyG is modal. Resetting the buffer does not reset the board or the mode. Since g3 was the last "mode" it was in. It will continue to be in this mode until you change it. I think you opened another thread that is similar to this problem if not the same here?

https://www.synthetos.com/topics/tinygcoolterm-crashing-not-solved/#post-5526

If this is the case I am going to move that thread here. I think putting up multiple topics on the same issue is a bit confusing.

If this is the same issue (z0 ran 4x times when in modal g3 sent tinyg into la la land when you send the correct gcode g0z5) then you very well could have found a bug. What I would suggest for now is to not send invalid gcode (if it can be avoided :) I tried to reproduce this however have not been able to as of yet. I am no way saying you are not 110% correct in seeing what you have seen! Just to be clear. The best way (if you are interested) to help us fix / identify this bug is to spell out exactly what it takes to reproduce it. For example:

1. Hit reset on Tinyg.
2. Opened coolterm and connected with RTS checked at 115200 baud.
3. Sent a file to TinyG.
3a. The file was.
G0x100
G0x0
G1F250x10y20
4. Hit cancel 5 seconds into the job.
5. In coolterm typed !% hit enter.
6. TinyG Stops
7. Typed in coolterm Z5 5x times. Each time with error "XYZ"
8. Type in coolterm G0Z0
9. TinyG goes off into XYZ coords.

Bug reproduced.

I admit timing bugs (5 seconds into the file send etc) are a bit harder to pinpoint. This kind of diagnostics gives us a fighting chance at fixing your issues.

Coolterm Advice / Issues:
Canceling jobs via coolterm is not as simple as you might think. As an FYI the OS is controlling flow control. So hitting cancel does nothing to the OS buffer that has been stored up. So typing !% will clear the buffer that currently resides in the TinyG. However the OS may / could have many bytes buffered. Simply pressing cancel does not clear the OS output buffer.

Which is really the heart of the matter. Coolterm is not meant to be used interactively they way you are. tgFX is much better for doing such operations. I did see you had an issue in updating your firmware. I think cmcgrath posted a link that you said you were going to look into last I checked.

https://www.synthetos.com/topics/updating-the-firmware/

However, if you are still having issues I was not aware you were unable to get firmware updating to work. I have been working on getting firmware updating working in tgFX. Its still a bit raw. That being said you are more than welcome to send the board in and I will update the firmware for you.

Trying to help.
ril3y

psyko #

TinyG is modal. Resetting the buffer does not reset the board or the mode. Since g3 was the last “mode” it was in. It will continue to be in this mode until you change it.

Agreed, sending simply a Z0 command doesn't mean anything in Iso GCode.
It's like hitting the accelerator pedal and expecting the car to move forward while you have the rear gear engaged.

tomking505 #

I finally figured out what you were talking about. Not everyone understands what "modal" means in this context.

For the other frustrated people who will come after me, you are saying that once it's in G1 mode, it stays there until you issue something like a G0 or G3. In my case, TinyG was apparently left in G3 mode when CoolTerm quit sending. It expected commands to be in G3 mode (curve) until I changed to G1 or G0.

So the idea is, once I cancelled TinyG from CoolTerm, I should have entered "!% G0 Z0", is that right?

Alden, Riley: PLEASE start putting this stuff in your documentation wiki. It would be easier to write it down once than to answer these questions. Plus, it would eliminate the need for your paying customers to be frustrated by the partial documentation.

Writing your documentation in a forum, bit by bit, is a recipe for disaster. It's wastes everyone's time, and leads to reasonable complaints you would rather not get.

tomking505 #

>I was not aware you were unable to get firmware updating to work.

I have mentioned it repeatedly for months.

>you are more than welcome to send the board in and I will update the firmware for you.

I would be grateful. Since you do not list an address on your About page, could you kindly send me that necessary information?

tomking505 #

I completely set up another laptop to try to update my firmware. Downloaded the firmware, downloaded CoolTerm, downloaded the Coolterm extensions, downloaded libusb0.dll, downloaded AvrDude. I verified that the hex file was not html.

Looked up the AvrDude syntax on https://github.com/synthetos/TinyG/wiki/TinyG-Updating-Firmware. Confirmed I'm on com4.

I shut down CoolTerm and issued the AvrDude command specified on your firmware page, "avrdude -p x192a3 -c avr109 -b 115200 -P COM4 -U flash:w:TinyG.hex"

The result was exactly the same as on my other laptop. What I got again was:

Failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed failed

grim #

Did you put the tinyg.hex file in the same folder as avrdude?
Did you rename the tinyg.hex file to tinyg.hex (or to EXACTLY what you put in the command -U flash:w:tinyg.hex)?
Did you search for anything about using avrdude first so you might be familiar with what you're actually doing by typing those commands? Prior to attempting to flash my first time I googled avrdude and found a nice tutorial from ladyada. Perhaps this would be useful for you as well.

Typing "failed" a thousand times may have helped your frustration but it didn't help anyone else out in figuring out what went wrong...just sayin.

mcgyvr #

^^ make sure you right click on that tingy.hex file and download/save it and not just let it open in the browser..

RileyStaff #

Firmware Update:
Can you show me in the firmware updating documentation that is says to 'download avrdude' ? There are many many many many random avrdude.exe bins floating around on the internet. I am not sure what avrdude bin you are using. Re-read this.

https://github.com/synthetos/TinyG/wiki/TinyG-Updating-Firmware#wiki-step3

Specifically,

The quickest way to get a binary version of avrdude for your system is to download the latest version of the Arduino IDE.

As far as "repeated for months" goes. Your last post on that page firmware updating issue page was you were going too looking into a possible fix that mcgyver posted." You did not follow up. You also have opened 30x topics that all are closely related not to mention posting on other topics your issues. This honestly is hard to follow. I am not saying you are wrong to do so. I am simply stating that its a bit of a "who knows what is wrong".

Documentation:
Documentation or the "assumed" lack thereof. TinyG wiki is about how TinyG operates. It is there for assumed that you know something about Gcode. There are plenty of Gcode tutorials out there that you can read to get up to speed on it.

Address:
Yes we do not provide this on the web page. By design.
you may email customerservice @ synthetos.com to get the address to send your board back in.

So the idea is, once I cancelled TinyG from CoolTerm, I should have entered “!% G0 Z0″, is that right?

Yes and no. Did you read my post about hitting cancel on Coolterm? If you did and did not understand please let me know. If you were to say send a G0X10000 that would be a very far move on the X axis right?
If you wanted to stop this move you would do !% then if you wanted to go to Z5 then you would do (after you sent %!) G0Z5 yes.

Again, sending file in coolterm is good for sending a file. Not stopping not resuming not anything else. At least during the file send.

Still trying to help.
ril3y

psyko #

tom, you should always use the motion Gxx keyword before issuing a move, unless you're 100% sure of the mode.
I would suggest you to read the RS 274 NGC GCode specification :
http://technisoftdirect.com/catalog/download/RS274NGC_3.pdf

Once you have a good understanding of GCode functionalities, you can try and use TinyG.
I've been using it for a while now, and didn't notice major issues. What you are mentionning really are the basics of GCode... I would be surprising that those basics methods don't works, regarding what I've been able to do with the board.

The only issue I'm having is small unexpected arcs. But I'm still trying to figure out the cause (TinyG, USB noise, so on...)

This topic is from the original forum (February 2014). Your reply starts a new discussion linked to it.

Reply

Different problem? Ask a new question

Back to TinyG Support or latest activity.