[PapstDFrisco]

Hi All,

I have a recent phenomenon, when running a g-code program, my axes stop moving.
I would say that it happens randomly, but it does seem to happen in certain areas of the g-code within a program.

If the move is in the middle of a program, I get a "Unexpected Motion Buffer Starved" dialog popup - then status of
Emergency Reset with Dynomotion Status: Y Axis Disabled.
In this case the x-axis is the only one moving when it stops.
The result for this case is the x-axis 'chirping and the motor oscillates / bounces slightly with each chirp.

In the second case it is the last move in the program so I don't get the motion buffer starved dialog.\
I do get the Emergency Reset with Dynomotion Status: Y Axis Disabled.
The result for this case is the x-axis 'chirping and the motor moves forward slightly with each chirp.

I have attached pictures of the screens.
I have taken video but they are too large to upload in my opinion ( 3M & 6M in size).
I can forward these if needed.

My understanding is that the main fault for the drive (SnapAmp) is over current.
I have tried de-tuning the axes - reducing the V,I,J settings to reduce the current peaks - this has had no
apparent effect. Verified that it did reduce the current via K-motion step response curves.

I hope someone has an idea of what could be causing this - as the system has been working for some time
without this happening. To my knowledge, nothing has changed - I definitely have not changed the firmware
or Mach3.

Thanks in advance for the ideas / assistance.
Matt

Crash 1 pics:
Status
Attachment 230456
g-code
Attachment 230458
Crash 2 pics
Status A
Attachment 230460
Status B
Attachment 230462
g-code
Attachment 230464

the g-code file is also attached - it's basically a 2d pocket - simple stuff

[TomKerekes]

Hi PapstDFrisco,

Not sure what that might be. I think a first step would be to try running KMotion.exe at the same time and see if a reason for the Y being disabled is displayed on the Console Screen. It might be something like a following error or limit switch (noise). What is your max following error setting?

I suspect the Current Fault LED on SnapAmp is illuminated. Its hard to say if that was the root cause or a result of something else. Usually if something happens that results in a large following error then when the current fault attempts to re-enable it immediately generates another current fault so it just keeps cycling until the system is re-initialized.

What Version of KMotion are you running? Please use V4.31 as it may have better error messages.

Regards

[PapstDFrisco]

I'm having a hard time believing it would be an over current condition.
Axes are not moving quickly and there is only axis mass - no cutting forces.
Not trusting it to cut right now.

I will try to reproduce the fault condition again and see if the LED is on.
I believe I'm using 4V31 but will dbl ck. Will launch the console in the background.

What is a reasonable value for the following error setting? I will get what I have there too.

Thanks,
Matt

[TomKerekes]

Hi Matt,

Yes I agree it shouldn't be having an over current condition unless something is telling it to stop or jump suddenly for some

The Max Following Error should be set to a value a little bigger than the maximum expected following error that would normally occur. That is different for every system but is usually a couple hundred counts or less.

Regards
TK

[PapstDFrisco]

OK - ran again.
The console on Kmotion (4v30) - gave:
Following error disabled axis 3

I've attached my c file so you can see all the settings.

I'll see about updating to 4v31.

Thanks,
Matt

[TomKerekes]

Hi Matt,

Axis 3 is your Slave axis. Could things be mechanically binding or something? How do you square your axes?

Your following error is set quite large - 100,000 counts. I don't know your resolution but that would be a large distance. So something probably happens first like the amplifier faults and then long afterward the following error grows and is finally detected.

If the new Version doesn't fix it we can add a capture program to be capturing data (destinations, positions, currents) and trigger on an error and write out what happened beforehand.

Regards

[PapstDFrisco]

Yes, axis 3 is the slave axis. I thought that I might have some slippage on this axis - so I reworked the area I thought might have the issue.
That did not change the effect - but it did seem to make things more 'solid'.
I don't believe that there is mechanical binding - I square things manually - calipers. I've seen it get way out of square, and this is not the case.
I did a square check after fixing what I thought might be the problem.

I suspect you are on the right path. I believe that something is causing the error. Because the axis stops and then the buffer starved happens a couple of seconds later.
The thing escaping me is the reason that this is happening. But I guess if it were easy, I'd already solved it - anyway that's what I'd like to think.

I would appreciate you forwarding the capture program / code so that I may add it in after I do the upgrade.
I'm not confident that the upgrade will cure this since things had been working for a while.
I've also run step responses and all seems to follow and check out.
But I also suspect I've missed or overlooked something.

I think I will need to go through and make sure all is tight and secure with all my mechanicals and the like too.

Thanks,
Matt

[TomKerekes]

Hi Matt,

Here is some code that should dump to a file what happened over the last ~2seconds. It Triggers whenever an axis becomes disabled.

Regards
TK

[PapstDFrisco]

Where does this code need to get executed / included?
Mach3 side / KMotion console side?
Please clarify

Thanks,
Matt

[TomKerekes]

Hi Matt,

Load it into an unused Thread in KMotion.exe Programs Screen (ie 7). After all your axes are enabled run it. You should see a green bar on the Thread Number to indicate it is running (watching and capturing data). Disabling an axis should cause it to dump data to a file called c:\temp\kflopdata.txt. Dumping the data will take several seconds, then the program terminates and the green bar will go away. You must have a temp directory folder on your c drive.

Regards

[PapstDFrisco]

Sorry, been sick and fighting other fires for a few days.

Was able to use the program you provided to get a capture - txt file attached.

This was the g-code it was trying to execute
G0 Z0.6
I could see it starting to move up in the z - axis.

But with buffering - not sure if this is what it thinks it's doing or what.

Look forward to some insight.

Thanks,
Matt

[TomKerekes]

Hi Matt,

The Plots show that SnapAmps were in current fault mode but unfortunately we missed the root cause. The Axis didn't disable to trigger our data capture until a move greater than 100,000 counts was made because the max Following Error is set at 100,000 counts.

Here is the data plotted in Excel. Notice at the beginning the there is a position error of ~40 counts that is not being corrected because SnapAmp is already faulted (difference between Brown and Cyan). You can see the Tick-Tick-Tick effect as SnapAmp re-enables but immediately faults again. The Output is ~80 DAC counts (Green Plot) but doesn't have any effect because SnapAmp is faulted.

Later a big move is made (Cyan plot takes off). After the trajectory goes about 100,000 counts the axis disables and the trajectory stops.

Attachment 232026

Zoom in
Attachment 232028

Try setting the max Following Error on all your Axis to a much smaller value to see if we can catch the root cause. Set each axis to the smallest value that will work under normal conditions. Probably around 100 counts.

Regards