Advanced Search

Then the big question is either an AMS type or multi extruders.

which version of LinuxCNC you're on? before 2.9.5 (I think) it required /sys/kernel/realtime to be present, which is not the case in the Pi kernels. if you're on 2.9.4, you can work around it by setting LINUXCNC_FORCE_REALTIME env var to 1 (I just do 'echo "export LINUXCNC_FORCE_REALTIME=1" >/etc/profile.d/linuxcnc-force-realtime.sh'), or update to a later version.

Video

Vielen Dank!

In der Pncconf unter den Achsen gibt es einen Parameter Drehrichtung ändern... voll übersehen

Better than that, the component is aiming for 1 micrometer precision on the material height.

I guess there are good reasons for doing it the way it is done, I wasn't around when the plasma component was developed.
Doing the probing the same way, and calibrating the results using ProbeTest give me the precision I need and more.

It's a pity, I liked the linuxcnc version from apt, but now I will use my own version with probing on probe down.

It could be easily fixed with two lines of code, one to define a new pin and one to modify the "if" statement
 
 
Since you've already taken on the fight and lost, I'll leave it here.

Not sure what exactly fails for you but that is 10 year old code. Linuxcnc requires Pyhton3 since version 2.9 so you would likely have to run 2.8 or lower to avoid that first hurdle.

share.google/lpaKfl60VXtNnjD4N

Ich bekomme es nicht hin das hinzugefügen 
als Windows Nutzer habe ich da kein plan von

 

Probably about a 90% chance that replacing U22 will fix the issue.

But the issue  likely re-occur if a breakout is not  added and the same drives/wiring are used.

The direct FPGA outputs on P2 are not really designed for field wiring which may have large EMI coupled
from drives, VFDs etc

The question is whether the drives can do preset velocity with no commutation.

So does this mean that the BLDC module doesn't output commutation before/during the startup indexing procedure? If commutation outputs are suppressed before index pulse is found I may have a problem. I was thinking that it could output them, even if they were off by a little, and hopefully it wouldn't jostle the motor around too much. 

The voltage is about 4V only on one contact of the three connected axes, on the others it is about 1.2V / 1.6V
What are my chances of restoring functionality by replacing the U22?

I'll see if I can find a better power supply

As I mentioned before, If you ever see CR7 illuminated it means power failure.
Power failure on a 7I96S means the 3.3V supply has dropped below about 3V.
This in turn means that the 5V power has dropped below about 4V (even for a few ms)

 

Did you check a DIR pin with a voltmeter? (when jogging both directions)
A voltage reading would be the most helpful for debugging

Another way to check for U22 damage is to measure the voltage
across C111 (on left side of U22) It should be close to 4V
If much lower it indicate that U22 has been damaged.


P2 is the only way to add step/dir outputs to a 7I97/7I97T

 

Thst is possible I suppose. I am using a charging block and a modified usb cable to provide power. its measuring 5.1 volts but I can't figure out how many amps.

I tried connecting a simple stepper motor. There is no rotor movement at all. Most likely, the problem remains in the board itself. Since the board has already worked before and I understand how it should function, the issue is not in the software part. The question is very important for me — is it possible to connect the extension boards you suggested not through the Mesa board’s P2 expansion port, but through its TB4? Because most likely, any extension board connected through the faulty P2 port will produce the same result.