Writing to database

[Charles_CLA]

I can't help you much with the Table name, if LabVIEW says the table doesn't exist then you'll need to check your connection string, table name etc to make sure they do in fact exist and are typed in correctly. You mentioned that you had LabVIEW reading data from the database, does the connection string and table name match what you have in your read code? As far as storing the data with a state machine, if every test is its own state then I would switch back to using a cluster with ten boolean elements. Use a shift register to shift the cluster back around for each test and in each state set the appropriate element in the cluster to the result of the test. In your save to DB step you can then directly wire the cluster to your write to DB function and not have to mess with the array to cluster.

[Damien129]

Yes my connection information input is a udl file. The table name matches the table i want to take the parmeters from. Thanks for the reply i am not sure i follow with the state machine i have attached my vi below. Have a look and see if what you suggest will work in the test step state

Regards

Damien

[Charles_CLA]

After seeing the code I understand your confusion. You have a fairly interesting architecture there. You should probably check out the Queued State Machine and Simple State Machine examples that ship with LabVIEW 2012 and stick with just one of those. The current blend you have is probably going to cause you much pain down the road.

If I understand your code correctly, the Test Step comes from the queue which is populated by the database. Within the "TestStep" state, you could wire the cluster value "TestStep" to a case structure. Create a case for each "TestStep" you have ("TestStep1", "TestStep2", etc...). In these cases you can bundle the appropriate pass fail element. Again, keep the pass fail cluster on a shift register so that you don't loose previous pass fail data. I'd modify your example but I can't as I don't have the SubVIs or IMAQ drivers.

[Damien129]

Hey charles,

Yes the test step receives the 10 test steps from the queue and removes an element after each loop. With the case structures i woud use a case within the test step case block? Is it something along the lines attached?

Damien

[Damien129]

Just tidied it up a little im unsure about how to set the appropriate element in the cluster to the result of the camera inspection state?

Thanks alot for your help charles.

Damien

[Charles_CLA]

Take a look at the attached VI. WARNING! I had to disconnect the controls from the typedefs you created as they weren't included. I think this will get you there.

[Damien129]

Fantastic Charles you have been a great help.

Just to clarify the vi, the case loop "Test1, Test2" will execute until the teststeps in the unbundle by name reaches the last test step? I would put my configure vi for power supply in each test case? What i am looking to do is perform the camera inspection in each case, so the result from my camera inspection is the "Test pass or fail criteria" which i would do inside the Test1, Test2 case? would this be correct. Apologies for all the questions.

Damien

[Charles_CLA]

This code would be blended with your old code that had the queue. The "TestStep" state kept on executing until the queue was empty. After each test was complete you run the boolean into the case structure that I created for you. This simply logs the data into the correct space in the cluster.

[Damien129]

Im probably missing something from what you say for instance with my camera inspection vi which will be contained within the case Test1, Test2 structure i will have an output of pass/fail where does this tie up with the vi you posted? Thanks Charles

[Charles_CLA · Accepted solution]

I've attempted to work the modifications back into your original program.