Saving parameters after shut down

More
14 May 2013 19:47 #34076 by mariusl
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.

Regards
Marius


www.bluearccnc.com

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

More
14 May 2013 20:03 #34080 by ArcEye
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

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

More
14 May 2013 22:47 #34085 by mariusl
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?

Regards
Marius


www.bluearccnc.com

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

More
14 May 2013 23:03 #34086 by ArcEye
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?

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

More
15 May 2013 04:24 #34099 by mariusl
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.

Regards
Marius


www.bluearccnc.com

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

More
15 May 2013 14:59 #34116 by ArcEye
Yeah, trying to debug physical connections on a machine is loads of fun B)

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

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

More
15 May 2013 16:15 #34120 by andypugh

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

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

More
15 May 2013 16:37 #34121 by ArcEye
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

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

More
15 May 2013 16:42 #34122 by andypugh

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

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

More
15 May 2013 16:59 #34123 by ArcEye
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:

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

Time to create page: 0.277 seconds
Powered by Kunena Forum