NASA LabVIEW User Group Meeting 9/22/22 (Progress in Test for Space)

[McCarty]

In this meeting, Dr. Jeremy Marquis discussed some of the test systems and software architectures which G Systems has developed for spacecraft, satellites, and satellite deployment systems.  In particular, he shared examples of the following:

• Three structural test systems for the Orion Multi-Purpose Crew Vehicle (MPCV)
• An architecture to facilitate communication between existing test operations software and multiple Electrical Ground Support Equipment (EGSE) systems

Congratulations to all who have supported the Artemis program at NASA.  We look forward to a successful first launch on September 27th!

The Testing We Need to Get to Mars

https://www.ni.com/en-us/perspectives/the-testing-we-need-to-get-to-mars.html 

To the Moon and Back

https://www.ni.com/en-us/perspectives/to-the-moon-and-back.html

OutPerform

https://insights.ni.com/outperform/?sf170163837=1 

[RVallieu]

This was an excellent meeting.

I was playing around this afternoon with recreating JSON data packet with TCP after the presentation - pretty interesting idea.  I of course have thought of questions after the fact.

Jeremy mentioned that they perform polling on the TCP loops.  The structure of their messages is Command String, JSON String.  I am curious why they took the polling approach rather than adding I32 Command Size and I32 JSON Data Packet Size to be sent before the Command and Data and then leverage using more event based style TCP waits where the 4-byte data reads could be set to either a long timeout or -1 and then the full data packet for the CMD or the JSON string could be read without the need to poll/interpret end of data.

This would still allow for variable length string commands and JSON packets, but make the transmission protocol a bit easier.

[Jeremy_Marquis]

Ryan,

We did prefix the packet with the packet length in a fixed size.  While this makes reading the remainder of the packet straightforward, unfortunately you still have to poll for the prefix.

Since the network actor needed to do other things also (e.g. publish data out), we used a short timeout on the TCP Read that waited on the incoming command packet data length so that we didn't block processing other tasks.  Note setting the TCP Read to "Buffered" mode will not return data unless all bytes requested are received, we used this for reading the data length prefix.

Jeremy

[RVallieu]

Ok that makes much more sense.