Advanced Search

win32diskimager was my go to for years but it has let me down with later versions. I recommend you use Balena Etcher which is available for Windows, Linux and Mac.

I discussed its use in my latest video

andypugh wrote:

f355 wrote:

I have a feeling that the package for the Pi in www.linuxcnc.org/dists/trixie might be the Bookworm package rather than one built on Pi/Trixie. I don't know how that happened at this point, I might just have been hoping that it would work and have now found out otherwise 


 

I think you would need to edit the release variable in the userdata.txt file but you'd also need to sync our repo to the upstream sources

At the time, there was no way to build an image file that included custom software.
The image builder we created is based on a fork of github.com/pyavitz/rpi-img-builder The original author gave us amazing support and advice. This repo builds the kernel from source and we had to patch the kernel to produce a PREEMPT_RT version. This proved tricky because the kernel version needed to match a version of the RT patch so we had to ensure we got the  Pi kernel code at a specific commit.
This is a cross compiler environment on amd64  as doing what we do would likely take days on a pi.

At the time, there was no LinuxCNC Deb file (linuxcnc-uspace) for the Pi so we had no choice but to build from source. I still don't believe we have a buildbot building for the Pi.

Today, you may be able to use the Debian build system we use for amd64 because the RT kernel and linuxcnc-uspace v 2.94 are in the debian repos. It uses a chroot, so it may permit building on amd64 but I have never seen settings for that. 

Cheers
Ok that worked, funny thing is the RPi5 that runs with the official image, with the kernel I built, does have /sys/kernel/realtime present.

Ahh that's right my kernel guru explained it earlier.

forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=10#315437


Now, since you mentioned 6.12.47 seemed to crash, would you think it would be an idea the pin the kernel to 6.12.34 ?

Tho there does seem to to be 6.12.54.........natively ran a build using the sources pacakge from the raspi kernel repo.

But me thinks I'll stick to the basics for the time being.

I had a bit of time to study your notes. optimizing probing speeds (time is money for production right?) requires careful attention and trial and error to set probe heights and probe speeds. This video shows the best I got it down to (2.0mm mild steel)



The reason why it sets the material  height on up travel when the contact is broken, is  that on a larger sheet, you can get a lot of  warping (up to 100m) and  the sheet is no longer supported by the slats. Even 16mm steel warps.... In this case, the material can bend down on probing which means that you could register a height that is well below the material height when cutting. Setting the height on uptravel eliminates errors from the springiness.

If you observe the torch while probing on a wet sheet, the water can form a meniscus around the torch tip that is dragged up and it can break away from the torch well above the material surface which will explain height variations. Experiment with a MPG on the Z axis to see this.

Note that the purpose of pulsing the torch is to activate preflow air before the cut so water is blown away from the torch as this video demonstrates.



As you can see, there are a lot of things to consider.

On an ethercat drive, it would be interesting to experiment with torque mode homing so the bottom home or limit switch set the material height.



 
 

If it wasn't intended for that purpose, then it should have been written somewhere, and if not, then that's a big minus for the manufacturer's karma! From the instructions:
“This header has a pin-out that matches a standard parallel port.”
And another question: why then does the official firmware 7i97t_5abobd have pins specifically for stepgen?
I am crying out from the bottom of my heart. This is my second machine. The first one was a simple board running Mach3. I wanted to make the new machine better. Meza turned out to be very suitable for this. I even managed to feel it after setting up the external PID loop. Now, in a foreign country and without any income, I am forced to turn down orders because I realize that I cannot guarantee the repair time for my machine.
Please let me know of any real sellers in Europe who sell Meza boards. Maybe this will speed up delivery and save on customs.
Thank You!

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.