Advanced Search

faaaasteeer!


Very nice. now I have questions on the spindle though, hahaha.

I did some further testing today, switched from Cinnamon to KDE, which runs much better and even better than XFCE. Here are the results of my stress testing, running for a couple of hours with 8 glxgears, two YouTube videos constantly playing, working with FreeCAD for my new machine design, and doing some compiling in the background.
Please notice that I run KDE on Wayland. When running on X11 the results are worse. The runtime of the test in the screenshot was only 4 minutes, but that was where the graphs had stabilized already. It looked the same after hours.

 

Below is the same test setup, but now with only isolcpus=3.
 

I believe I have the same N100 mini PC. Here are the results of my stress testing, running for a couple of hours with 8 glxgears, two YouTube videos constantly playing, working with FreeCAD for my new machine design, and doing some compiling in the background.

I running on Debian 13 (Trixie, weekly build; so far absolutely stable despite being not released yet), running KDE and LinuxCNC 2.9.3-1+b2

 

Hi PCW,

thx for your effort.

OK-- I just realise your strategy : We tested P1 and found the Hardware OK at P1 and than I fell into a trap with the loopback ---I assumed we were going to something similar to what you have been suggesting in

forum.linuxcnc.org/38-general-linuxcnc-q...-modbus-help?start=0

loop the onboard rs-485 to the pktUARTS on P1 so yesterdays results were the results of such a test.

But you wanted me to test a direct loopback from RX+ to TX+ and RX- to TX- of the onboard RS-485 -- sry my fault

The result of this test is:

without loopback:
0000EBFF
00002BFF
00006BFF
with loopback:
0000EBFF
00000BFF
00006BFF

 

So to give you a clear idea of my understanding of how things work.

1. before homing the controller is in 'joint' mode and axes (eg X,Y,Z,...) do not exist
2. a successful homing procedure ends with the joints being in a known position (ie each joint position is either zero or offset by the OFFSET or HOME_OFFSET values set in the [JOINT_n] section of your ini file or has a known position from an absolute encoder)
3. these joint position values are then passed to the Forward kinematic model which calculates the initial values for the axes position.
4. Axes are created as setup in the ini file (eg X, Y, Z) and are initialized with the values calculated in step 3
5. The trajectory planner calculates the axis positions and passes them on to the Inverse kinematic model which calculates the joint position values to be passed on to the motor drives (eg by way of step generators, ethercat command, analog voltage, etc).

Is it a correct assumption that the forward transformation is only called when homing the machine - and beyond that is not referenced?

That is what I _think_ is happening but I'm not positive. If you home your machine manually I wonder if you could simply set the cartesian position to zero in your forward kinematics:

As long as you have no OFFSET or HOME_OFFSET values set in the [JOINT_n] section of your ini file then that should give you a cartesian coordinate of X0/Y0 for joint0.pos_fb = 0/ oint_1.pos_fb = 0. But again I'm really not sure as to what actually happens behind the scenes which I think is here:
github.com/LinuxCNC/linuxcnc/blob/master...emc/motion/control.c

I have a ryzen 5 1600 on a b350 (or 450 can't remember) and a ryzen 2600 on an a320 (or whatever the cheapest board was at the time)

Both show numbers around what you are seeing and work great!

Thanks that worked, also the +5V GND on the encoder section also works. No need to provide separate power to MPG.

thanks

The Inverse kinematics can be solved purely by math so that's what I did. I'm new to Newton Raphison - this was my first time using it so I only used it for the forward kinematics.  I wrote a simple processing program to try to confirm the math and that seems to yield correct values. But your explaination makes sense. 

Is it a correct assumption that the forward transformation is only called when homing the machine - and beyond that is not referenced?  In my case, with the cable robot it is not possible to add "home" switches to each of the joints so my current strategy is to manually drive the unit to 0,0 and then home manually.

I'm still confused on how LinuxCNC uses the forward and inverse. I will look for an explaination on why the forward transformation and inverse are yielding different values. 

Thanks for your input!! 

Alright here is a short video of these servos running.

Didn't realise how long it has been since posting here.

A lot of things have happened to the mill and on Friday I finally made its first very slow chips in a long long time.

Z axis motor took me some figuring out as the servo drive was not as basic as the X and Y motors.

Have wired up the hydraulic pump and got the tool clamp functional, have kept this running analogue style with just switches and relays for now. Can change to PC control down the track.

Have a tool setter and probe fitted although the probe was DOA from AliExpress so had to arrange another.

Still working on linking my physical buttons on my control panel as well as the biggest task of getting the gearbox running which I have had a few goes at now. I am finally getting some progress on a classic ladder solution for this so hopefully not too far off now.
​​​​​

Hi all.
Been stumbling around classic ladder learning the basics to add functions to my mill.
I have a question. How do you go about linking a pin to multiple signals or the inverse?
I have a spindle break button as a momentary switch on my control panel which I would like to turn on and off the spindle brake. I have been unsuccessful so far at the pin on the mesa card is already driven by another signal coming from HAL
​​
There must be a way to do this as plenty of people have physical buttons as well as buttons inside the gui.

Thanks in advance.
 

I'm afraid I don't have time to debug your kinematic model but it looks like your forward and your inverse kinematic models are not 'inverse' to one another and so a joint position of 0/0 (ie after homing) does not result in a cartesian position of X0/Y0 and vice versa as it should.
Note how the Joint1 position has run away after homing:

 

I'm not really familiar with using Jacobian matrices but I would have expected the forward kinematics to use the jacobian matrix and then invert that to derive the inverse kinematics. You seem to use the jacobian for the forward kinematics only.

So, in the '5-axis table dual rotary' simulation, which hal pins are you seeing this change in value when you switch between Manual and MDI mode?

[edit]
Here is  how I'm trying to reproduce the issue:
 

I've been running it for a while and it's been solid with a mesa card.
setting the irq affinity is important, other than that - pretty much no special tuning.

see here also:
forum.linuxcnc.org/18-computer/51678-lin...tel-n100-cpu?start=0