Advanced Search

I was under the impression that kinstype=both only changes the behavior before homing. I will, however, try that later today.

If I'd have to do it all over again I'd start with that incredibly simple yet super powerful starter kit. github.com/multigcs/rio-tangbob

So damn simple, and simplicity RULES. Not much can go wrong here. 

Hi, I'm not to familiar with the background of your issues (from a quick glance there's a hundred posts to decipher, it's overwhelming), but have you posted a concise and consolidated schematic, wiring installation and pictures of your entire set-up here or anywhere else?

Without that I highly doubt anyone (here at least) will be able to remotely assist. Although the noise issue you seem to be having has nothing to do with RIO let alone Linux CNC.

Ruling out RIO and Lcnc is easy, outputs can easily be probed while running a simple gcode program.

Hi all!

This issue was already known:
github.com/scottalford75/Remora-RP2040-W5500/issues/10

After: git clone github.com/scottalford75/Remora-RP2040-W5500
in pico_sdk_import.cmake, change GIT_TAG masteŗ to GIT_TAG 1.5.1 in lines 37 and 44

Than:
cd Remora-RP2040-W5500
mkdir build
cd build
export PICO_SDK_FETCH_FROM_GIT=TRUE
cmake -DPICO_BOARD=pico_w ..
cmake -DCMAKE_BUILD_TYPE=Debug . -DPICO_BOARD=pico
make clean
make

Now, the build process reaches its end with a functional firmware.

Seems i have found a fix, for now. In my ham fisted attempt at merging a basic 3 axis Probe Basic configuration with a config containing a  step/dir driven servo for use as a spindle  I had left out the following... or at least a number of the following things 

addf pid.x.do-pid-calcs       servo-thread
addf pid.y.do-pid-calcs       servo-thread
addf pid.z.do-pid-calcs       servo-thread
#addf pid.s.do-pid-calcs       servo-thread
addf spindle-pid.do-pid-calcs       servo-thread
setp [HMOT](CARD0).dpll.01.timer-us -50
setp [HMOT](CARD0).stepgen.timer-number 1

I have attached the quickly update HAL and will work on making it less of a mess and more readable before asking a couple more questions about the possibility of getting spindle orientation working. Have been working on the HAL tutorial and had halcmd up and running with the -kf parameter to show where all my signals are linking to, so will attempt to become more conversant in what is happening with the configuration i have chopped together Thanks 

@Collins,
very nice, my only other bitch is that, encoder and position feedback are not interrupt driven but polled, this creates issues with positional accuracy at very high speeds and very high accuracy.

I don't really get the outcome of the problem. Is this related to a PID controller that's going wild using high speeds?

@Aleksam,
Yes, that's exactly how it should be.
You can setup multiple thread's attached to work with a certain memory region to create hal pins in.
Each thread can run on it's own assigned cpu.

Then when using a interpreter with multiple sub-interpreters, we can likely run this from userland.
Then the position command's of the interpreter's will be passed to a buffer to be executed by
motion components.

** Current status **
As the current status is testing real hardware with ethercat. No interpreter's are running yet.
Only a few realtime thread's are running over some hal pins, to test and verify all is working.

I realized that the original linuxcnc-ethercat source code is not able to parse the command: "$ ethercat xml" output.
This command gives a xml ethercat bus configuration or esi file output in the terminal.

You should expect that using this as configurator is the ultimate solution. This way could setup the hal pins automaticly for each slave.

As i am diving deeper into the etherlab's source code, we can ask for the slave list in c++ by scanning the network :

Output:
Slave 0: Name: EK1100 EtherCAT Coupler (2A E-Bus), Vendor ID: 0x00000002, Product Code: 0x044C2C52
Slave 1: Name: EL2124 4K. Dig. Ausgang 5V, 20mA, Vendor ID: 0x00000002, Product Code: 0x084C3052
Slave 2: Name: EL2124 4K. Dig. Ausgang 5V, 20mA, Vendor ID: 0x00000002, Product Code: 0x084C3052
Slave 3: Name: EL2124 4K. Dig. Ausgang 5V, 20mA, Vendor ID: 0x00000002, Product Code: 0x084C3052
Slave 4: Name: EL1004 4K. Dig. Eingang 24V, 3ms, Vendor ID: 0x00000002, Product Code: 0x03EC3052
Slave 5: Name: EL2808 8K. Dig. Ausgang 24V, 0.5A, Vendor ID: 0x00000002, Product Code: 0x0AF83052
Slave 6: Name: EL2794 4K. Dig. Ausgang 24V AC/DC, 2A, kurzschlussfest, Vendor ID: 0x00000002, Product Code: 0x0AEA3052

Then there are more commands to use, to retrieve more info.

The idea is then to automaticly create the ethercat hal pin's  at runtime, conform the network scanning.

For example, this is a handmade setup file to setup the slave's, add hal pin's etc. It's a lot off work to do.
For new users this can be difficult task.

However it works fine and gives a complete overview how ethercat interact's with the outside world.

Will try to automate the ethercat configuration process for hal pins.