stepgen
gnipsel.com/files/0001-increase-stepgen-to-16.patch
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...hb=refs/heads/master
Thanks
JT
Please Log in or Create an account to join the conversation.
+/*int step_type[MAX_CHAN] = { -1, -1, -1, -1, -1, -1, -1, -1, -1 };*/
+int step_type[MAX_CHAN] = { [0 ... MAX_CHAN-1] = -1 } ;
The method of array initialisation you first used is the C89 standard across all compilers
The method you then went for is peculiar to gcc and may require C99 to work
Try int step_type[] = { [0 ... MAX_CHAN-1] = -1 } ;
since you don't need to specify the array size when you are spelling it out in the initialiser
Otherwise I would stick with the old-fashioned method you used initially and then commented out.
regards
Please Log in or Create an account to join the conversation.
If you had a really big array all the same value, would be easier to memset() it after declaration, than write out all the initialisers.
I have given up using any of the newer array initialisation methods with Linuxcnc, because I keep getting bitten by the requirement for extra switches to the compiler
when they are compiled using comp.
The favourite one is ISO C90 forbids variable-size array so requires the -std=C99 switch, which comp does not use, so the code is not portable.
regards
Please Log in or Create an account to join the conversation.
There was a suggestion on the IRC to increase the stepgen to 16 from the current 8 to be more inline with pid.
Why have a limit at all?
if there has to be a limit, then why not 18, for a 9-axis gantry configuration?
It is possibly to assign arrays at run-time in C (just slightly more troublesome) so there is no real reason to impose a limit.
Please Log in or Create an account to join the conversation.
There was a suggestion on the IRC to increase the stepgen to 16 from the current 8 to be more inline with pid.
Why have a limit at all?
if there has to be a limit, then why not 18, for a 9-axis gantry configuration?
It is possibly to assign arrays at run-time in C (just slightly more troublesome) so there is no real reason to impose a limit.
That's beyond my guesspertice level in C... JT hands the baton off to Andy.
JT
Please Log in or Create an account to join the conversation.
It is possibly to assign arrays at run-time in C (just slightly more troublesome) so there is no real reason to impose a limit.
The way the code is written at present, prevents unlimited arrays because it is parsing the commandline with RTAPI_MP_ARRAY_XXXX which requires a number as an argument to be already decided, hence the MAX_CHAN #define.
The way around this might be to have the first argument as the number of channels and then use that to assign the arrays for step_type and ctrl_type
I'll have a play and see what happens
regards
Please Log in or Create an account to join the conversation.
The way the code is written at present, prevents unlimited arrays because it is parsing the commandline with RTAPI_MP_ARRAY_XXXX which requires a number as an argument to be already decided, hence the MAX_CHAN #define.
Ah, yes. And MP_STRING unhelpfully breaks at commas (I think) so we can't parse p,p,p,p,p,p as a string and just count entries.
Please Log in or Create an account to join the conversation.
Ah, yes. And MP_STRING unhelpfully breaks at commas (I think) so we can't parse p,p,p,p,p,p as a string and just count entries.
That is actually what I did, I used RTAI_MP_STRING to collect the params and used a : delimiter so I got a string (or at least I think I would have done)
Then parsed that for the number required, but could not use a variable to initialise arrays, so had to create arrays of pointers to hal_malloc'd data......
and then just thought why bother, it is miles simpler just to set MAX_CHAN to a number higher than we need and if that changes, increase it.
Please Log in or Create an account to join the conversation.