- This topic has 15 replies, 5 voices, and was last updated 10 years, 10 months ago by
.
-
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
tomkingcnc@gmail.comNew 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.0I 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.
Tom..
just checking but..
you said shut down tinyg then issued the avrdude command.. Tinyg needs to be ON and in bootloader “mode”.. (basically the first 3 seconds after powered on or the rest button is pressed for it to work..
see step 3 here..
https://github.com/synthetos/TinyG/wiki/TinyG-Updating-Firmwareand here is the hex file to use.. just incase https://dl.dropboxusercontent.com/u/9726802/TinyG/tinyg.hex
- You must be logged in to reply to this topic.
