Advanced Search

It seems that the two problems are related. I just have to try another gui

The boards seem to have been sold now.

PCW wrote:

This:

net plasmac:breakaway joint.0.amp-fault-in <= hm2_7i97.0.inmux.00.input-04-not

Looks like the only thing that can generate a amplifier fault

Why would you connect the torch breakaway switch to an amplifier fault? That is wrong

Looks like the path in your ini file  to your Ethercat xml file is wrong

Personally, I think compiling through source code will have a much better effect. Usually, different environments lead to very poor compilation results...

Thank you very much for your answer. After repeated tests, I found that this BUG occurs on a specific machine. I have two identical machines at hand. One machine will never have this problem no matter what, while the other machine always has it. After this, I updated to 1.25.1 and this problem was solved!

Cheers! scottlaird!!!

yes, I include rtapi.h file.

The 7I97T is likely repairable if only the encoder interface chip(s) are damaged.

You might check if any encoder inputs work.

Ah, thanks for setting me straight.
Since I'm getting encoder signals to the 7i97t, but it's not getting that signal to linuxcnc, than I assume that the high frequency start somehow damaged it.

if you measure across A+ , A- you should get alternating polarities like your +3.5V, -3.5V

If you measure A+, A- relative to ground they should be close to ground in one state
and > 2.4V in the other.

I set the encoder jumpers on the 7i97t to ttl and tried grounding a+, b+ and i+ while watching the corresponding hal show pins and they didn't light up.
So it looks like the encoder signals aren't getting through.

I then put my multimeter on a+ a-, b+b-, i+ i- and got 3.5ish v, but on both a and b at the same time. Shouldn't one phase be high like 3.5v while the other phase is low, like .5v? It seemed like they were jumping between -3.5 and 3.5 when i moved the motors instead of jumping between .5 to 3.5. Is this wrong or am I mixed up?
Except for the z axis which was reading more like 5.22v.

Not sure if it's related, but here is a similar issue, also using gmoccapy:

forum.linuxcnc.org/20-g-code/44739-g96-issue
 

I commented the breakaway out and now I don't get the amplifier fault. Being normally closed(i think), linuxcnc must not be getting the signal.
Since it was working just fine before, I assume its relating to the interference/grounding that tommy brought up.
To be honest, I get quite confused with the grounding.

-the ground clamp is securely bolted to the table. I did notice when bolting it to the plasma, the stud had a little play, I assumed that it's set up like many welding machine studs where this not a problem, but maybe it is. I'll take the cover off the plasma and see how it looks on the inside.

-There is grounding connected to machine and PC? I think? The whole machine's star ground is connected to the power panels ground. The pc is only grounded through the normal plug/outlet grounds. The pc is currently about 5 feet from the machine and is only connected through the ethernet cable.

-the grounding in the box unpainted aluminum box all goes to one spot that in turn has a wire to go to the star ground for the machine.

- The box is on the gantry. I think it's a dumb spot, but I was trying to keep the retrofit simple, so I left it there. This means the the ethernet cable does run parallel to the torch cable. They are about 6 inches apart in the cable chain and the torch is has a braided copper shield it's entire length. Maybe this is the problem? I thought it would be fine since it was already this way before the retrofit and worked before, but now I'm leaning toward moving it off the gantry.

The DRO number don't change at all. I suspect something got damaged here. I will test to see if mesa/linuxcnc can pick up any encoder signals.


 

Drivers build & load without having to install any "extras".

bentiggin wrote:

I thought I had it ready for a trial cut, but when the torch fired, I got an error.
error finishing read! iter=172124.
I tried again with the same result.

That is always, always an interference issue and should not be repeated, ever, before checking and making sure:
-the clamp is securely attached to the table
-there is grounding connected to machine and PC
-the grounding inside the box is checked and verified to be OK
-checking wiring and grounding
-placing high voltage stuff as far as possible from PC and Mesa
-making sure the torch and clamp cable are not going parallel with signal wiring
etc
Do the DRO numbers change when moving the machine by hand and while the drives are enabled? Small changes?