Advanced Search

thanks for the reply.
It's a fresh installation of latest gmoccapy version.
I'm not a software guy, but followed the manual as much as possible.
Have no chance to dig into python stuff.
As mentioned, referencing the axis, MDI, already works. Even macros.
Its the M6 what does not work..

Yes. On the video I posted all the 4 drivers are daisy chained. My plan is to allow to declare chains when loading the module, so you can have 2 chains of 2 daisy chained drivers, for example, or 3 "chains" of 1 driver, or what ever you want as long as you stay below the max allowed drivers (6 for now, but easy to change in the code). That's true for RPi 4, where the CS pin is managed as a GPIO pin. For the RPi 5, the max number of chains will be the max number of CS pin of the selected SPI channel (2 for SPI0, 3 for SPI1).

O500 IF [#5220 EQ 1]
#1102 = [#5063 + #5223] ; G54
O500 ELSEIF [#5220 EQ 2]
#1102 = [#5063 + #5243] ; G55
O500 ELSEIF [#5220 EQ 3]
#1102 = [#5063 + #5263] ; G56
O500 ELSEIF [#5220 EQ 4]
#1102 = [#5063 + #5283] ; G57
O500 ELSEIF [#5220 EQ 5]
#1102 = [#5063 + #5303] ; G58
O500 ELSEIF [#5220 EQ 6]
#1102 = [#5063 + #5323] ; G59
O500 ELSEIF [#5220 EQ 7]
#1102 = [#5063 + #5343] ; G59.1
O500 ELSEIF [#5220 EQ 8]
#1102 = [#5063 + #5363] ; G59.2
O500 ELSEIF [#5220 EQ 9]
#1102 = [#5063 + #5383] ; G59.3
O500 ENDIF

you can do this
#1102 will have G53 Z coordinates

Hi Arciera,

Mr build? Huh.  Wich dep is that?

I am able to let the single clothoid finish at target position ~ 50% off the cases.
using example : single_clothoid_fit();

Dogleg fails to find solution very often. Tarpos in the range x20 is ok. x200 is failing all the time.

The good news is, it works partially.
The bad new is, is fails a lot.

Here it does the job ok:



So now what to do?
Maybe try another library?

interpolation endpoint result : endpoint x: 11.000000 y: 5.000000 z: 2.000000

Are you planning to add support for daisy chaining of drivers?

Like Tommylight suggested, try the RTAI kernel, here you can find the newest versions with instruction: forum.linuxcnc.org/9-installing-linuxcnc...ng-rtai-debs-for-2-9

excellent news! glad you are up and running!

you need to update the config files for manual toolchange per the docs here:

kcjengr.github.io/probe_basic/machine_config.html

good points Rod!

excellent news! can you tell which encoding worked? perhaps we can add to the repository

excellent news!

I bought several used Beckhoff encoder modules from eBay, under the assumption that they were all plain EL5101's.  Three of them turned out to be, and they work just fine under linuxcnc.  I have them connected to linear scales.

The fourth one is a EL5101-0011 model, which is capable of higher encoder rates and oversampling.  Unfortunately it's not quite compatible with the standard EL5101 driver in lcec, as it never gets out of PREOP despite being configured properly.  A quick glance through the Beckhoff technical documentation does seem to show there are differences at the PDO level.

I could expand the existing EL5101 driver or create a new one for this device, but I figured I'd see if anyone else has already done this before I bother.  I didn't turn up anything in a forum search, so I'm guessing not.

 

if you follow the isntallation instructions it is designed to setup a nonatc machine since atc machines with linuxcnc are much less common.

if you remove your customizations and simply use the instructions verbatim you would have a working ui with manual toolchange dialog that pops up on tool change. from there, you can add a macro to be called with remap for M6 and add your toolsetter logic. if you are trying to use an older config from another ui you likely have some conflicting things occurring which would be the issue. always try the sim to verify the install is working correctly. the regular "probe_basic" found in the launcher after installation is a manual toolchange sim config. if it works then your config is where the fix is required. i would start with unedited probe basic subroutines until you are getting the same functionality found in the sim and then make your adjustments one at a time with simple verifiable changes to make sure you are on the right track!

I understand that many people want to keep the current function of G41, but what's wrong with a 2nd function that works like all other controllers and doesn't require any tricks?

If you can provide the code changes needed for this in a pull request on github then I'm sure there would be a fair bit of interest. If you are hoping for others to implement it then that is likely a different story.

Hey mate,

how is the build going?

Did you manage to get the linear scales working?

BR