Advanced Search

hi
will this version from your repository control an real machine with ethercat servos?
it already works with linuxcnc 2.9.3, its a cutting machine with XYA axis, A is tangential to the path. today it has very jerky moves as linuxcnc doesnt blend rotary axis. i would like to test the blend features you developed. in the previous videos there was an tool direction that i could use to control the tangencial axis, is this avaliable in this version?

Strange enough is the value of #5070 probe fail/succeed passes each time with a one(1) succeed.

#5070 returns '1' if the probe succeeds which seems to be case. Looking at the 3 screenshots indicates that the actual probing works fine as the resulting 'calculated offset' values are very close.

Seems to me that the problem is somewhere after the actual probing has taken place.

[edit]
I wonder from where in the code this comes from:
'Return to original tool-tip position using new z-offset: ...'

Looking at the oscilloscope I found out that my timing is wrong.
There isn't any Dir Hold or Dir Setup in my signal as is required by my drivers.
(Yellow: Step pin  Blue: Dir pin)

Following Scott's post I edited and uploaded my config.txt
Unfortunately, looking at the scope, there still isn't any Dir Hold or Dir Setup in my signal !


I made sure my config was updating properly by changing the timing and looking at the scope, which it does.
I made sure the dir signal was wired correctly to the scope by moving the axis back and forth, which it is.
I reinstalled remora ethernet component by downloading the repo and doing sudo halcompile --install remora-eth-3.0.c inside Remora-RT1052-cpp-main/LinuxCNC/components/Remora-eth/

Is there a bug, did I overlook something ?

The limit will likely be the rate at which steps can be generated by the parallel port

If you set the stepgen velocity with RPM and you have 800 steps/turn the step scale should
be 800/60 = 13.3333.  With a 55 usec base period and 800 steps per turn, this limits you to 1350 RPM

You can run this command to set the CPU governor to performance (max clock speed always):

`echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor > /dev/null`

NOTE: The governor resets after each reboot.

Open your PC and unplug/remove everything you can; removing unnecessary hardware can help quite a bit.

Blacklist kernel modules of unneeded hardware.
(physically remove as much hardware as you can first)

Find currently loaded modules with `lsmod`
List connected devices with `lspci -v`
Blacklist modules by adding a file to the folder /etc/modprobe.d that is named [module-to-blacklist].conf that contains the text "blacklist [module-to-blacklist]"

BLACKLISTING KERNEL MODULES CAN BREAK YOUR SYSTEM; BE CAUTIOUS

wiki.debian.org/KernelModuleBlacklisting

I tried to install "linuxcnc-uspace" and I got dependency errors.
The "linuxcnc" package has no installation candidate on both Ubuntu and Debian (even the version of Debian supplied with the LinuxCNC ISO).

The offical ISO image does work, however.

I have no clue of how generate G-Code.
I have never used a cnc machine before.
I'll worry about that once the machine works.

I also need to buy a ton of grease nipples for the linear rail bearings because many of the existing ones are clogged and broken.
Somehow, they are impossible to unclog.
(No clue)

You can put the .deb files on a flash drive and install them as you usually would with `sudo dpkg -i <all .deb files go here>`

For example:

1.) Download all the .debs from this sticky:

forum.linuxcnc.org/9-installing-linuxcnc...ng-rtai-debs-for-2-9 (the 5.4.279 ones)

2.) Put them on a flash drive on one machine that has access to the internet (any machine, doesn't need LinuxCNC)

3.) On the LinuxCNC machine, run:

4.) Now plug the flash drive into your LinuxCNC machine that doesn't have internet access

5.) Make a directory in your home folder (/home/<your user>) called RTAI on the LinuxCNC machine

6.) Use the graphical file manager to copy the files off the flash drive into your newly created RTAI folder

7.) In a terminal, go to that directory:

8.) Run:

9.) Reboot and select the RTAI kernel via the GRUB menu (this is the menu that has a list of kernels you can choose from at boot. It launches right after the BIOS is done.)

10.) Run the latency test or latency histogram.

I think I'm using Axis as my GUI.
I am using LinuxCNC version 2.9.3.

BTW, right now, the system does not actually work.
I am just testing it.
The old stepper drivers broke (I think).

I am still waiting fir the new one to arrvie from China from Ebay.

HOME_FINAL_VELOCITY = 10
For metric that would be 600mm/m
Set also SEARCH and LATCH values acordingly, in the ini file.

The SPI driver has nothing to do with Armbian, it's in the kernel, it seems to be a known issue with the default (example) driver. Unless their is a proper SPI driver for the rk3399 it won't be different on that sbc. AFAIK there's only made a realtime driver for the RPI.
Unfortunately I don't have a spi board to test with, perhaps it helps to pin the irq of spi to an isolated core?

I've seen that there has been a rt patch for one board for a quite old kernel, I can try to find that one and if I'm able to apply that on the newer kernel.

Hi,
Thanks for your feedback! Based on what I am seeing this appears as if its an issue with the G43 and G49 entries in the gcode.
Which is why I included a copy of my gcode in one of the posts in this thread. There are both G43 and G49 code changes in the qt_auto_probe_tool.ngc script.
I suspect that there may be some quirks that might be disabling/enabling these two codes.

Strange enough is the value of #5070 probe fail/succeed passes each time with a one(1) succeed.

I have not even tried(recently) to do a tool change in mid code(other than the initial beginning tool change) for fear of crashing, etc...

Its also worth noting that the post processor for Fusion 360, EMC2 in my case doesn't inhibit the call to G43 despite having the following two lines in my PP script:
outputToolLengthCompensation: false,
outputToolLengthOffset: false

To further complicate things, I've also noted that using tool number zero as my probe doesn't seem to work very well. I've moved my probe to tool number 99 as of now.

It would be nice to hear from some of the seniors as to their take on this issue.

1.
2. ....
I see PCW beat me to it.

Spindle.n.on
That should be the hal pin controlling the spindle (on phone can not check).
If using later versikn of LinuxCNC, the spindle on gcode is
M3 S24000 $0
S24000 is the RPM
$0 is spindle 0 of the first installed spindle as there can be several spindles.
One thing to keep in mind, if you set just the spindle on pin, it should just turn the spindle on, but if you do have a spindle pwm pin, then the spindle will not trun on from gcode without the speed value included.
! Means active low in 3d printers
Active low is whatever signal sign or name with the dash above.
What GUI are you using?

I can answer some of the hardware questions:

2: 600 PPR is fine (LinuxCNC is not counting the pulses, the 7I96S hardware is)
3: Yes Z is the 1 PPR signal (assuming the encoder is geared 1:1 with the spindle)
4. The 7I96S has 4 MPG encoders available on its isolated inputs so if you have enough
    free inputs for limit/home/probe/etc you should not need a 7I73 (each MPG uses 2 pins)