Saving parameters after shut down

It's above my pay grade but I will give it a bash.
What happens if Lcnc does not shut down from the UI. On my machine the bios will shut down all open programs when the power button is pressed before it actually does the power down.

Andy Pugh wrote:

Why not put "restore" and "save" in the SIGINT and SIGTERM routines?
(I _think_ that the contents of the shared memory are retained until everything has quit)

I had considered something similar, but it was becoming too specific.

I use the signal() function to try to make sure that the user_mainloop finishes cleanly, no matter what the cause was.

If I put write code in it, it would overwrite the file with whatever was in the spin_boxes, even if it was garbage, so I left it as requiring some form of conscious trigger.

It could be done that way, but there might be downsides as well as advantages. Perhaps a component really should be modular and only requiring connections to pins?

Up to you I can do it either way

I think - so all may benefit, it has to be modular. One component for the file handler and one for the trigger generator. The file handler could have a parameter that will specify the number of variables stored and one has to connect the hal pins to the right pin number in order to retrieve or save your variables. Ten or twenty or however many you set the parameter for at the same time. The user must determine the sequence by naming it correctly. This way any of the new pyvcp param pins can be used. Even for labels.
Am I making sense?

This is a 'one off' for your requirements at present.

It could certainly be made more generic by creating N parameter pins at load time.
I would have to implement it differently, by indexing through an array of pins so that the number does not have to be known initially.
I did something similar recently.

I take it works OK as is for your current requirement?

I did not test the latest code that you posted today as I am busy fighting with the THC component to react to my inputs. Once I get the THC to work, I will complete the config with the parameter saving as the last thing to do.
Debugging these things live is a real challenge and not pleasant at the best of times.

Yeah, trying to debug physical connections on a machine is loads of fun

Well by the time you get to it, I might have finished the generic component.

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.

The RT module parameter macros don't work for userspace components, so need to see if I can parse the command line before the pins are created.

regards

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

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