Any feedback on a Periodic Table VI?

[bluekid239]

Hello! I am a relatively new programmer, but I've learned LabView relatively quickly.  I recently decided to start a new project that would challenge my programming skills, so I've decided to make some VIs that do things with data from all the different elements from the Periodic Table (such as formula mass, for a simple example).  I decided to start with a VI that actually gives the other VIs the information they need.  I've come up with quite a few different examples of information I thought useful, but I thought I'd see what you programmers out there would like on it, considering this can (and should) be used by you guys in your programs.  I haven't completely finished it, but I've gotten the first 4 periods done.  I'll post a copy of it as soon as I figure out how.  Here's a picture of the program so far.

All feedback is nice. The True case is not filled out just yet, I'm waiting to finish the False case first (so I can copy and paste).

[bluekid239]

Whoops, I feel ignorant. Here's the above-mentioned file in the attachment.

[tst]

That VI actually looks pretty good for a beginner (with the cleanly laid out terminals being a big plus).

Comments:

1. I would suggest making the code even cleaner.
2. A common way of ensuring a VI fits in the data flow and doesn't execute is to have an Error In input as well and surround the code in a case structure, so that if there was an error, the code is not executed and the error is passed through. That said, this only usually applies if the code itself can generate an error.
3. Which brings me to the next point. Currently, it looks like the only error you can get is by feeding in a wrong atomic number. One way you can work around this is by changing the input from the atomic number to an enum which will have a list of all the elements. Whether this is appropriate or not is up to you.
4. If you do create that enum, you should make it a typedef. The same applies to your cluster.
5. There are several cases where you build arrays. Instead, you can just use an array constant and fill in the values directly.
6. In fact, you can simplify the entire code if you simply push all the data about an element into a (typedef) cluster and output that cluster. You can then simply have an array of these clusters and index out the correct element instead of having all the constants in the code. This will also free up your connector pane considerably. Of course, it's also possible that you prefer the connector pane to have the outputs separately. In that case, you can still have the array of clusters, which will include everything, and then unbundle the data from the element you created into the outputs.

[smercurio_fc]

I agree that it looks pretty good. One thing that you may want to consider is to have the data reside in a file. A lot of what you're doing is simply spitting out a different value depending on an atomic number. In some cases you're spitting out a different sized array. If I were doing this I'd probably store all the data in an XML file and then I would just need to parse the XML file to read the data for a specific atomic number. This would eliminate the need to have a case for each element. What are we up to now? 110 or something?

[Ben]

---

smercurio_fc wrote:
I agree that it looks pretty good. One thing that you may want to consider is to have the data reside in a file. A lot of what you're doing is simply spitting out a different value depending on an atomic number. In some cases you're spitting out a different sized array. If I were doing this I'd probably store all the data in an XML file and then I would just need to parse the XML file to read the data for a specific atomic number. This would eliminate the need to have a case for each element. What are we up to now? 110 or something?

---

Olivia knows of about 109 but that gives me a chance to make one of my typical "hair-splitting" points.

We only need a U8 for the atomic number.

Ben

[Darin.K]

I agree with the comments so far, I would probably suggest a couple of things.  First, this looks like (I hope) the business end of your application, not a user interface (ie. your user interface will call this VI to get the relavent data).  As such, I would move towards having a cluster as the input and output types.  Using a configuration file is also a good idea, when new elements are discovered, and sometimes later refuted, it would be nice if you did not have to edit your VI.

As a bonus exercise, you should also give the ground state term symbol.  Super bonus points for implementing Hund's rules in a VI as opposed to simply wiring constants.

[bluekid239]

Thank you all for your feedback on my VI, I greatly appreciate it. I have a couple of specific thanks to give here:

tst--The array of clusters of info sounds like a great idea, actually.  I could implement that quickly and easily. Thank you.

smercucio-- Because I am a beginner, I have no idea how to implement that XML idea of yours, but it sounds like a really interesting idea.  I'll look into it and think about implementing it into my program. Thank you.

If anyone else has more feedback, I'm still open to ideas! I appreciate all help offered!

[GregFreeman]

This is a personal, aesthetic preference, but I'd right click your indicators and controlls where appropriate and uncheck view as icon. IMO it makes things much cleaner/easier to condense. It will also allow for all of your indicators to cleanly fit on the right side of your diagram, instead of some above and below with wires "spaghetting" (spaghetting = new VERB)backwards.

Message Edited by for(imstuck) on 12-11-2009 04:10 PM