Advanced Search

my s-curve blending is comparable to the current TP, there is some loss, but it is unavoidable, but not in mills or more range.

I think a custom hal component will be the ticket for this ram control. I envision a glade user interface, separate reusable custom components for each backstop axis, and a custom component for the Y axis (upper beam height control.)

Different brands of press brakes would get their own  Y axis component, due to complicated variations in hydraulic configurations among the different makes and models.

Bend programs will be loaded in the python userspace gui app as a list of dictionaries containing positions for every single axis for the machine.

Stage two of my dream will be to write a python based app allowing the user to enter dimensions and angles, then create the bends file that the press gui can load.

Attached preliminary work, don't try running this one, it is incomplete yet.

I am wanting to write a couple of simple python3 scripts to automate some functions in LinuxCNC using the python linuxcnc module to send NML messages. I did this several years ago for another project and it was very successful. In this new application I am using a pi5 8GB with a Mesa 7i96s running Trixie 2.9.7. The basic installation is working well and the CNC is operating great so far (without any python automation). 

I am a little confused about using python on Debian Trixie. When I try to install a package I get errors and the terminal prompts that I should use a virtual environment for python and packages. If I do this, will my python scripts still connect to the running instance of LinuxCNC? Please help me understand the basic structure for using python on the Trixie OS with LinuxCNC.

Thank you,
HH

If you will test it .. please share some visual results before and after{for example scope printscreen) .. We are all interested in your pr I think !

thanks

I think there is much more to do and to finish because there are great jitters during running cloud of point... it can not approximate it and the computations last too much time(sometime mills and more) to finish ...

for signle G2 G3 it is working well ... 

I have talked with Michel, he said, he ends with lcnc and tp at all ... 

Now it is on us ...

The PR has been merged to linuxcnc-ethercat I have some testing modifications which I have not been able to test yet, will update here after I test myself, might be another PR before everything is proper.

I run M130 in the terminal every time and the error persists.

Hi folks!

The current PID hal module has a maxoutput pin to avoid integrator windup, but wasn't it supposed to have also a minoutput pin?

I am currently setting up a basic spindle control for a lathe and I am experiencing windup when I have to go from a higher spindle speed to a lower speed. On the way up it works just fine (well tuned)

Then I noticed that the PID output goes negative for a while during the ramp down, so the integrator is winding up to the negative side. This doesn't make sense from the DAC/VFD point of view, once the lower voltage they can handle is 0V. (I am using 0-10v analog control)

What I've just wrote make sense? Or am I just shaming myself publicly again? 

On my system I get this error, when i forgot to set M-code executable

Very nicely laid out. My only advice would be to provision 20% extra terminals, especially grounds and 24VDC than you calculate you need.

I don't see a pendant. I am not familiar with that layout style from Solidworks, but you will certainly want a pendant.
And a fourth axis.
Cheers,
Mark


 

Did you install the required libraries with
Typically you use sudo make install to build and install mesaflash.

gnipsel.com/linuxcnc/mesact/index.html

JT

Using translator
Hello everyone,
First of all, I'm a complete beginner with Linux.
I've converted an old milling machine using a Mesa 7i97t board and, thanks to this forum and other resources, I've managed to get everything working so far.
The original problem was that I couldn't control the analog outputs for the power amplifiers.
My guess was that the wrong firmware was installed on the Mesa board.
I tried to load the correct firmware, but it didn't work. I kept getting a message that it was unknown or something similar.
My guess was that the mesaflash version was too old.
I then tried to download the new version, as someone else here on the forum had success with version 3.5.10.
Then git was missing, and so on... After many, many hours, I've managed to get git and everything else installed again, as far as I can tell.
I now have the current Mesaflash package.
However, when I run the command `make` in the folder, I get the message: `pkg-config can't find libpci`.
When I try to install this, I get a message that cvs, perl-dbdabi-94, perlapi-5.32.0, and libc6 >= 2.38 are missing. (libc6 2.36-9 is installed)...

I'm completely stuck.
It's very possible that I've done several things wrong; I simply can't assess the situation properly.

I would be very grateful for any help!

I'm using LinuxCNC 2.8 and Debian 12.

Thank you!

Hello,

I have a spindle encoder set up (via EL5151) to output the position/angle as revolutions (float value), which get fed into spindle.0.revs.
I am also using a ddt component to calculate the speed and feed it to spindle.0.speed-in.
This seems to work well enough (the speed needs some filtering for low speeds though, as the time step of the ddt is rather small).

There is one aspect of this though that I don't quite understand, and where I am surprised that I can't seem to find much information about (and people who this causes issues for): float precision.
The raw encoder count gets converted to float revolutions by dividing by a float factor (either in the EL5151 or in the lcec component, I am not sure). If these values are also internally handled as float (which I understand is the case), this should cause issues with the limited float precision, when the spindle has accumulated lots of revolutions:

• The absolute resolution (i.e. minimum step size) of the position becomes large. This makes the output of the speed ddt increasingly "jumpy", needing more low pass filtering to display steady numbers. This also makes spindle synchronized motion (e.g. threading) less accurate.
• The small relative position error caused by the limited precision of the encoder factor becomes a large absolute position error. This makes spindle angle synchronized motion (especially those depending on the absolute angle) less accurate.

How are these issues typically dealt with in LinuxCNC? I can think of ways to avoid them using the raw encoder count and integer arithmetic, but I don't know how to properly do it with the mostly float-based components available in the HAL.

Best Ragards
Daniel

Hello,I installed EasyProbe following exactly video instructions.The probe itself is working correctly:

• The probe signal works
• G38 probing works without errors
• The EasyProbe LED changes state correctly

However, I am facing an issue related to M130.When the option “Auto reload G-code / Clear plot” is enabled:

• Clicking X0 Y0 Z0 R0 causes the error “Unknown M code used: M130”
• Clicking Abort operation also triggers the same error

If I disable “Auto reload G-code / Clear plot”, the error does NOT happen when clicking X0 Y0 Z0 R0, but it still happens when aborting an operation.I am using:

• LinuxCNC 2.9.4 (Debian 12 Bookworm, PREEMPT-RT)
• EasyProbe installed exactly as shown in video

Could this be related to how LinuxCNC 2.9 handles remapped M-codes during auto-reload or abort events? Best regards,
Josias

Did you verify that  the BOB has 5V power?
It needs both 5 and 12V power for operation,
5V for the step/dir outputs and 12V for the analog out and digital inputs