[Emc-users] Interp problems?

[dave]

Hi all,

I recently switched from a Duron 1200 that has been running for years to
a MW525.
I thought by this time several problems would have been fixed.
I'm still using tklinuxcnc but have plans to shift to gmocapy. I love
the features in axis but do not
interface well with the UI.

***@linuxcnc:~$ uname -a
Linux linuxcnc 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc
i686 i686 i386 GNU/Linux

a. to work reliably on startup G40 must be on a line by itself. The only
time this is a real problem is
when I am using hand written code and it quits of get canceled before
the G40. I don't know if this
is a gui problem or can be traced back to the interp.

b. The offsets are usually correct but the offset number often doesn't
display correctly.
It can display G54 but the offsets are for G55 and the program runs
correctly.
Once in a while no matter what I do the program cannot invoke either the
offsets or the correct
offset number.

c. minor but annoying ... in mdi I get an error message "cannot open
<filename>.

d. I've done no configuration in terms of isolcpu, etc. and occasionally
get cycle time violations. It is
my understanding that rtai doesn't need it.

Sorry to dump on you but things have finally gotten to the point where I
can't do any machining.

"b" has me completely stalled.

Gentle help would be appreciated.

Dave


ps. In desperation I would try axis (again) but clicking on the sample
configurations doesn't fill in the tree.

'a' and 'b' existed with the Duron also but I've never been this stalled.

[Jon Elson]

Post by dave
ps. In desperation I would try axis (again) but clicking
on the sample configurations doesn't fill in the tree.
'a' and 'b' existed with the Duron also but I've never
been this stalled.

Pick any config that you like, and open the xxx.ini file in
an editor.
in section [DISPLAY]
change the line DISPLAY = <something>
to
DISPLAY = axis

This should be the only thing you need to change to switch
between GUIs, as long as they don't use any exotic features
like virtual control panels.

Jon

[dave]

Post by dave
ps. In desperation I would try axis (again) but clicking on the
sample configurations doesn't fill in the tree.
'a' and 'b' existed with the Duron also but I've never been this stalled.

Pick any config that you like, and open the xxx.ini file in an editor.
in section [DISPLAY]
change the line DISPLAY = <something>
to
DISPLAY = axis
This should be the only thing you need to change to switch between
GUIs, as long as they don't use any exotic features like virtual
control panels.
Jon

Thanks Jon,
Tried that earlier in the day and didn't get anything.
Just tried it again and what to my wondering eyes ... axis. :-)
Still struggling with the interface but it seems to be giving me the
same errors as tk.
I can't quite figure out how I can be in the middle of the bed .... with
a small part and still
get limit violations. I suspect it is heat. The heat sink was maybe 120
F. Before I go too much farther
I will rig a fan.

Bit by bit ( maybe ) we'll get sorted.

Dave

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[andy pugh]

can't quite figure out how I can be in the middle of the bed .... with a
small part and still
get limit violations

Is this actual limit-switch trips. or warnings that the G-code exceeds
machine limits?

The first is probably electrical noise. I seem to always end up with a
software low-pass on those signals, just because false-trips are so
annoying and a couple of mS delay in responding to a limit switch isn't
that critical.

If it is the second, then you might need to have a look at your coordinate
system offsets.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?CoordinateSystems#So_if_you_re_lost_what_should_you_do

[dave]

Post by andy pugh

can't quite figure out how I can be in the middle of the bed .... with a
small part and still
get limit violations

Is this actual limit-switch trips. or warnings that the G-code exceeds
machine limits?
The first is probably electrical noise. I seem to always end up with a
software low-pass on those signals, just because false-trips are so
annoying and a couple of mS delay in responding to a limit switch isn't
that critical.
If it is the second, then you might need to have a look at your coordinate
system offsets.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?CoordinateSystems#So_if_you_re_lost_what_should_you_do

.....warning: gcode exceeds machine limits. I classically set my limits
at -.2 ..18, -.2, ..9 and 0 ... -3.
Moving to -9 ... 9, -4 ... 4 for x and y and it still gave me the same
error message. .... and yes I shutdown linuxcnc and restarted homing on
the center of the bed.

