Forum Replies Created
-
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.
>Gcode is modal – the gcode interpreter must have been in a G2 or G3 arc command before entering the z5′s.
Yes, I said this gcode draws 24mm circles. That’s all there are are G3s.
>The arc specification error is Gcode telling you that the command is not a full specified arc.
That was my assumption.
>When you entered the G0 Z0 command you changed to traverse mode.
Yes, it should have. So then why didn’t it go to X5? That has been the behavior until today. IF I enter a malformed G3, I get an error. After that, it should respond normally to commands, but didn’t.
>Was X5 Y11.336 a target of the previous arc?
I posted the gcode in the previous message on this topic. It is:
G0 X13.015 Y0.0 G1 F333.0 Z-0.9 G3 F200.0 X-6.5075 Y11.2713 I-13.015 J0.0 G3 Y-11.2713 I6.5075 J-11.2713 G3 X13.015 Y0.0 I6.5075 J11.2713 G1 F333.0 Z-1.8 G3 F200.0 X-6.5075 Y11.2713 I-13.015 J0.0 G3 Y-11.2713 I6.5075 J-11.2713 G3 X13.015 Y0.0 I6.5075 J11.2713 G1 F333.0 Z-2.7And forgive me for pointing out that you did not address the substance of my message. Quote: “Note at the bottom, when I manually enter a “G0Z0″, and TinyG responded by sending my cutter to x5y11 at high speed, breaking the bit!”
>Not saying that you shouldn’t spend time attempting to find bugs
Thanks for responding Mcgyvr. You have the wrong idea. I’m certainly not looking for bugs. I’m just trying to get an important project done. Ought to be pretty simple.
>My mom said.. “Then don’t touch your eye..
Yes, I’d like to stop poking myself in the eye. But I have a project I started in November, the reason I bought the TinyG, is DUE next week. Due as in I’m royally screwed if this isn’t done. I’m talking “thousands down the toilet” screwed.
>Maybe you should just use the e-stop button or find another way
Certainly a fine idea, except, this is the best I have found. If Riley or Alden have suggested a solution, I didn’t see it.
> I’m sure they would be happy to do that for you since you have repeatedly complained about not being able to do so..
If that was an option, why didn’t someone say so two months ago? Have I not made it clear there is something very wrong here?
Anyway, I appreciate that you wrote back. Sometimes I feel like I’m all alone here.
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.0I may have a clue to why my machine moves strangely after a Coolterm cancel.
I just got the same behavior, except I got a curve error. Backtracking it makes me think Coolterm is halting exactly when you hit the cancel button. It doesn’t halt after it sends a return, as I assumed. If true, Tinyg only receives part of a command. When I manually enter a command and hit enter, Tinyg sees the partial command plus my command, and tries to do something with it.
I would prefer to use TGfx. The hold button works much better for halting a job. But I still cannot update the firmware on either of my TinyGs.
Tom
Okay. Thanks, let’s try that.
- 1. First I press the button, then type, then press the button again.
- 2. This time, I typed the html tags manually.
-
3. This time, I wrote the whole line, highlighted it, then pressed the button.
Since there is no preview, I can’t tell before hitting submit if these will work. Before hitting submit, all three look like valid html.
(EDIT) After hitting submit, *none* of them look underlined. :^|
(2ND EDIT) While the actual link button has an underline, the actual UL button does not. So I guess UL works the way they designed it. 🙂 🙂Tom
I’d like to have the offending gcode myself. But when it happened, I was more worried about solving the problem, and continued playing with settings in CamBam until I got it to work sufficiently. That over wrote my gcode with something that worked. Sorry.
In CamBam, I slightly adjust depth increment and stepover, which don’t change the finished product, just the way it routes.
I know that is no help. Sorry about that. When it happens, I just see red and work the problem.
