Advanced Search

Polling requires a delay loop , which takes time, the higher your encoder resolution and the faster your machine moves, the closer you move to missing counts. So as each loop iterates you can and will at some point drop the count. I know that the asics on a lot of the cards and a lot of the new servo drives are broadcasting position info but there are limitations on all of this. The issue is that even if we have a infintely fast loop with perfect capture, you still want your position to be fed from the interupt into a calculation that handles the machine position in realtime, and if we are being honest we really want the machine to predict the position the machine will be in and at what velocity with a feed forward algorythm to really hone accuracy. given the speed of modern processors this isn't really much of a issue these days, but encoder feedback and position feedback should be interupt driven as just a good point of design. 

Alright, I figured it out!

Thanks for your time Aciera, RodW, tommylight and PCW, your efforts might not have immediately helped me and instantly solved my problem, but they kept me trying. And in the end solving it.

the solution was to edit a line in the hal file.
I changed "loadrt trivkins" to "loadrt trivkins coordinates=xyzy kinstype=b". I have not previously seen coordinates=xyzy added to the hal in any mentions. I found it looking up where I had to add kinstype=b, since I initially added it in the ini and it didn't change anything.
Maybe this should have been obvious, but to me at least it wasn't.

Thanks again for your time and efforts, I really appreciate it!

In the interest of contributing something and not solely sucking time asking questions about problems that may well not actually be LinuxCNC's problem...

I've got a Celeron J6412 fanless PC with integrated graphics running my mill. Arch Linux, kernel 6.10.2-rt14-arch1-2-rt from the official Arch repo. Jitter is ~32000 ns- plenty good for Mesa usage, longer than I'd like. That's the result of following this thread's guidance and the usual disabling of power management in the BIOS.

My actual contribution is around video drivers. Re jitter, fbdev works great (albeit slow), the legacy Intel and KMS/modesetting drivers were terrible- latency well over 100000 ns. I'm guessing that's why you see the "nomodeset" kernel option listed. In my case, I found that disabling glamor in xorg.conf lets you use modesetting with seemingly (placebo effect?) better performance, but without any hit to jitter:

Maybe these videos made by TheFeralEngineer help (There are multiple parts to each of these):

Hi
I recently bought a cheap desktop CNC router as I couldn't afford a big one, and I need a decent video tutorial to show me how to setup the software and get Gcode as well as how to run jobs on the 3018 CNC machine via Linux.

Any one know of any videos that will get me up and running without going into the history of either Linux or the router?

Best regards

Fabian.

 

The current release is now 1.0.3 and all the tutorial videos are here .

Recently we have added examples of operations that use parameters set in the GUI similar to the old NGCGUI but better.

JT

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.

 

Does it follow that since any of the Gmoccapy sims open, that the problem does not lie with the kernel?

The problem, to the uninitiated, is what stepconf wizard produces.

I'll try to make a better model tomorrow, but maybe the attached shows the gist of it better in cross section. The desired end result is a rectangular pocket. The result is as shown with the undercuts. The tops of both walls are in the right spots and of the correct thickness. The +Y wall is fine all the way down, the -Y wall is not. The end mill was a YG1 E5G98910 (3/8" diameter, 2-1/8" LBS, and 1/2" LOC, with a 0.345" shank, so it is possible for it to make some degree of undercut without rubbing). I'll see if I can measure how extreme the undercuts are tomorrow.

Cutting an internal pocket, climb cuts. The original material was a solid piece.

Possible multiple axes have errors, but I'm not seeing evidence of it. The one dimension in X I can measure is correct and shows no signs of misalignment between Z passes.


I agree this smells like a hardware issue- if so, it'll probably be a bear to track down. The motors are ClearPath servos, driven in quadrature mode. I believe the signals are 5V from the Mesa board, but would have to double check that. If there's some kind of encoder error, it's internal to the motor.

The cables are as provided from Teknic: motor -> cable -> soldered joint to circular connector -> connector -> soldered joint on other end of connector -> ferrule to 7i76E screw terminal. X and Y cables do run adjacent to one another (and power cables) for a few feet, and they're not shielded- though Teknic also sells 55' unshielded cables, so one might infer they don't believe it's important.

What's really hanging me up is that it seems to return to the correct place in +Y, despite apparently cutting incorrectly a variable amount in -Y.


Either way, I'll double check nothing is mechanically loose tomorrow (that would be the nicest answer) and put a scope on the Y axis signals while jogging X around, see what kind of cross-talk I get. I already got LinuxCNC 2.9.3 installed.

ETA: Mechanics appear fine- I can lean/pull on the Y axis and it'll move maybe 0.001", then springs back when I release it. Leadscrew retention nut appears tight.

Do let me know if things are still unclear.

Hey guys. I wonder if someone could assist me in nutting a problem in my configuration. I know the layout of the config has more than one problem, and i plan to learn better how to fix this myself, however as long as i have the axis' dialled in and the servo spindle controlled through the software i am a-ok with not having spindle orientation and extras setup until I better understand the Hal configurations. 

I have been running Probe Basic as a 3 axis stepper driven mill configuration, 3 homing switches for a year using the standard mill motor spindle and that has worked fine. I have just installed a Servo Motor to drive the spindle and now for some reason I am getting a joint following error when homing any axis. 

I have had the servo spindle working in a test file, (both Axis and probe basic GUIs),but when combined together in the previously working Probe Basic config I have issues. 

I have a feeling it might be something that is related to the post-gui file, as in an attempt to chase errors I was getting I have consolidated a not task that was conflicting, and I have reached to end of my limited knowledge.

I am working regularly to better understand the control flow within linuxcnc, but for now, if i was just able to get a minimal running configuration sorted I could at least use the machine whilst i gain that better knowledge. 

Thanks very much,
Bruno