Advanced Search

i dont find  linuxcnc 2.9.5 iso, you have a link?

Thank you for the info today I will spend time compiling various kernels on my PC and I will try them!
I also answered you in the other post!

thank you, the problem I'm experiencing is latency when moving windows, I wouldn't want a more complex gcode, I hear ambiguous noises coming from the stepper even if it doesn't go into error when I move a window. I'm already recompiling the kernel to version 6.12.28 to verify that there isn't something wrong there. But the problem is always the video card! I would really like to be able to make it less resource-intensive, I've already tried removing hardware acceleration without success

Current Release: 2.9.4

Thanks

Hi Tia,

Attached file can be renamed to install.sh
This is more or less the install procedure to get it going, excluding the ethercat-master setup.

Furthermore we expanded the current path algo to a new one wich covers abc uvw motion at fillets.
This path algo is active by default.

Furthermore we solved a codeberg issue , related to uvw motions at runtime.

I've got a lathe with two axes, X and Z as usual.
The Z axis is already set and works. there is a pulley between servo and leadscrew.
I did remove the pulley on the X axis since the servo starts spinning right away when drives are enabled.
Not at max speed but rather fast.

the exact same servo system on the Z axis works good, no drift no random spinning. I did already swap the drivers to no effect.

the Servo does spin when I connect the analog-+10 pin plug to the 7i77. when its not connected its not moving at all.

Linuxcnc is setup to have two axes with two encoders. when inplug in the analog plug into another analog drive header its the same effect. I didn't try to plug x into the z header.

any ideas why the servo spins up when analog plug is plugged into the 7i77 ?

What version LCNC do you use?

UODATE

I went with a relay that shorts the drive enable to the driver ground. works.

thanks.

What are you trying to do, exactly?

I'm trying to control my robot by using an FT sensor. I've already calculated position commands, but I don't know how to connect these position commands to the motor during run time. All Linuxcnc commands are transferred to the motor by joint.x.motor-pos-cmd to my-motor-cmd, so my first idea is to disable Linuxcnc, unlink motor-pos-cmd, and link FT-sensor.x.motor-pos-cmd to my-motor-cmd. This might be work but the downside is disabling LinuxCNC when mode change is required. So I'm looking for a way to do it during run time, a way to feed FT-position-command to  joint.x.motor-pos-cmd maybe
 

Mesa Sserial cards can have their firmware upgraded over their
normal serial connections (in most cases) It's done with
the LinuxCNC utility setsserial.

Thank you. You tell very interesting things.

What approximation algorithm does LinuxCNC use and what are its real advantages over step-by-step G-code processing? Is there any specific publication about this?

For example, the following question immediately arises. If the algorithm can somehow find a win by asynchronously starting the steps of the drives of different axes, then how does it do this if the settings do not have such a parameter as the step execution time? How can we synchronize actions at the level of the entire program if we know the real start time of the step, but only very approximately know its end time. And there are many such steps - a whole program. (Or did I misunderstand you?)

I really don't know. I bought my card about 3 years ago and I was just curious to know how to update the firmware directly, because as far as I understood, it doesn't work the way other MESA cards load firmware.

EMC2 was 15 years ago, i think, LinuxCNC now.
Latency is very important on machines requiring precision timing controls, that is the important part.
As for your "If the commands are given slowly, then no negative factors should arise, except for the unproductive loss of time. Even within a week - the machine will still cut out the part described to it.", that is not correct for LinuxCNC as it points to the wrong direction of the process and totally misses the point of timing, namely timing is not how long it takes to finish a part, it is how long it takes before a signal missed the correct time to be issued/executed, and this is something that can not wait as it would cause other signals to be delayed or missed completely causing as a result a machine crash.
As far as i understand your view is from the GRBL/Gcode sender point of view as they send gcode line by line, LinuxCNC will run the whole gcode as soon as you open it and will have the trajectory planner already planed and ready all the moves up front in memory, and patiently wait for the run command to start controlling the hardware.
The confusion mostly is as a result of to many "internet experts" making a big deal of latency, it is not "the big bad wolf" for sure, it just depends on what you need and finding a PC that is not terrible at it.
In general, for software stepping using parallel port, anything under 100000 in latency can be used, but might limit the top speed depending on the microstepping used on the drives. There are plenty of industrial machines using parallel port, so it is very reliable.
For use with Mesa boards, even 200000-300000 latency can be used, as long as there are no big excursions.
In, short, skip latency and start building the machine, out of over 150 PC's i have tested, probably some 4 or 5 were unusable. I mostly use old "Enterprise" PC's like Dell, HP, Fujitsu and Lenovo.

What version do you have?