I suspect that this is a thermal problem ... small fan blowing across
the mb. Next step is to rig a
so-called 'whisper' fan off an 11/40. Can you believe they have a
100,000 hrs on them.
Temp is 55 this morn so I'm blowing cool air into the shop. :-)

One issue at a time...

Tnx

Dave

[jeremy youngs]

All machine move offs should be in the negative direction. I.e. I believe
you have your scales backwards. There was an illustration pinned in the
forum about this

Post by dave

can't quite figure out how I can be in the middle of the bed .... with a

Post by dave
small part and still
get limit violations
Is this actual limit-switch trips. or warnings that the G-code exceeds

machine limits?
The first is probably electrical noise. I seem to always end up with a
software low-pass on those signals, just because false-trips are so
annoying and a couple of mS delay in responding to a limit switch isn't
that critical.
If it is the second, then you might need to have a look at your coordinate
system offsets.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?CoordinateSystems#S
o_if_you_re_lost_what_should_you_do
.....warning: gcode exceeds machine limits. I classically set my limits

at -.2 ..18, -.2, ..9 and 0 ... -3.
Moving to -9 ... 9, -4 ... 4 for x and y and it still gave me the same
error message. .... and yes I shutdown linuxcnc and restarted homing on the
center of the bed.
I suspect that this is a thermal problem ... small fan blowing across the
mb. Next step is to rig a
so-called 'whisper' fan off an 11/40. Can you believe they have a 100,000
hrs on them.
Temp is 55 this morn so I'm blowing cool air into the shop. :-)
One issue at a time...
Tnx
Dave
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[dave]

Post by dave

Post by andy pugh

can't quite figure out how I can be in the middle of the bed .... with a
small part and still
get limit violations

Is this actual limit-switch trips. or warnings that the G-code exceeds
machine limits?
The first is probably electrical noise. I seem to always end up with a
software low-pass on those signals, just because false-trips are so
annoying and a couple of mS delay in responding to a limit switch isn't
that critical.
If it is the second, then you might need to have a look at your coordinate
system offsets.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?CoordinateSystems#So_if_you_re_lost_what_should_you_do

.....warning: gcode exceeds machine limits. I classically set my
limits at -.2 ..18, -.2, ..9 and 0 ... -3.
Moving to -9 ... 9, -4 ... 4 for x and y and it still gave me the
same error message. .... and yes I shutdown linuxcnc and restarted
homing on the center of the bed.
I suspect that this is a thermal problem ... small fan blowing across
the mb. Next step is to rig a
so-called 'whisper' fan off an 11/40. Can you believe they have a
100,000 hrs on them.
Temp is 55 this morn so I'm blowing cool air into the shop. :-)
One issue at a time...
Tnx
Dave

Having cooled off the shop a bit the limits violation seems to have
gone away for now. We'll see
what later in the day brings. BTW the limit violations were consistent
between axis and tklinuxcnc.

