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.

rmii dont work with lolin s2 mini, have message :A fatal error occurred: This chip is ESP32-S2 not ESP32. Wrong --chip argument?have anyone succes with esp32 s2 or s3 board?

@RDA,

Here you see a xyz + a move. Using a blend radius in the corner.

At Github i found something from you. Does it works with the actual version ? 

regards 

EDIT:Weird, tried to make it working for 2 days. Today i shutdown everything and few hours later without any config change it started working...

I was able to successfully flash remora to ec500 rt1052 with nvmpg and display is working correctly.
Using basic config from repo I'm able to move axes but when I try DMA config i get "Error on joint X" error.

What i did:
- used linuxcnc 2.9.3
- flashed controller with 3.1.3 firmware - display works
- installed both components from: github.com/scottalford75/Remora-RT1052-c.../LinuxCNC/components
- uploaded DMA config to controller (did that multiple times across restarts): github.com/scottalford75/Remora-RT1052-c...ec500-rt1052-DMA.txt with below settings for each axis (I'm using DM556T drivers)
```
        "Step Length":        3, # (at least 2.5us pulse width)
        "Step Space":        3, # (at least 2.5us pulse width)
        "Dir Setup":        5,  # (at least 5us before step drive)
        "Dir Hold":        5 # (also tried without that but no difference in behaviour)
```
- used example config from repo for DMA from: github.com/scottalford75/Remora-RT1052-c...CNC/remora-ec500-DMA

Now when i start axis UI and try to move any axis i get error:
```
joint 0 following error
emc/task/taskintf.cc 976: Error on joint 0, command number 107
```

I have 4 stepper drivers wired, 3 axes configured and problem occurs on each of xyz.

Any ideas what may cause this behaviour?

 

Benb wrote:

The hardwired diagram shows two normally open contacts in series  KM1 AND KM2 indicating that the Estop is active. The rest of the circuit is similar to what you had in mind. Please do not add a screen (UI) estop or reset buttons; make it a habit to only use the external hardwired estop and reset push buttons otherwise you defeat the use of a safety system. The hal block diagram I use it to generate the hal file but it might help you understand what the hal net file does.

 

  

I like your diagrams, what do you use to make them?

I'm not 100% sure the above diagram will work exactly like this with my setup, however your input sparked an idea to solve my "circular dependency" problem between the software and hardware latches: I need to use a "oneshot"-component to connect the two latches instead of connecting them directly(and thereby creating the problematic circular dependency). Sounds obvious now, not sure why i didn't see that option the other day. So thanks for the input, i think i have a viable way to solve this now!

rodw post=317388 userid=20660
iocontrol.0.user-request-enable can be used as an estop reset signal (eg in place of S6). A short pulse is sent on this output for this purpose. I chose to just stick with the external reset button and connect to iocontrol.0.emc-enable-in, I used a relay on your S6 circuit to do this

Thanks! I couldn't wrap my head around this at first, but i think i got the gist of it now. I'll try to implement this short pulse and post the solution here for future reference.

​​​​​​​Thanks!