A gds feature to edit/create a PrmDb.dat

[SMorettini]

Hey! After some digging, I couldn't spot an easy way to tweak or make a new PrmDb.dat file without running Fprime, setting the parameters and saving them. Got me thinking - what if we build a feature in GDS or a standalone tool to tackle this PrmDb.dat editing business? 🛠️

What's your take? Could it be a game-changer for others? Are any existing plans floating around for this? Let's chat!

[LeStarch]

I think this would be a useful tool!

[timcanham]

The parameters are in the XML dictionary with the intent that somebody could at least generate a set of commands to set all the parameters to their defaults, but we haven't gotten to it yet.

[SMorettini]

Possible solution:

• Add a tab(in fprime-gds) displaying PrmDb content as editable JSON.
• Include a Save button to store changes.
• Minimal effort, high flexibility.

Positive Outcome:

• Enables PrmDb content introspection.
• Facilitates file editing.
• Simple implementation, minimal input form work.

Negative Outcome:

• Potential difficulty in manual JSON editing.
• Assumes infrequent PrmDB changes in fprime-gds. But limited impact due to probably rare editing of the file.

[SMorettini]

... how about a sequence file that could be hand-edited?

I like this idea too.

... That way users can generate the set of commands they like, save them off somewhere, and then generate a sequence binary as they would other commands

I didn't understand what you meant in this part? What you mean with set of commands?

[timcanham]

"The set of commands" means the commands that set the parameter values. If they have different sets of parameters for different scenarios, after they generate a file with the parameter-setting commands for those values, they can store them somewher (like Git) and compile them to send to the spacecraft when they want to use that set.

[SMorettini]

I think your solution doesn't cover the case of the initialization of the PrmDb. From my understanding, your idea is to start the executable on the target and then run the sequence of commands to generate the PrmDb.dat.

I think it's better to have a solution where the PrmDb.dat can be initialized without having the deployment running, that's why I was proposing the solution where in gds the user could generate/edit it. With this functionality it would be possible to upload on the target the initial PrmDb.dat that then can be changed at runtime using the commands.

[timcanham]

I agree - I think both would be good. It's not typical to upload a new PrmDb.dat during flight, but to populate it with commands. Having a ground utility to do this would certainly open that up as an option for testbeds or flight. So I vote for both.

[SterlingPeet]

Seeing as how the direct generation of a seed PrmDb.dat file is new feature that fills a missing functionality, I would focus on that first. An enhancement to the same tool that generates commands or a sequence would be great, and ease the process of creating bulk updates; but wouldn't be closing quite as big of a feature gap.