Advanced Search

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

Here is a more stable version (in my opinion).
But the calculation problem is still there (on my computer).

A cosa potrebbe essere dovuto? Cosa significano queste uscite danneggiate? Perché "sembra" che i motori facciano quello che dovrebbero fare, o almeno credo. Stai dicendo che devo comprarne uno nuovo?

pippin88 wrote:

isolcpus does not disable cores

isolcpus isolates designated cores from the general scheduler
So routine tasks won't be assigned to those cores. E.g. web browser running in the background won't take CPU time on isolated cores

Yes, that is what I actually meant, but you found a more correct way to say it I updated the text. Thank you for correcting me!

Isolating cores from the general scheduler and how that impacts latency always feels a bit like black magic to me, and results can vary quite a lot between different processor architectures. I remember using a J1900 board, where isolplus=1,2 gave the best results, which I guess may be related to how the cores are internally arranged on the die in two pairs, cores 0 and 1 being on one half of the die and sharing resources, and cores 2 and 3 sharing the other half. I guess limiting the general scheduler to only use one core per pair has an impact on interrupts and latency. I am not sure how the N100 is internally organized and how that may be impacting latency.
Do you know if there are any articles that explain how exactly LinuxCNC tasks are assigned to isolated cores? I would be interested in learning more about it. The main reason being that I am looking at some Arm based solutions that combine both application processors (e.g. Cortex-A53/55 capable of running Linux) and microcontrollers (e.g. CortexM7/33) in one chip. Some even have a dedicated DSP, which can be an efficient way to handle PIDs and so forth. Although my primary interest in this area is something else than CNC machine control, I think it would be very interesting to see if we could port LinuxCNC to such a platform, where the general Linux part of LinuxCNC can run on a Cortex-A, and where the real-time tasks can be performed on a Cortex-M, independently from the application processor. This separation could free us from Intel and AMD and how their platforms are more geared towards gamers than industrial low latency applications.

isolcpus does not disable cores

isolcpus isolates designated cores from the general scheduler
So routine tasks won't be assigned to those cores. E.g. web browser running in the background won't take CPU time on isolated cores

Thanks for the comments - they were very useful.  Here is what is happening when I try running LinuxCNC with my custom kinematics. 

I am running in simulation mode - no hardware is connected or moving
When I launch LinuxCNC, the GUI only lists Joint0 and Joint[1]  - not X and Y (1st image) 
When I "home" the machine, X and Y appear on the GUI however the position of the unit jumps to x1.106, y1.895 (image 2) 
At the same time, the forward kinematics are executing and coverging, but not exactly where I expected them (very close though) 
Am then getting a "Joint Following Error" and the inverse kinematics are executing but returning zeros for every calculation. 
My cablekins.comp file is attached. 

Any ideas?   
 

ATC chip cover.

Top plate is 1/4" polyethelene; white skirt sections are PETG.  Door, slider mechanism, and motor cover are PETG-CF.

Skirt sections have interlocking tabs, and are edge-glued with epoxy.

After 18 months in the making, the ATC just passed a torture test so I feel like I don't have to hide my shame.

 
 

andypugh wrote:

You could try switching to joint mode (halui.mode.joint ) then homing, but I am not sure that is preferable to unhoming then rehoming.

What is the input that prompts this? Are you literally just working at the command line, or is the rehoming prompted by a soft or hard button?

 

For simple MDI type mill control tasks I prefer real buttons to mouse clicks. So I made this little control panel for ease of use. On the control panel side it's just Arduino code so libraries galore and I found some open source code called Arduino Connector (Thanks Alex from Germany) that allows simple messaging between Arduino world and HAL. The display has multiple modes and in the Jog Mode, the home buttons are associated with the three grey buttons just below the screen.


 

Yeah, from a distance I would guess that U5 (the driver chip  for STEP-/DIR- 0 0..3)
has been damaged as it looks like all 0..3 - pins are bad.