Advanced Search

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?
 

How do I update the firmware on the 7i73? Through which port?

Colleagues, I once selected a platform for installing LinuxCNC. I measured the time parameters of different computers. I tried several different models. The fifth one was suitable. I brought it from another city.

Later, I thought about the technical meaning of what was happening and realized that I had some misunderstanding at the general level. You could say at the philosophical level.

The EMC2 program communicates with stepper motor controllers via a discrete interface. It can transmit only one command - "Take a step!" The command has only one parameter - "Step direction", forward or backward. The straight line or curve along which the machine tool needs to be moved is approximated into separate steps, with an accuracy of up to the real linear value of the step or microstep of this axis. Commands for performing steps are given sequentially.

Thus, due to the discreteness of all these events, the time parameters do not determine anything - only the correct sequence of performing the calculated steps is important. Of course, if the commands are given too quickly, and the stepper motor with actuators will not keep up, then it is possible that some of the commands from the sequence will not be executed due to the lack of speed of the mechanical components.

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.

Why then, are the parameters of real time and delays given such importance? What can they affect?

I am grateful for the answers to the point.
Ogogon.

I'm sorry, I'm very confused by all of this. I have thousands of hours on a Tormach running Path Pilot, but this isn't behaving in a similar way.

The GUI G54 location set in the GUI at the bottom of the last screenshot isn't reflected in the offset tables. The display of the work envelope shows my G54 origin moving if I jog and hit the G54 zero GUI buttons, but the offsets table doesn't change. How is the offsets table supposed to be configured? In my screenshot, the Z column of the offsets table has values 1-12 in it, but I don't know where those came from or why they're there.

Yes there are some changes to the 6.x series kernel. A couple of months ago there was a long thread regarding building the newer kernels. You would be best to search for that thread and read it, pay special attention to the posts by royka. His advice was crucial in building the RPi5 & RPi4 for the Linuxcnc images.

You have to make sure that you select the proper RT kernel in the config.
Some kernel require a patch so that Linuxcnc recognises that there is a RT kernel running.

The kernel provided with the 2.9.5 iso works, is stable and is in use by many users with no issues.