Common Naming Reference?

Joe Kale

unread,

Mar 12, 2021, 9:40:40 PM3/12/21

to F´ Community Group

Is there a reference for common naming conventions in F'? I have recently been struggling with compilation issues because of port names that were copied from other components that must have been specific to the component.

As an example in the Ref project, in Command Reply ports, there seems to be 2 names: CmdStatus and cmdResponseOut. Event Loggers use Log, logOut, and eventOut.

Peet, Sterling L

unread,

Mar 13, 2021, 6:51:32 PM3/13/21

to Joe Kale, F´ Community Group

Hi Joe,

The first place to look for these sorts of naming conventions is the F Prime Users Guide: https://nasa.github.io/fprime/UsersGuide/guide.html

I am guessing that you are actually asking about how the name of “special” port is generated by the Autocoder. In this case, if a port of a certain type is needed by a component (e.g: you have defined a telemetry channel, so you need a Fw::Tlm typed port), then the autocoder will first check if one is specified in the component’s Ai.xml file. If so, it will use it, and if not, it will create one for the component using the default name.

This means that older, legacy, built-in components might have a non-standard name for these ports, and they will still work properly without re-writing the component. It also means that they might not match the names of ports that are automatically generated for your custom components.

When I need to look at this type of information, I will reference the default configuration for the autocoder found here: https://github.com/nasa/fprime/blob/devel/Autocoders/Python/src/fprime_ac/utils/ConfigManager.py

Inspecting this file tells us that the default port name is generated from this configuration line item: self.__prop["special_ports"]["Telemetry"]["name"] = "Tlm"

So you can expect your component to have a port named Tlm that should be connected to your telemetry handling component.

If you have worked with topologies much at all, you will find that they are large, sometimes rather complicated, and seem to have a lot of moving parts. There is good news, I am partnering with the guys at JPL to build a linter for F Prime, and you can beta test it today. It can tell you about a few things that might be wrong, including ports that are unconnected in your topology or ports that are connected to a non-existent component.

The linter is part of an add-on toolset for F Prime, under development here: https://github.com/SterlingPeet/python-fprime-extras/tree/devel

If you try it out, make sure that you check out the devel branch before running pip install . in the F Prime venv.

Let us know if this helps, or if you need some other hints.

Thanks,

Sterling Peet

Space Systems Design Lab at Aerospace Engineering
Engineering Science and Mechanics Building
Georgia Institute of Technology
620 Cherry St. N.W. Atlanta GA 30332

Web: http://ssdl.gatech.edu/sterling-peet
Ph: (404) 385-7641

On Mar 12, 2021, at 9:40 PM, Joe Kale <joe.ka...@gmail.com> wrote:

Is there a reference for common naming conventions in F'? I have recently been struggling with compilation issues because of port names that were copied from other components that must have been specific to the component.

As an example in the Ref project, in Command Reply ports, there seems to be 2 names: CmdStatus and cmdResponseOut. Event Loggers use Log, logOut, and eventOut.

--
You received this message because you are subscribed to the Google Groups "F´ Community Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fprime-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fprime-community/c1a3ef7c-385e-4e89-8dc2-99807b54660bn%40googlegroups.com.

Joe Kale

unread,

Mar 14, 2021, 1:38:14 PM3/14/21

to F´ Community Group

Hi Sterling,

Thank you for this very helpful response. You were correct about what I was asking about so the lead for the autocoder config will help greatly while I'm getting used to things.

I will certainly be looking into your linter as well. I started with a rather simple custom component so much of my debugging has been with mistakes in my topology and that should help save me some time.