alden

You might be referring to feed rate overrides – allows adjusting a job speed up and down during runtime. This is on the list but there are a few other things to get working first.

By the way, I got some of those Automation Technology 425 oz-in NEMA 23 motors in you found. Really nice. Here’s a video:

http://www.flickr.com/photos/rileyporter/9959403684

• This reply was modified 11 years, 1 month ago by alden.
• This reply was modified 11 years, 1 month ago by alden.
• This reply was modified 11 years, 1 month ago by alden.
• This reply was modified 11 years, 1 month ago by alden.
• This reply was modified 11 years, 1 month ago by alden.

I think it’s dicey. Those signals are driven by output lines on the Xmega. These are 3.3v outputs and won’t be happy about 5v, so avoid that. Electrically you will see 2 output stages fighting with each other, so the Mach3-sourced signals will have to win (drive the Xmega lines low).

One possibility would be to hack the Xmega code so those lines are inputs – i.e. disconnected. THat should work better.

It’s really up to you if you want to try it. If so be sure not to send more than about 3v into the board.

We think there’s a bug introduced in 380.05 where on connection if the terminal does not assert RTS the command does not get to TinyG (does not connect). The earlier versions of tgFX did not assert RTS, whereas Coolterm does. This explains why it will connect to Coolterm but not tgFX.

We have done 2 things. (1) tgFX version 2072 asserts RTS. Right now only the Win32 binary does this. Once this is tested others will be posted as well.

(2) A patch has been added to the edge branch (build 380.06) that allows a terminal to connect without asserting RTS if TinyG’s flow control is either OFF ($ex=0) or set to XON ($ex=1). Also, the default flow control setting has been set to XON. If flow control is then set to RTS ($ex=2) then RTS still needs to be asserted because that’s the way RTS/CTS flow control is supposed to work.

Build 380.06 is in test in the edge branch now. We will test tonight or tomorrow and push this to master assuming tests are OK.

@sjhan12: This should fix the behavior you are seeing in your own application. Try out 380.06 from edge.

Thanks. I’m traveling this week but should be able to test it out at the end of the week or over the weekend. Can you please also include the Gcode that failed? I’d like to try to run it. Thanks.

Cool stuff. A couple of things to note:

– It is possible that a status report can be skipped. This is normal and by design. The system will not report more frequently than the status interval: {“si”:250} for example. This is to manage the load on the serial line in heavy traffic. You will not miss any events as all changes are reported, but things like line numbers, velocity, position might “skip ahead”.

– You might want to consider setting your footer depth variable (fd) to 0. This makes the JSON footer a peer of the response, and sets up for future developments where things other than ‘r’s will return with footers. We left the fd=1 setting in so as not to break legacy parsers, but if you are doing this new I’d recommend using fd=0

InPhase – thanks for your comments,and sorry you are having problems. TgFX still needs some shakeout and the new binaries need to get posted. Hopefully we’ll get through this hiccup. THanks for your patience, and I understand if you can’t integrate into a production environment until these things are taken care of.