Riley

Zach,

That is a new one. I suspect that there is something going wrong on your build process. However in the spirit of getting you and tom cutting on edge I am going to post a link to the “working” edge. I say “working” because it is EDGE! So this is going to be a release but for now its still being tested. So warnings and all that aside try this link out.

I have ZIPPED it so there should be NO ISSUES with windows vs linux vs OSX.

So try this.
https://www.dropbox.com/sh/jyegsvudnhp9w0o/qbvJCmpTis

Also note that we are working (as Alden said) on getting the bin files put up on a more obvious page.

If you find bugs please open “issues” on github here:
https://github.com/synthetos/TinyG/issues

Thanks and let us know how it goes!
ril3y

Tom,

I am beginning to see a trend here. You make a post.. You say I was doing ‘xyz’ and TinyG ruined my work and you are mad. I have replied to you in previous a previous post to email and we can setup a call to help you though your issues.

You did not respond. You continue to blast the project and forum with your “issues” then never provide anything to help us replicate your problems. Frankly, its quite old.

So here is what you can do. You can provide USEFUL information on how to replicate this “bug” or “error” you claim to be seeing. Or you can continue your rants and be ignored.

What are you using to send gcode files? Are you setting flow control?
Since I think you are using coolterm to send files, did you follow this?
https://github.com/synthetos/TinyG/wiki/TinyG-Sending-Files-with-CoolTerm

tgFX does not support the edge branch right now. I am working on this today to fix this.

What gcode files are you sending? What firmware build number are you running?

As far as this issue above goes. I had a similar problem with a PCB mill running a cheap Chinese spindle. The spindle was so noisy that it was casing TinyG and the usb signals to get all garbled. If you have a scope you might was to take a look. I also would suggest you move your spindle cables away from your motors / control lines. I ended up using a computer UPS as a “filter” and it worked after that. Also if you run the job without the spindle on (a dry run) do you get these same errors?

riley

Hi Riley,
The x64 is useless and very buggy. The x84 is ok but can be launced only randomly on my Toshiba Laptop running win7 Ultimate. TinyG DOES NOT echo anyting when connected. Jog using arrows and + /= only work sometimes.

The x64 was removed. Use 32bit.

tgFX always come up with metric and if one forgets to set the units to inches everytime tgFX is started there job is lost. G20/21 does not seem to help(?) Many missing steps and sometimes misses line of gcode!

tgFX does not come up as “metric” or “inches” your default unit mode that is set on TinyG does this. tgFX just reads it back.

Velocity or FR display doesn’t always follow gcode.
When Motor1 & 2 are run together, the Velocity value is some different number

This does not give me enough information to help you. However I ASSUME you mean, when you run x and y (motor 1 and 2) together (and they contain the same velocity movement) then your velocity does something a bit more than what you expected? This is correct. Short answer think of the hypotenuse of a triangle. Alden can explain more on that side.

There can be a screen size configuration.
Any info from Synthetos ALWAYS show OSX screen and setup (https://github.com/synthetos/tgFX, for example).

Would be nice to have a scolling gcode to show which line is being used.

Had this.. Ditched it.. It lagged older systems badly. This was a javaFX issue

I am using TinyG v8 and the latest binary for tgFX.

Thanks for all the help!

Gopal

The arrow has to be at the bottom edge of the top selection boxes to be active.

Not sure of the context on this comment.

AHHA! Don’t hurt yourself. Good to hear its working!

Riley

I have been working on getting in app firmware working with the XMEGA and the Arduino DUE port of TinyG. I also have been working on getting the DUE to work with tgfX ( subtle differences in hardware ).

I pushed some new code tonight. So yah still working on it. So much to do so little time!

Riley

Good point alden.

@tim,

Wow that really sucks that the 115200 is not “reliable”. I would suggest you play with the baudrates. I for one have not tried other rates really. If you experience something “off” or “weird” let us know. I would also say to try to set your $si=250 or so to test it out.

ril3y

This is my fault. This occurs when you initially flash your firmware (via a AVR programmer not the bootloader) and you power off TinyG before the “defaults” have been set in the EEPROM.

$defa=1 will fix this issue. Luckily I figured this out and re-did most of the boards. However a few like yours slipped though before I realized this.

Sorry guys,

Riley

When you plug in your programmer it issues a reset. Simple enough. Its not dangerous just don’t do it while doing something or you will lose 🙂

TO BE CLEAR:
!!!!!
!!!!!
!!WE DO NOT HAVE AN EMERGENCY STOP!!

Pretty dramatic but its true. A E stop is only implemented via a physical power disconnect (speaking on behalf of Synthetos). We provide some software stop’s / resets but its not an E stop. I just want to make that point clear so you don’t cut off your fingers because of a bug I might introduce in the future 🙂

ril3y