LabVIEW
system config help
Hi,
I am stuck on this problem,
I was wondering if someone can give me some ideas on approaching this problem.
as of right now, I have 5 test systems that are very similar.
all of this 5 system uses 1 software that handles all 5 systems.
to determine what configuration to setup the system, i call for an external file and gets its input to config the serial port, etc.
This version that i have is configured for 5 systems, but not for additonal system without modifying the software.
in order for me to add new system, i would have to edit the ring properties and that changes the software, and that needs more validation that i dont want to deal with.
can someone guide me into figuring out how to include more systems with the current setup that i have without having to modify my code in the future.
here is my diagram.
i get a file from a folder with the test station id. match the filename with colum 0 of the setup file. and if it matches, then give test system number from 0-4 for system 1,2,3,4,5.
ex.
system 1 = 12345-001
system 2 = 12345-002
system 3 = 54321-001
system 4 = 54321-002
system 5 = 54321-003
how would i created system 6 of 12345-003,
or system 7 of 54321-004
without having to edit the ring properties?
Find_CPU_NAME.vi
Main Vi
Test Sequence gives value of 0-4 and that determines how to configure the system.
I guess my question is ..
can I change my ring properties dynamically.
how do i programmically add to a ring property.
without having to "edit items"
krispiekream wrote:[...]
I guess my question is ..can I change my ring properties dynamically.
how do i programmically add to a ring property.
without having to "edit items"
Like this:
This may sound like a stupid question, but what is wrong with (a *.ini file - read key value,) :
1) convert decimal value into a type def enum
2) Enum goes into case structure,
3) Each case of the case structure (self documenting code) outputs the test system required.
(Enum could even be test system required)
Which ever way you do it, you have to recompile every time you add a machine or change the function of the machine.
Storing the Test System type directly on the machine is much easier to update than in the code as if a machine changes it's function, or a new machine is added to the system.
Do you have a very good reason for this implementation Krispy?
This is looking suspiciously like Rube Goldberg to me. 
James
A word of caution:
there is one "minor" differance between enums and ring controls. You CAN change the strings[] in rings while running. You cannot change the strings[] in enums while running.
So- if you use an enum to hold your "list of active stations" you need to recompile for each added station. if you chose to use a ring you can populate "list of active stations".strings[] from your configuration file.
As an aside- A configuration file could be in almost any format (See This thread for a brief discourse on preferances and a good nuggetette from DFGray)
Selecting the best (for you) format is going to be worth the development investment. you may want to reevaluate the limits imposed by the existing model and bump up changing the file structure from "maybe someday" to "potential for immediate development"
can you show me in a diagram of what you mean?
how would i make a list on the ring from the file name.
i apparently went another route and not use enum or ring.
it works for me.
In this thread I and the OP developed a "released test launchpad". It used a config file to hold a list of "test" names and vi's that performed the test. the ini file was used to populate a ring control that allowed the user to select the "test" to launch.
In fact that little vi grew into a "feature" that I use to extend capabilities of test apps that I ship. Customers allways seem to want something on top of the test like "It would be nice if I could programmatically see the variation of param x in my data without maniplulating the data file in excel" <Poof> Graph parameter x.vi shows up as an option without recompiling the test application. Kinda neat really
