Riley

Hey Spark,

I see you are using coolterm? Did you try tgFX? I will have an OXS new “edge” build out tonight? (i hope) that you can test. However, I am curious as I do a different method of sending files rather than just using RTS. I use RTS + count bytes. Its not ideal and I will update this to use qr’s as well. However I would be very interested to see if you still experience this same issue in tgFX.

ril3y

Flux and Grath,

Lots of good stuff here! Flux, could you add your code to the “sending gcode files” on the wiki?
https://github.com/synthetos/TinyG/wiki/TinyG-Sending-Files

Alden/rob/I have been swamped over the past few days. I promise we will look at this. We hear you! I am sorry tgFX did not work in Linux for you. I am very much looking forward to playing with your code too!

Grath you are a machine! Thanks for the help in replicating this issue.

As far as dev goes.. ALL BETS ARE OFF 🙂 That being said here is the “official” game plan. I am getting tgFX stable with “412.01”, then we are going to push forward 412.02 as master as there are a few changes from there.

Just an FYI.

I did post a windows bin for the newest tgFX. I will post a new thread there too. I could use some help testing it out. It should address a few of your gripes too grath.

Ril3y

Ok this is weird indeed. My first thought would be to restore all config values to default. Lets see your config and see if I can replicate it.

ril3y

Dj0nes,

What is your zaxis issues? I want to be clear we are dealing with the same thing?

Hey guys,

Sorry been a bit busy this week. Hopefully this weekend I can put some new code up. First off thanks to everyone helping out on this thread! I read it and cringe a bit. “you have to do x to y and then jump and close your eyes” to get this to work. I am sorry about this 🙂

The zooming and machines with large max travel values are HORRIBLE! On my 4ft x 2ft. cnc I put it at 300mm x 300m so I can at least see!
I realize that is not a great solution.

I would very much like to see your “cam file sender” also you should put it on the wiki.
https://github.com/synthetos/TinyG/wiki/TinyG-Sending-Files

As for the uninstaller. I have muddied the water by releasing zip files and exe files. If you used an “installer” remove it before you use another exe installer. There should be a uninstaller in the windows program files for tinyg. If anyone is going to be around this weekend I am going to try to push out some new experimental builds. I have taken on a few design issues that people were complaining about. Also I am trying to fix the jogging bug where it changes tabs. I think there also is a bug when sending files that sometimes a line is skipped? Which can be pretty bad if its say pickup the Z axis from the work. Has anyone else seen this? Wow I am really off topic. Sorry guys.

Thanks!

ril3y

So one thing you can do to see if this is indeed tgFX or TinyG issue is run this in coolterm.

So just make sure you select RTS and connect then send file and stand back 🙂
This will for sure give me some data to get this one tracked down!

Can you post this file too? I love the design very cool stuff indeed.

ril3y

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?

TinyG/CoolTerm crashing NOT solved

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.

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

TinyG source is open source. We also provide the schematics. TinyG hardware is not OSH.