Getting error when installing a homebrew component

ArcEye:
What do you mean by moving the functions inline? Do you mean one large function that contains everything instead of the internal calls to other functions? I'll probably give that a shot.

Exactly that. When the component is polled, it is the main FUNCTION(_){ .... } that is called.

To call another function from within the FUNCTION(_), requires pushing all the existing register values, the function parameters, the base address of the call and the return address from the function onto the stack, jumping to another area of code, doing something then popping all the register values off the stack again and jumping back to the return address.
It can be quite wastefull of time and resources in rt programming, where everything needs to run as quick as possible and return.

There is ample scope for problems, if for instance the memory area used is not in unique posession of the module using it, I don't know if this caused the problems I have had with it, but I now avoid external functions.

If you have a lump of code that needs to be run several times from different stages of the function, you can set a state which runs the code and change the state to that number whenever you want it, to avoid duplication.
eg


But in your component, most of the functions are just querying the value of a bool, which could simply be done directly in the code as required.

regards

Thanks ArcEye,

I have done that. I have some other nagging problems still remaining, but I'll start a new thread. I appreciate the help!

Mr. Technical

Hi Mick
I see that you referred to userspace component rather than RT. Is there some documentation to read that will tell the difference between the two or compare them?

Hi

I expect there are some good articles out there, I don't think there is anything specific under the Linuxcnc docs.
The major differences are memory allocation and which 'ring' the code runs in.

The big practical differences as far as components go are, the speed that the component needs to run and the resources it needs to access.

A toolchanger waiting for a single trigger pulse to get the tool 1 position say, needs to poll frequently with high kernel priority or the pulse may have passed by the next poll.
It is liable to be restricted to doing its interaction via HAL pins, which is fine for that sort of component

A serial link which updates a remote DRO will find it far more important that it can access all the standard serial libs for port access and being limited to only updating data say 4 times a second, is not really a limitation, it would take the operator longer than that to read the figure and mentally process it.
The other big plus with userspace is that you can use GUI programming libs and anything else you would do in a 'normal' program, so the options for display and processing the data are greatly increased.

The mechanics of writing a rt or userspace component using comp are probably best explored through the sources and the comp docs.

The rt component uses the FUNCTION(_) macro, that is the function which gets called each poll.

A userspace component uses the user_mainloop() function and within it the FOR_ALL_INSTS() macro (for all instances)

That is just a potted overview, hopefully start you off

regards

Good explanation, thanks man.