LinuxCNC GCC C hal_float_t NOT properly aligned ?

Hi,
I've created simple HAL component in C++ there www.linuxcnc.org/index.php/english/forum...nt-compilation#47367 , but when added a few more pins to my kins RT component written in C (eneurokins.c):

typedef struct thaldata {
hal_float_t *md; // Machine diameter
hal_float_t *mp; // Machine path
hal_float_t *cx, *cy, *cz; // G-code cartesian coords
hal_float_t *ml, *mr, *mz; // Machine coords
} thaldata;

everything works with LinuxCNC axis configured to use those eneurokins kinematics component, but strange things happends when loading my own user space eneurokinsd.cpp component with HAL interface written in C++:

$ halcmd loadusr eneurokinsd
eneurokinsd: ml: 0.0000 mr: 14.1421 mz: 10.0000 cx: 10.000000 cy: 10.000000 : 10.000000 md: 0.000000 mp: -nan
eneurokinsd: ml: 0.0000 mr: 14.1421 mz: 10.0000 cx: 10.000000 cy: 10.000000 cz: 10.000000 md: 0.0000 mp: -nan
eneurokinsd: ml: 0.0000 mr: 14.1421 mz: 10.0000 cx: 10.000000 cy: 10.000000 cz: 10.000000 md: 0.0000 mp: -nan

Axis interface stops working and displays those strange -nan too.

I've found such news group post:
Re: [Emc-commit] master: work around a gcc bug in order to properly align hal_float_t
but it has date: 2009-11-23 14:26

What do you thing, is it possible that it is a gcc bug?

The bug has two faces. First, structure size mismatches between C and
C++. This affects programs which have C and C++ parts and which use a
structure with hal_float_t that happens to be unaligned.

I will try to change my eneurokins RT HAL component to C++, but is it possible this is the case of hal_float_t structure size mismatch between C and C++ ?

regards.

andypugh wrote:

I think it is more likely a divide-by-zero error in your kinematics file.

I do not think so, while those configured kins works without any problems with linuxcnc axis and I can read its pins using halmeter when in MDI mode G-code is entered.
Those -nan shows when this user space component is loaded which creates a few signals to read my kins I/O pins.
I think I will move all those hal_float_t pins to its own structures:

typedef struct float_data_t {
hal_float_t *pin;
} kins_float_t;
...
static kins_float_t *kmp= NULL;
...
#define MP (*(kmp->pin))
...
kmp = (kins_float_t*)hal_malloc(sizeof(kins_float_t));
...
if((ret = hal_pin_float_new(eneurokinsd_mp, HAL_IN, &(kmp->pin), comp_id)) < 0) goto error;
...
double mp;
mp= MP;

However, I've dit it this user space HAL component in my C++ app with all kins pins, but still have those -nan when loaded after linuxcnc and axis starts.
Maybe I will try to change also those hal_float_t in my kins component to its own structures like I've did with kver & kmp so far:

struct haldata {
hal_float_t *md, // Machine diameter
*cx, *cy, *cz, // G-code cartesian coords
*ml, *mr, *mz; // Machine coords

} *haldata= 0;

static kins_float_t *kver= NULL; // Version
static kins_float_t *kmp= NULL; // Machine path

Update: It does not help when started after those changes, it looks like ver, md is cleared by this user space eneurokinsd and mp is set to -nan

$ ./eneurokinsd
./eneurokinsd: HAL component: eneurokinsd init: comp id: 20
eneurokinsd: ver: 0.0000 ml: 0.0000 mr: 14.1421 mz: 10.0000 cx: 10.000000 cy: 10.000000 cz: 10.000000 md: 0.000000 mp: -nan

BTW: I will remove this pin machine path eneurokins.mp from my kins while I've dit it to try to catch machine tool path length during milling tracking XYZ forward/inwerse kins functions calls.
Maybe there is another way to find this tool path which I'd like to use to estimate % of G-code job done and time left to finish job while total tool path could be known from CAM tool or CAE which created G-Code ?

andypugh wrote:

I think you will need to explain the symptoms on the developers mailing list where the guys who understand HAL and RTAPI are.

I've changed my user space Hal component from C++ to C source code, removed eneurokins.mp compiled and now it looks like it works-there is no those strange -nan, but eneurokins.ver pin in my kins is overwritten to 0, however setting this signal using halcmd :

$ halcmd sets eneurokinsver 20140528.0009

works as expected and I'm able to issue MDI mode G-code and my user space HAL C component reads in 1s delays those coords set in my custom kins during milling job controlled by linuxcnc axis, so I can use this data in my visualisation openGL app on remote work station

Maybe those -nan are from these "rtapi_math" and I missed something in my kins-I use sqrt,sin,cos,asin,acos for the moment?
It looks like while this custom eneurokins component is loaded in linuxcnc axis, those forward/inverse kinematics functions are called not only when eg.: MDI G-code is entered and milling job started, but all the time.
Maybe I should use RTAPI mutexes?
While I only wanted to read those pins in my user space HAL enabled app I simply connect pins to signal and use its pointer to read kins pins:

double ml= (*(kml->pin));

I will see if this problem will apear on other LinuxCNC PC machine-just configuring diskless LinuxCNC boot network server with NFS exported rootfs to test it on other machines

andypugh wrote:

git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ebcf919032553f87d99f

It explains everything
My change in this function of my eneurokins RT component, where machine diameter pin eneurokins.md was set to.... 0.0 (like other pins) during this signal linking, which caused of course division by zero here:

int kinematicsForward(const double *joints,
EmcPose * pos,
const KINEMATICS_FORWARD_FLAGS * fflags,
KINEMATICS_INVERSE_FLAGS * iflags)
{
...
double R,D;
int ret= 0;

D= md; // Changed this it was before: D= (*(kmd->pin)); or D= (*(haldata->md)); and this generated -nan's
R= D/2;

l= joints[0];
r= joints[1];
z= joints[2];

// l= a*R
a= l/R;
x= r*cos(a);
y= r*sin(a);
...

I was sure, that linking pin to new signal does not change its value set during kins component initialization but it looks like it does and sets it to 0.0 for this hal_float_t

So far, a new signal value defaulted to 0/0.0/false regardless of
the pin's values linked to it.

old behavior: a pin's default value would be overwritten by a signal value
on link, effectively making the default pin value invisible outside the
component, and potentially causing a jump in the pin's value on link.

In my changed version of those kins I've harcoded for the moment this machine diameter md used in kinetics calculations,
so now it does not matter that signal linking clears it

static kins_float_t *kmd= NULL; // Machine diameter
#define MDdefault (2*meter)

static double md= MDdefault;

Then in my forward/inverse kinetics functions simply overwrite it, so if I add overwrite to this eneurokins.ver I should see proper version number not 0.0

// Update Hal info
MD= md;

ML= l;
MR= r;
MZ= z;

CX= x;
CY= y;
CZ= z;

Thank you very much, this HAL link/unlink signal details was a key to understand why those -nan affected CX CY G-code coordinates in forward kinetics and ML in inverse and other default pin values

Now LinuxCNC with Axis and my kins works as wanted to:

It is time to connect this eneurokinsd user space kins daemon with adjustable output frame rate eneurokinsd.fps to my OpenGL machine visualisation software on external workstations with other Linux distro over compressed secure SSH channel.