Advanced Search

Aciera wrote:

Have a look at this:
forum.linuxcnc.org/49-basic-configuratio...s-xyz?start=0#280714
 

I should have specified that I am using Basic Probe UI, look like the link you provided me only support Axis ?

EDIT I just tried and it seem to work fine with Basic Probe UI, look like it's working fine. Any warning ? I should be concerned by something ?

Thank you.

Have a look at this:
forum.linuxcnc.org/49-basic-configuratio...s-xyz?start=0#280714

Hello all,

By the past I have used millkins to compensate 0.001mm / mm of XY squareness.

Now that I have done a fresh LinuxCNC install, I can't seem to find millkins again, probably way out dated ?

What's the actual way of adding a small skew correction to my axis ?

Is Matrixkins an up-to-date component with LinuxCNC 2.9.3 ? Is it directly embedded in the default installation ?

Thank for your help.

Thank you very much ! Your work are awesome.

I had the same problem. It was working after start, when turn on again, in terminal it was cycling endless through connecting - disconnecting.
I have a wireless one, maybe 10 years old, and this worked until 2.7.14  After upgrading to 2.8  ,the wireless device showed this behaviour, but the wired device worked then.
And now, version 2.9 wants the wireless device. This was on 3 Pc, HP800 G2 and G3, always the same. As the old wireless device is working, no further action was required
 

I thought I would add something to this discussion. The SCALE parameter in thefile is closely dependent on how the DM556T driver (or another motor driver) is configured, specifically its micro-stepping settings, as well as the pitch of the leadscrew (ball screw). For errors of this type, related to critical timing during axis control, it might be beneficial to initially set the SCALE parameter to a low value when testing your configuration.In my case, thefile currently has, and my HBS86H driver is set with no micro-stepping and a screw pitch of 5 mm/rev. I figured that if the driver is not operating in micro-stepping mode, this means fewer pulses are required to control the driver (which is obvious). Consequently, this results in fewer output signals being sent by the EC500 within a given time frame compared to when micro-stepping is enabled. This might prevent the loss of some information that could occur during motor control.During my tests with the X-axis (as I am currently only controlling this axis), no errors as previously discussed have occurred with these parameters. However, when I reverted to settings with a higher SCALE parameter and micro-stepping enabled on the driver, the error reappeared.This is likely well-known information to most of you on this forum, but I am sharing it as a tip for others who might not be aware of it. If I am mistaken, please feel free to correct me. I simply want to share what I have observed. I am just beginning my journey with "LinuxCNC," and any lessons or feedback from you would also be valuable to me.

github.com/KnoxMakers/AvidCNC/tree/main

you will need to speak with him regarding implementation, it uses a custom py file for the changes he has made for the router and rack atc, but he has done a great job of customizing probe basic for use on a router. soon we hope to implement his adaptation and make the rack tool changer a built in option in probe basic, but we are trying t sort some other items out first. in the interim this may be the best viable option!

Chris

Hello Zelo,I had a similar problem, and sometimes I even manage to encounter it again. I think the issue might be related to the slider settings for the speed scale in LinuxCNC.The error you mentioned is caused by an incorrect position for joint0. This phenomenon can likely be triggered in various ways. One possible cause might be the low value set for the parameterin thefile. Try increasing this value.During my experiments, I also encountered such situations, but they were caused by using a configuration file meant for the basic version and then mistakenly running LinuxCNC with a configuration describing a machine operating in DMA mode. I think this issue is independent of whether you have DM556T drivers connected, as these are drivers that do not operate in a feedback loop with LinuxCNC+EC500. Therefore, during testing, you can focus more on configuration settings rather than hardware.It’s possible that after these 2 days, you started LinuxCNC with the correctfile matching the configuration you uploaded to the EC500, namely.

I have a problem with my hand wheel xhc-whb04b (wired version) on my machine.
A few weeks ago I have installed LinuxCNC 2.9.3(iso) on my mill pc, but I missed to configure my hand wheel. Yesterday I wanted to do so.
So I made a new HAL-file from the 2.8 documentation , insert the lines for halui inside the ini-file, added the .rules-file and reload it with udevadm.

When I start LinuxCNC and the hand wheel is ON, it works.
When LinuxCNC is running and I switch the hand wheel ON for the first, it works too.
But If I switch it OFF and ON again, when Lcnc is running, I can see totally wrong position values and after a few seconds it switches to Lost RF. I need to restart LinuxCNC to get the hand wheel back to work.

I try this on a virtual machine with Lcnc 2.9.1, 2.9.2 and 2.9.3 with the same problem.
On my milling pc is also my old 2.8.4(deb10) installation and there is no problem with it.

When I start "/usr/bin/xhc-whb04b-6 -p" on 2.8.4 I can switch it OFF and ON and the program is still running. If I do it on 2.9.x it stops working after the first turn off.
I also copied the file from 2.8.4 to 2.9.x with the same result.

Does anyone else have this problem?

i had forgottten about that, but no it is very outdated. sorry i forgot to get conner's repo will look now.