You could use any aggregate function to complete the query and ignore that if you used a second (SELECT) query and ignore the calculated field. However the number and names of the ct fields will be volatile so you can't simply have a calculated field in your select like [1H] & "-" & [20S] because it doesn't exist for most records and there's no guarantee that it will in the future either. If you have a limited number of possibilities you can define them so as to make these fields static and then include them all in one query calculated field. Null results would be ignored. There are some query wizards here (IMO) who might find this simple but that's not my strength. I always seem to see the code tree in the forest of possibilities. If there are a lot of PS values, then I think code would be more practical than complex calculations if fields that you have to maintain every time you have to deal with a new PS value that's been introduced.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.