cmcgrath5035

Your question is somewhat unclear.

Are the Allegro A3977s on a unique shield board?
Or are they assembled onto a Gshield pwb?
Or are you working with them on a prototype board?

Does the A3977 interface with 3.3V logic?

Great to hear you are up and running.

I am curious, though, about anything having to do with Java helping.
Chilipeppr is all JavaScript, not Java.

Browser (what do you use, Chrome?) of course supports Java. Perhaps by allocating more to Java directly, the browser has to provide less?

Anyway, happy milling!

Is changing the firmware a big deal?

You would be on your own to make such a change.
Have you reviewed and well understood the existing code base?

What does foam works normally interface with?

My guess would be it would be non-trivial, but do-able.

Screw machine, I presume?

Do you have a Axis?
If not, I suggest set $4pm=0 to disable it.

If you get a chance – please switch to mm mode when dumping $$
TinyG is native mm, highly recommended that you enter parameters in mm.
I keep a few comparison files around and use diff to compare too user files – helps separate the needles from the hay.

It is not clear to me if all your testing in the big paragraph above was CP or a mix.
There are some practical limits on size of file that can be loaded into CP.
I don’t have much experience there.

did you reset your jog distance after switching units?
A jog of 0.1 is units agnostic, it will jog 0.1″ in inch mode, 0.1 mm in mm mode.

Sounds like you are on the path to success

Have you dug into this section of the wiki?

https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#axis-settings

I believe, with the correct parameter settings, A rotational can be used to create linear motion.

I suppose you may need to research what Foram Works expects of A.

Interesting.

My interpretation of what you write is somewhat different than yours.
AFAIK, there are 2 correct ways to set a zero
1. A hard or commanded tinyG reset
2. A Gcode sequence, such as G28.x
To that list I suppose we have to add the possibility of a major tinyG barf while interpreting G code that has similar effect to #2.
A #1. event would be obvious, I think, due to flashing LEDs and startup messages issued to the upstream channel, which you do not see.

I believe there is a way for CoolTerm to T the upstream response into a file, so you could scroll thru it and see where the change to zero position occurred. Have you tried that?
I find it difficult to comprehend a #2 event, intentional or barf, that would not be revealed in status messages.

What generates your Gcode?
Did you make manual ‘enhancements’ ?

RTS/CTS flow control is probably the most reliable of the two.

Have you ever tried Chilipeppr?
It implements a closed loop flow control and command aduit mechanism that might be helpful debugging here.

• This reply was modified 8 years, 10 months ago by cmcgrath5035.

Here are a few somewhat random questions in an attempt to narrow the universe of possible areas for investigation.

Can you better describe “zero reset”?, Does the job come to a halt, reporting that it is now at position (0,0)? Does it behave as if a Gcode command caused the new position, or does it look like the FW crashes and causes tinyG to hard reset, which would set a new zero at that location?

Does the reset event occur at the same location in the Gcode file, or is it random?

If it appears to be a random hard reset, any reason to suspect power droop or similar?

What Flow control ar you using between CoolTerm and TinyG (RTS, Xoff, …)?

Are you monitoring tinyG status messages? Are they revealing any useful info?

I’ll pause there.

I am not sure I understand your target environment, specifically what would Gcode call a fourth Linear axis?
I am not aware of a four linear motion dialect of Gcode, but perhaps only because I have not gone looking.
Each motor can be assigned to linear motion, but there are only 3 linear directions, as far as I am aware.