Multiple passes thru a small routine show progressive x offset with each
iteration. :-(
Dial indicator on X is clean in one direction but not the other which
usually indicates a broken
coupler to the encoder. I'll have to tear into the housing to verify
that. Shift is about a cm for
each pass of a pocketing routine. Same shift pattern as another routine
to inlet a tang on a stock.

Bird walking a bit .... my Z axis encoder is driven off a small timing
pulley that couples the
encoder to the servo drive belt. ~100K counts/in. I'm thinking the same
thing could be used
for the X and eliminate the coupler and make access easier.

Stay tuned we'll sort this out yet with help.

Dave

Post by dave
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

Post by dave
Having cooled off the shop a bit the limits violation
seems to have gone away for now. We'll see
what later in the day brings. BTW the limit violations
were consistent between axis and tklinuxcnc.
Multiple passes thru a small routine show progressive x
offset with each iteration. :-(
Dial indicator on X is clean in one direction but not the
other which usually indicates a broken
coupler to the encoder. I'll have to tear into the housing
to verify that. Shift is about a cm for
each pass of a pocketing routine. Same shift pattern as
another routine to inlet a tang on a stock.

Well, could be a marginal encoder that is reporting more
counts in one direction than the other.
That COULD be affected by heat. Or, the encoder counter
could be missing counts.

Jon

[dave]

Post by dave
Having cooled off the shop a bit the limits violation seems to have
gone away for now. We'll see
what later in the day brings. BTW the limit violations were
consistent between axis and tklinuxcnc.
Multiple passes thru a small routine show progressive x offset with
each iteration. :-(
Dial indicator on X is clean in one direction but not the other which
usually indicates a broken
coupler to the encoder. I'll have to tear into the housing to verify
that. Shift is about a cm for
each pass of a pocketing routine. Same shift pattern as another
routine to inlet a tang on a stock.

Well, could be a marginal encoder that is reporting more counts in one
direction than the other.
That COULD be affected by heat. Or, the encoder counter could be
missing counts.
Jon

I've unmounted the encoder and the coupling was not broken so that
leaves connections/cabling or
a failed encoder. This is the first summer with this cpu. The old Duron
1200 would go on strike when
the shop got too warm.
Much more to verify .........

Dave

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

Post by dave
.....warning: gcode exceeds machine limits. I classically
set my limits at -.2 ..18, -.2, ..9 and 0 ... -3.
Moving to -9 ... 9, -4 ... 4 for x and y and it still
gave me the same error message. .... and yes I shutdown
linuxcnc and restarted homing on the center of the bed.

I can't POSSIBLY see how temperature could affect soft
limits, which is what your message describes. The only way
this could happen is computer malfunction or homing to a
different spot than was intended for home.

[dave]

Post by dave
.....warning: gcode exceeds machine limits. I classically set my
limits at -.2 ..18, -.2, ..9 and 0 ... -3.
Moving to -9 ... 9, -4 ... 4 for x and y and it still gave me the
same error message. .... and yes I shutdown linuxcnc and restarted
homing on the center of the bed.

I can't POSSIBLY see how temperature could affect soft limits, which
is what your message describes. The only way this could happen is
computer malfunction or homing to a different spot than was intended
for home.

For right now I suspect cpu temp.
Homing is manual and I know rather well where each axis is when I home.
Lots of things to look at...........

Dave

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[andy pugh]

Post by dave
For right now I suspect cpu temp.
Homing is manual

Are you sure that you are doing this right?

If you jog to your manual home position and re-home, does the problem go
away?

[dave]

Post by andy pugh

Post by dave
For right now I suspect cpu temp.
Homing is manual

Are you sure that you are doing this right?
If you jog to your manual home position and re-home, does the problem go
away?

I've lost the thread ....
As of this morning .... cooler weather the limits violation went away.
The shift in G55 didn't disappear every loop through a pocket shifted
about 1 cm.
Current tack is to replace the X encoder and see if that fixes things.
Time will tell.
It might be a couple of days before I get things settled again.
Keep poking, we'll get this sorted yet.

Dave

Rehome, exit Tk... , etc, do a total shutdown and boot, no joy.

[andy pugh]

Post by dave
The shift in G55 didn't disappear every loop through a pocket shifted
about 1 cm.

Is the machine absolute position shifting? ie, if you set your display to
"machine coordinates" and jog to the home position, does it show the right
values?

I can't see how even a dodgy encoder can move the soft limits. (which seems
to be the reported problem)

How do you home? Are you confusing homing with touching-off?

[dave]

Post by andy pugh

Post by dave
The shift in G55 didn't disappear every loop through a pocket shifted
about 1 cm.

Is the machine absolute position shifting? ie, if you set your display to
"machine coordinates" and jog to the home position, does it show the right
values?
I can't see how even a dodgy encoder can move the soft limits. (which seems
to be the reported problem)
How do you home? Are you confusing homing with touching-off?

As I said in a previous post. I posted too many questions in one post.
Keeping them sorted in replies
is a problem. The encoder is one problem and the out of limits is
another. Cooling off the shop
seems to have cured the limits problem ... for now.

I'm homing in the easiest manner possible; Move all axes to machine
(mechanical) zero and click mouse.
Not that it makes any real difference but my 0,0,0 (G54) is lower left
for X,Y and spindle all the way up, Some people home to mechanical
center of bed; and I've actually heard of
people homing to upper right corner. I just don't think that way.

How do you home? Are you confusing homing with touching-off?

I hope not! Home to G54. Touch off for G55...59.3.

As for the thermal problem: right now I'm blowing cool air ( 20 C ) into
the shop.

Dave

[andy pugh]

Post by dave
I'm homing in the easiest manner possible; Move all axes to machine
(mechanical) zero and click mouse.

What are you clicking with the mouse?

[dave]

Post by andy pugh

Post by dave
I'm homing in the easiest manner possible; Move all axes to machine
(mechanical) zero and click mouse.

What are you clicking with the mouse?

yes.

[andy pugh]

Post by dave
I'm homing in the easiest manner possible; Move all axes to machine

Post by dave
(mechanical) zero and click mouse.

What are you clicking with the mouse?
yes.

What on-screen control are you clicking with the mouse?

[dave]

Post by andy pugh

Post by dave
I'm homing in the easiest manner possible; Move all axes to machine

Post by dave
(mechanical) zero and click mouse.

What are you clicking with the mouse?
yes.

What on-screen control are you clicking with the mouse?

"home" carefully nestled between the - and + jog buttons.
Now you have me curious; not certain where you are headed.

Dave

[andy pugh]

Post by dave
"home" carefully nestled between the - and + jog buttons.
Now you have me curious; not certain where you are headed.

Curious that you don't have a "home all" button, but where I was heading
was that if you had been using "touch off" to zero the axes on a machine
with NO_FORCE_HOMING configured then an incremental step towards one or
other soft limit is likely.

Is G53 moving?

[dave]

Post by andy pugh

Post by dave
"home" carefully nestled between the - and + jog buttons.
Now you have me curious; not certain where you are headed.

Curious that you don't have a "home all" button, but where I was heading
was that if you had been using "touch off" to zero the axes on a machine
with NO_FORCE_HOMING configured then an incremental step towards one or
other soft limit is likely.
Is G53 moving?

Opps! Didn't think to check. Darned!
I suspect so. My standard end of program goes:
G53G0Z0
G53G0X0Y7.5 ( to move out of the way of the tool)
G54G90
M2

and IIRC X was considerable displaced in the + direction.

Lets put this all on hold and see how things shake out with a new
encoder in place and hopefully
cooler temps. Tomorrow is supposed to be low 80's so about 10 degrees
cooler. :-)

