Fixed xtce typo and updated codice xtce files

[GFMoraga]

Change Summary

Fixed a typo in the ccsds_header_xtce_generator.py, ccsds-header.xml and re-ran xtce_generator_codice.py

Overview

This is a simple typo fix

Updated Files

• ccsds_header_xtce_generator.py

  • changed SEG_FLGS to SEQ_FLGS

• ccsds-header.xml

  • changed SEG_FLGS to SEQ_FLGS

• codice xtce files

  • re-ran xtce_generator_codice.py to update all xtce files to fix typo

[maxinelasp]

I'm concerned about the BinaryParameterType -> IntegerParameterType change, is that intentional? I updated telemetery generator to create the BinaryParameterType because I think that's the correct thing, and I need it that way in the GLOWS XTCE. Is that a conflict between the codice requirements?

[maxinelasp]

Why did this change? telemetry generator should do this BinaryParameterType, and not the integer type which it changed to.

[GFMoraga]

Hmmm...I can look into it, I didn't touch anything except the typo issue. The def create_parameter_types didn't change, so I honestly do not know currently.

[GFMoraga]

Ok! So.. @maxinelasp @greglucas the code is correct on my local, but I figured out thet Maxine added or "INT" when she updated the telemetry_generator.py in line 118.
I simply took this away, and codice returned to BinaryParameterType like before. Solutions?

[GFMoraga]

I am going to leave it with Maxines current update. Since this is only codice related right now..we will handle this error when we run into it.

[greglucas]

Are you working from the TLM_COD.xlsx spreadsheet that is in the repo? I see BYTE in the dataType field under the P_COD_HI_INSTRUMENT_COUNTERS tab, so I think that should still fall down to BinaryParameterType.

p.s. if you click on the line number, then expand the three dots you can copy permalink to get a reference to the code spot you're talking about.

imap_processing/tools/xtce_generation/telemetry_generator.py

Line 118 in 01d9a0d

And view the git blame directly in the UI if that is helpful as well.

[greglucas]

OK, I think I see now that I look closer at the code.

"SINT" or "INT" in parameter_type_ref_name

will evaluate to "SINT" if "INT" not in parameter_type_ref_name. Which then in turn evaluates to True, and thus we never hit the BYTE path.

I think it might need to be something more like this:

any(x in parameter_type_ref_name for x in ["SINT", "INT"])

[GFMoraga]

I can fix it in this PR, but would need guidance. I kinda see what you mean here Greg, but I also haven't built many any statements with for loops.

[GFMoraga]

Wait! I think I got it!

[greglucas]

Actually, it might just be easier to change the order or lookup around. What is parameter_type_ref_name is it just a string, or is it a tuple/set/list?

A few options for you:

elif "INT" in parameter_type_ref_name:

or

elif parameter_type_ref_name in ["SINT", "INT"]:

[GFMoraga]

I just made a new commit! It seemed to fix this issue.

[bourque]

Thanks for making this quick fix! This will help me on #184

[greglucas]

I agree with @maxinelasp about the BinaryParameterType change and removing the unused file.

I am guessing you may have run this with an older version of the file you had around somewhere, or haven't rebased this on upstream/dev so those changes aren't in your local file.

[GFMoraga]

Ive never used codecov. How do I fix this check?

codecov/patch — 94.24% of diff hit (target 94.66%)
codecov/project — 94.33% (-0.33%) compared to 690038f

I figured out a solution and took comments seriously

[maxinelasp]

LGTM, thanks for investigating the binary type issue

[GFMoraga]

I tried to look into codecov..but I couldn't figure it out..so I merged because I was at a 94.24%. Maybe @greglucas you can help me understand this for future PRs?