Strange behaviour of custom component

Grotius
Offline
Platinum Member

11 Apr 2025 19:41 #326101 by Grotius

Replied by Grotius on topic Strange behaviour of custom component

@Endian,

Ever thought about writing components in c code instead of halcompile code?
I bet writing in c will relax your code. You can also ask DeepSeek to write c code, then
compile it with cmake, and you are off.
I have old examples, if interested.

I don't see any memory allocation for multiple instances of the component at the moment.
If you like at threads.c you can see RTAPI... is used for setting up multiple threads.

The following user(s) said Thank You: endian

Please Log in or Create an account to join the conversation.

endian
Topic Author
Offline
Elite Member

11 Apr 2025 20:10 #326104 by endian

Replied by endian on topic Strange behaviour of custom component

Yes I have to start ... I have planty of ideas but I am aware little bit to code them over halcompile...

Yes defenetly I am interested even in all which should improve our skills ... can you provide me them please?

thanks...

The following user(s) said Thank You: Grotius

Please Log in or Create an account to join the conversation.

Hakan
Offline
Platinum Member

11 Apr 2025 20:18 - 11 Apr 2025 20:19 #326107 by Hakan

Replied by Hakan on topic Strange behaviour of custom component

You can test with "halcomp --preprocess a*.comp" and look at the a*.c code.
I would not think that is any easier, but Grotius is on another level so what do I know.

Anyways, endian, a start would be to go away from enum, it doesn't seem to work well.
Remove those four-five lines and put in here, just before the ;;

// opmode constants

variable char modeSwap;
variable char homeState;
;;

And further down, below positionModeStatus, put in defines instead of the enums.

#define positionModeStatus                                              16

#define WRITEMODE 0
#define WAITVELOMODE 1
#define INITIAL 2
#define WORKING 3
#define WAITINGFORENABLE 4
#define HOMING 5

#define HOMETRIGGER 0
#define HOMECONFIRM 1
#define HOMESEEKING 2

At least it compiles. Feel free to butcher the code any way you like.]

Last edit: 11 Apr 2025 20:19 by Hakan.

The following user(s) said Thank You: Grotius, endian

Please Log in or Create an account to join the conversation.

Grotius
Offline
Platinum Member

11 Apr 2025 21:14 #326116 by Grotius

Replied by Grotius on topic Strange behaviour of custom component

Hi,

but Grotius is on another level so what do I know.
I am on the same level as you Hakan.

Halcompile preprocess gives you bad c code. The preprocess option can be helpfull in some cases,
like reverse engineering a component.

This is a cmake project for a component called "test", i made years ago. It can be used for linuxcnc directly.

codeberg.org/skynet/hal-core/src/branch/.../test/CMakeLists.txt

here should be "linuxcnchal"
your relative paths to linuxcnc dirs
Then this is the function to write your home sequence in.
This is how you load the component in hal.

Then you can look at threads.c source code to use RTAPI ... text's inside the c code, so you can use
multiple instances of the component.

Just ask DeepSeek to add this feature to the test.c file and tell it what you want.
Do it step by step, and test so now and then. In fact it's quite easy.

If you don't succeed in 24hours, i will do it for you.

The following user(s) said Thank You: endian

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

11 Apr 2025 21:34 #326119 by andypugh

Replied by andypugh on topic Strange behaviour of custom component

endian wrote:
Okay I got it... But how to customize them to not hard code them

In this case the answer is simple, just move the two variables above the ;; separator and create them as parameters. Then you will end up with independent static variables for each instance of the component.

So:

;;
...
enum MODESWAP{WRITEMODE, WAITVELOMODE, INITIAL, WORKING, WAITINGFORENABLE, HOMING};
enum MODESWAP modeSwap;
enum HOMESTATE{HOMETRIGGER, HOMECONFIRM, HOMESEEKING};
enum HOMESTATE homeState;

becomes

param out unsigned modeSwap;
param out unsigned homeState;
...
;;

You _may_ still be able to use the enum, that would be something I would experiment with to find out. If not you could create the state names as macros to preserve readability. (but you can always use something like:

switch(modeSwap){
   case 1: // Waiting
...
   case 10: // Exploding

)

The following user(s) said Thank You: endian

Please Log in or Create an account to join the conversation.

Time to create page: 0.442 seconds