Dave

[dave]

Post by dave

Post by andy pugh

Post by dave
"home" carefully nestled between the - and + jog buttons.
Now you have me curious; not certain where you are headed.

Curious that you don't have a "home all" button, but where I was heading
was that if you had been using "touch off" to zero the axes on a machine
with NO_FORCE_HOMING configured then an incremental step towards one or
other soft limit is likely.
Is G53 moving?

Opps! Didn't think to check. Darned!
G53G0Z0
G53G0X0Y7.5 ( to move out of the way of the tool)
G54G90
M2
and IIRC X was considerable displaced in the + direction.
Lets put this all on hold and see how things shake out with a new
encoder in place and hopefully
cooler temps. Tomorrow is supposed to be low 80's so about 10 degrees
cooler. :-)
Dave

UPDATE:
Just installed a replacement 2500 ppr encoder and motion is solid
and makes sense. Cut the
same test pocket and it looks nice and doesn't shift X between z
layers.

As for the zero shift it is OK for now; 100 degree weather due next
week so between now and then
I need to get a decent cooling fan in place for testing if things go
south again.

Thanks for all the thoughtful ideas and help. We'll see what warmer
weather brings. Stay tuned.
Only hit 87 today.

Dave

Post by dave
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[dave]

Post by dave
.....warning: gcode exceeds machine limits. I classically set my
limits at -.2 ..18, -.2, ..9 and 0 ... -3.
Moving to -9 ... 9, -4 ... 4 for x and y and it still gave me the
same error message. .... and yes I shutdown linuxcnc and restarted
homing on the center of the bed.

