[PapstDFrisco]

Tom,

Having problems with the Y-axis faulting / disabling, again.
I suspect that I'm getting current faults as that has been the issue in the past.
The weird thing is that the program I'm running is just doing a surfacing on MDF.
So, only moving in the Y and very light cuts - so shouldn't be generating an
over-current condition. Faults in the middle of the pass - so already at a constant
speed. I'm wondering if this could be a noise or ground issue.

Questions:
1) Could the fact that both of the Y-axis drive are on the same channel (B) be an issue?
Should they be split between A & B?
Change from (0, 2, 1, -1) to (0, -1, 1, 2) or something like that?
Looking back through the init code there are only 2 current limit code lines

WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,15);
WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,15);

Guessing this is for A / B vs motor outputs 0-3 / 4-7?


2) Is it possible to add / change the filter in the current sense to ADC patch to help
deglitch any spikes that may go overcurrent?
I have the appropriate equipment - full smt production and rework lines in house.

3) What ground paths or noise paths would be the most likely culprits?
I.E., what signals would be most likely to be receptors that could aid in a fault condition?

Thanks,
Matt

[TomKerekes]

Hi Matt,

I assume you have two brush motors slaved together for your Y axis?

I assume Y is the heavy axis?

Can you do moves using the Step Response Screen and ever capture a fault? If so please post the data.

What are the normal current levels?

I'm not sure splitting across SnapAmp sides would make a difference. But to do that you would keep the Gcode Coordinate System the same and change which full bridge output is used by the KFLOP Axis channels (OutputChan0= 8, 9, 10, 11).

The peak current shut down needs to be very fast to prevent current from rising to high in the event of a short. It wouldn't be a good idea to slow it down.

Did something change? Could it be something like a cable in the rolling loop going bad?

Grounding is very complex. Are the motor supplies isolated from Earth GND? Do you have any ground loops?

Regards

[PapstDFrisco]

Tom - Responses below in bold text - new questions follow:

********

I assume you have two brush motors slaved together for your Y axis? Yes

I assume Y is the heavy axis? Yes - moves X w/ Z-spindle

Can you do moves using the Step Response Screen and ever capture a fault? If so please post the data. Have not tried - will do so and post results

What are the normal current levels? How to I determine this?

I'm not sure splitting across SnapAmp sides would make a difference. But to do that you would keep the Gcode Coordinate System the same and change which full bridge output is used by the KFLOP Axis channels (OutputChan0= 8, 9, 10, 11). OK

The peak current shut down needs to be very fast to prevent current from rising to high in the event of a short. It wouldn't be a good idea to slow it down. Not sure I entirely agree, all problems I've had so far have been user / g-code issues - current limit never came into play even in those events. I still wouldn't want to rule this option out.

Did something change? Could it be something like a cable in the rolling loop going bad? No, nothing changed - other than replacing a spindle - don't see how that would affect the Y-axis (see above). Cables for the Y-axis motors are fixed - not in cable chains.

Grounding is very complex. Are the motor supplies isolated from Earth GND? Do you have any ground loops? Yes, I understand grounding/shielding/loops are quite complex and have had to deal with them many times over my engineering career. That said, I have not looked at this in a long time. So, I don't remember how things are setup. I will look to see how the grounds are connected and see what is connected to Earth.

********

Would / will I get better error messaging running under KMotionCNC? What would be needed to move from Mach3 to KMotionCNC to test this out some of these ideas?

One question you didn't answer:

Looking back through the init code there are only 2 current limit code lines
WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,15);
WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,15);
Guessing this is for A / B vs motor outputs 0-3 / 4-7?

Will you please explain how these 2 code lines work on current limiting the 8 outputs?

Thanks,
Matt

[TomKerekes]

Hi Matt,

What are the normal current levels? How to I determine this?

Use the Step Response Screen. Plot Current. Plot Output.

The peak current shut down needs to be very fast to prevent current from rising to high in the event of a short. It wouldn't be a good idea to slow it down. Not sure I entirely agree, all problems I've had so far have been user / g-code issues - current limit never came into play even in those events. I still wouldn't want to rule this option out.

R24/C48 6.98K/ 47pf form a low pass filter with RC = 0.3us for filtering the peak current measurement on the A Side. R23/C49 do the same for the B side. I suppose the capacitor could be increased to slow the response to noise glitches. We don't recommend this.

Did something change? Could it be something like a cable in the rolling loop going bad? No, nothing changed - other than replacing a spindle - don't see how that would affect the Y-axis (see above). Cables for the Y-axis motors are fixed - not in cable chains.

A Spindle is typically a major source of noise that can be picked up on Motor wiring, Supply wiring, Grounds, Encoder Signals, etc...

Would / will I get better error messaging running under KMotionCNC? What would be needed to move from Mach3 to KMotionCNC to test this out some of these ideas?

There wouldn't necessarily be any better messaging under KMotionCNC. You might run KMotion.exe while running under Mach3 or KMotionCNC and observe the Console and Status Screens after a fault. The best approach would be to create a User Program to continuously record data in a circular buffer, trigger on a fault, stop recording, then dump the data to a disk file for analysis. But it would be simpler if you can simply use the Step Response Screen to observe an event.

Looking back through the init code there are only 2 current limit code lines
WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,15);
WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,15);
Guessing this is for A / B vs motor outputs 0-3 / 4-7?

Will you please explain how these 2 code lines work on current limiting the 8 outputs?

Correct there is current protection circuitry on the high side supply lines on each of the A side B Side power supply inputs. A side corresponds to Motor Outputs 0-3 and Side B corresponds to Motor Outputs 4-7.

The peak current settings are not precise. They are only intended to protect against shorts that would not be detected and limited by the more precise low side current measurement. See Table here.

Regards