With regard to key structure...
it's a string made up of usually six pairs os characters. EG first pair = building num, 2nd pair = room num, 3rd pair = Instrument type....etc. What makes a good primary key?
Well, this is subjective, of course, but.... what you just described is NOT a good key precisely because (A) it has multiple components and (B) the individual components have separate and independent meaning.
This is probably going to be a case where an autonumbered key is your better choice. The problem with synthesized keys (i.e. made as a composite of other meaningful data) is that you either have duplicated data or an impossibly complex compound key.
In your case, that composite key has meaning. (You said so.) So... suppose some day that you get a request for a report for only those devices of a particular type in a particular building, showing room number. How will your database support that query? OK, the rule is that Access can't tell you anything you didn't tell it first. So to search for the devices, they must exist in a way that you can QUICKLY find them. Ditto, particular buildings.
If this is a single-field key, you have to either break it apart to do the search, which adds a lot of time to the operation. Or you have to have those same elements a second time as individual fields to support a query.
If on the other hand they are already separated, then this is a compound key with six elements. OK, Access allows 10 elements in an index, so you can do this, but you are over 50% of the complexity of the most complex key allowed. It will take you AGES to build proper keys for this table. Not to mention that I'm sure at least a couple of those key elements are merely used as "discriminators" just in case you ever have two of the same type of device from the same manufacturer in the same room in the same building.
Use this concept instead...
table INSTRUMENTS
InstID, PK, autonumber (long)
Bldg, number or code (in the code case, FK to a building table)
Room, number or alphanumeric (depends on your room numbering scheme)
DeviceType, text or code (FK to a device type table)
DeviceMaker, text or code (FK to a device supplier table)
other device data...
Now base your instrumentation tables on that starting point. You might have one table for each TYPE of instrument. This relationship would then be SPARSE in the sense that over the sum of all instrument sub-tables, you would fully reference every instrument at your complex, but no instrument would appear in two sub-tables at once.
However, In my database I can think of lots of examples of fields that do not particularly depend on any others.
If this is true then they don't belong in the database. Or you have incorrectly estimated their dependency. But I'm glad you expressed it as you did. That fact means you at least partially understand one of the aspects of normalization. No element belongs in a table unless it depends on the entire key value and nothing else.
Your earlier question "What makes a good key?" is answered simply. If it is possible to find any key that satisfies this dependency requirement, then it is a good key. If you have to force the issue (have a "discriminator" element to avoid duplicates built from your meaningful key elements) then it is NOT a good key.
I used an earlier example regarding candidate keys. A USA Social Security Number is supposedly unique (excluding identity theft cases). A company could use an employee number or the SSN as a key in a personnel table. Either one would be enough to guarantee uniqueness. External reasons would suggest use of the Employee Number in preference to SSN. But either would be a good key. Both of these are NATURAL keys because both have meaning.
In your case, there is probably no single unique NATURAL key because you have different instrument serial numbers (or maybe some with no serial numbers), different makers, different types, different locations (bldg+room), different model numbers, etc. etc. etc. In this case, you would probably do better (and take up less room) with a GENERATED key (autonumber). This is because taken by themselves, all of your candidate NATURAL keys would fail on grounds of uniqueness, and even a combination would fail without the addition of that discriminator field (to handle duplicate devices in the same room). Therefore, you have NO apparent natural keys.
I think a large part of your problem is that your business model is giving you trouble here. And that is crucial to your success in taming this beast. Do you understand how to determine the nature of the tables you really need? With no disrespect intended, I think you don't - because it sounds like you let some non-tech people define some or all of the 40 tables you mentioned.