I can't POSSIBLY see how temperature could affect soft limits, which
is what your message describes. The only way this could happen is
computer malfunction or homing to a different spot than was intended
for home.

Hi Jon,
After getting the new encoder installed and checked out I went looking
for a way to monitor cpu
temp.
So far, less than 50% of max... max is defined a 100 C. Temp in the shop
today was 93. We'll see what next week brings. Anyway, so far so good.
Hard to believe that the goofy encoder could have induced that behavior
but....
Time will tell.

dave

[Jon Elson]

Post by dave

Post by Jon Elson

Post by dave
.....warning: gcode exceeds machine limits. I
classically set my limits at -.2 ..18, -.2, ..9 and 0
... -3.
Moving to -9 ... 9, -4 ... 4 for x and y and it still
gave me the same error message. .... and yes I shutdown
linuxcnc and restarted homing on the center of the bed.

I can't POSSIBLY see how temperature could affect soft
limits, which is what your message describes. The only
way this could happen is computer malfunction or homing
to a different spot than was intended for home.

Hi Jon,
After getting the new encoder installed and checked out I
went looking for a way to monitor cpu
temp.
So far, less than 50% of max... max is defined a 100 C.
Temp in the shop today was 93. We'll see what next week
brings. Anyway, so far so good.
Hard to believe that the goofy encoder could have induced
that behavior but....

Some systems have the temp sensing diode in the CPU hooked
up. There is a package called lm_sensors. After installing,
run sensors-detect to configure it, then just type "sensors"
to get a temp readout.

Yes, I have seen a number of encoders that were on the brink
of failure start doing strange things just before they died.

Jon

[dave]

Post by dave

Post by dave
.....warning: gcode exceeds machine limits. I classically set my
limits at -.2 ..18, -.2, ..9 and 0 ... -3.
Moving to -9 ... 9, -4 ... 4 for x and y and it still gave me the
same error message. .... and yes I shutdown linuxcnc and restarted
homing on the center of the bed.

I can't POSSIBLY see how temperature could affect soft limits, which
is what your message describes. The only way this could happen is
computer malfunction or homing to a different spot than was intended
for home.

Hi Jon,
After getting the new encoder installed and checked out I went
looking for a way to monitor cpu
temp.
So far, less than 50% of max... max is defined a 100 C. Temp in the
shop today was 93. We'll see what next week brings. Anyway, so far so
good.
Hard to believe that the goofy encoder could have induced that
behavior but....

Some systems have the temp sensing diode in the CPU hooked up. There
is a package called lm_sensors. After installing, run sensors-detect
to configure it, then just type "sensors" to get a temp readout.
Yes, I have seen a number of encoders that were on the brink of
failure start doing strange things just before they died.
Jon

As good a theory as any until someone has an epiphany.
Yep! lm_sensors is what I used.

Dave

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[andy pugh]

Post by dave
I suspect that this is a thermal problem

Whereas I consider the idea that it is a _Computer_ thermal problem almost
inconceivable.

[Jon Elson]

Post by andy pugh

Post by dave
I suspect that this is a thermal problem

Whereas I consider the idea that it is a _Computer_ thermal problem almost
inconceivable.

Yes, for a CPU to foul up ONLY the counting of one axis in
ONE direction seems implausible. I'm guessing possibly a
weak encoder that is losing counts when hot. I'd also check
the power supply to the encoder as close to the encoder as
it is available.

