Saving parameters after shut down

ArcEye wrote: Just need to ascertain if I can do things the way I want to inside a userspace .comp file or if it would be better to just write a C component from the outset.

If you want to support a variable number of pins, of a variable datatype, then you need to be working in C.
comp doesn't handle variable-sized arrays, and certainly doesn't understand variable arrays of unions.

In the smart-serial code (which has absolutely no idea how many pins it is going to find, of what type, but it could be literally thousands) I couldn't get a Union to work for me. So I use a struct that contains one of each HAL data type. Only one of them is ever mapped to a HAL pin, and the code decides at run-time which one to use.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...d943aad72448ea5212ed
struct hm2_sserial_pins_t

Thanks Andy

So far I have found 2 errors in the comp file which stop the userinit(argc, argv); function from working.
argv was being assigned to itself instead of argv_ plus another minor typo, no terminating ; to the function declaration.

I am rewriting the generated C code from comp to allow the userinit function to parse the commandline
and populate static ints, which can then set array sizes within the export() pin creation routine.

It is similar in a way to your solution, because they are declared before the commandline is parsed and may end up containing nothing
and not triggering the creation of an array, or even a single pin.

I may then try to reverse engineer my changes and patch comp, or just keep the file I end up with as a template.
See how it goes.

regards

ArcEye wrote: I may then try to reverse engineer my changes and patch comp

Seb already fixed it, I think:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...5c1a465260fe0a39e636

Looks like someone else ran into the same problems that I did.

Yes he has fixed the same userinit() typos in the master, I was using 2.5.2

I know he has already made a more complete change to the struct __comp_state *inst; visibility issue than I did, but that does not seem to be in the pull of the master I have at present.

The reverse engineering I was referring to was the whole way export() gets it values
The problem is whether I have the interest to try to fix all the possible eventualities, having solved my own :laugh:

Hi

Now completed my full paramsaver component

This component will create up to 32 IN pins and 32 OUT pins of each, of types float, s32 and bit.

The OUT pins can be overwritten by reading from a file, enabling components or widgets attached to those pins
to be initialised to known or saved values.

The IN pins can be connected to any suitable component pin or widget pin
The values received at the IN pins can be saved to file making settings persistent between shutdowns.

This comes into its own if you use my amended pyvcp_widgets
www.linuxcnc.org/index.php/english/forum...nbox-in-hal?start=27

Then you can link say the hal-pin of a spinbox to paramsaver.invalueF.00 and the new param-pin of the spinbox to paramsaver.outvalueF.00
Set paramsaver.writetrigger to true and create a file
Set paramsaver.readtrigger to true and the value will be inserted back into the spinbox.

Commandline switches:-

loadusr -W paramsaver f=NN s=NN b=NN filename=xxxxxxx onstart=0/1 onexit=0/1

f=NN number of float pins to create, one of IN and OUT for each

s=NN number of s32 pins to create, one of IN and OUT for each

b=NN number of bit pins to create, one of IN and OUT for each

filename=xxxxxx filename to save under
If none given will default to param.sav
Only input filename, not extension or path
Will be created as /home/username/linuxcnc/xxxxxxxx.sav

onstart=0/1 If set to 1, will load file at startup to populate the OUT pins (defaults to 0)

onexit=0/1 If set to 1 will write to file at shutdown (defaults to 0)



The zip contains a compiled component for 10.04, the C source code and a man page

Compile the source with comp --install --userspace paramsaver.c

Usual caveats - let me know any bugs - I have tested a fair amount and seems OK.


regards

PS
It could do with making more efficient regards memory allocation, for the reasons Andy was outlining regards not being able easily to have dynamic arrays etc in a file compiled by comp.
Works perfectly well as is, just offends the OCD side of my nature. Next job on the jotter.

See later posts for updated zip

ArcEye
Thanks a lot for all your input here and into our lives. This is one of the most welcome components for a long time. I am presenting a CNC/MACH course tomorrow but I will try and test it by the evening.

Thanks again man.