I did have a problem with my mill some years ago. I did a
couple things wrong on one job and didn't notice the hole
spacing was off until the parts were used. One error was I
didn't spot the holes, I just drilled them with jobber's
length drills, so all bets on accuracy would be off,
anyway. But, the holes were too widely spaced. Hmmm, many
errors in the machine would cause the holes to be too CLOSE
together. Then, I noticed the spindle speed display was
fluctuating. I started to investigate. On my PPMC system,
the encoder board powers the encoders through the encoder
connector.
I saw that the encoders had about 4.0 V where it should have
been 5.0 +/- 5% or so. The main DC connector to the PPMC
motherboard was making a poor contact, and the whole PPMC
system was running on about 4.1 V! Amazing that it even
worked at all, as that was WAY outside the VCC spec for all
the chips. Once I wiggled the connector, everything
returned to normal.

So, the error was due to one encoder losing counts, so the
machine moved farther than it should have. It was pretty
repeatable, so the error did not accumulate.

Jon

[dave]

Post by andy pugh

Post by dave
I suspect that this is a thermal problem

Whereas I consider the idea that it is a _Computer_ thermal problem almost
inconceivable.

Yes, for a CPU to foul up ONLY the counting of one axis in ONE
direction seems implausible. I'm guessing possibly a weak encoder
that is losing counts when hot. I'd also check the power supply to
the encoder as close to the encoder as it is available.
I did have a problem with my mill some years ago. I did a couple
things wrong on one job and didn't notice the hole spacing was off
until the parts were used. One error was I didn't spot the holes, I
just drilled them with jobber's length drills, so all bets on accuracy
would be off, anyway. But, the holes were too widely spaced. Hmmm,
many errors in the machine would cause the holes to be too CLOSE
together. Then, I noticed the spindle speed display was fluctuating.
I started to investigate. On my PPMC system, the encoder board powers
the encoders through the encoder connector.
I saw that the encoders had about 4.0 V where it should have been 5.0
+/- 5% or so. The main DC connector to the PPMC motherboard was
making a poor contact, and the whole PPMC system was running on about
4.1 V! Amazing that it even worked at all, as that was WAY outside
the VCC spec for all the chips. Once I wiggled the connector,
everything returned to normal.
So, the error was due to one encoder losing counts, so the machine
moved farther than it should have. It was pretty repeatable, so the
error did not accumulate.
Jon

"Yes, for a CPU to foul up ONLY the counting of one axis in ONE
direction seems implausible."

I agree!

We have two separate issues. In my original post I listed too many
problems which leads to context confusion when replying.
The thermal issue is in reference to the out of limits when the part was
clearly in the middle of the workspace. The machine simply didn't know
where it was.

I suspected the shifting axis issue was a broken helicoil; it has
happened before. Not in this case...
I dismounted the encoder and old fumble finger dropped the mounting
assembly. One encoder ruined.
I did find a break in the encoder connection on the A+ channel so that
explains the shifting.
Will install a new encoder today so one problem should disappear.

Re': ppmc. The whole connector system was weak. IIRC I soldered the
power connections and that
fixed that! Also I constructed a solid Al bracket for the data
connector. Once it was bolted down I never had another problem...rock
solid. I could run the communication diagnostic for hours or days
without an error.
Back to the soldering station...........

Dave

[Jon Elson]

Post by dave
Thanks Jon,
Tried that earlier in the day and didn't get anything.
Just tried it again and what to my wondering eyes ...
axis. :-)
Still struggling with the interface but it seems to be
giving me the same errors as tk.
I can't quite figure out how I can be in the middle of the
bed .... with a small part and still
get limit violations.

These are soft limit errors, or limit switch tripped
errors? Soft limit errors will manifest when you try to jog
past them, the machine will just stop with no explanation.
A limit switched tripped will raise a red warning message on
the screen.
If you are getting limit switch tripped conditions, then you
may have a problem with flaky wiring, or insufficient
pull-up or whatever on the digital inputs. If soft limits,
then you need to check that homing is working right, and
that the right numbers have been given for MIN_LIMIT and
MAX_LIMIT for each axis.

Post by dave
I suspect it is heat. The heat sink was maybe 120 F.
Before I go too much farther
I will rig a fan.

If you are getting FOLLOWING error limits, then the axis is
not following the commanded position accurately.

Jon