Running sequence unmanned

[1984]

Hello community,

I have a sequence file testing our product and now the new requirement to test the product in a temperature chamber at different temps over the weekend (abandoned). 

Controlling the temperature of the chamber can be done from a VI, but how should I launch my sequence based on the state of this chamber control VI? What would be the right approach. I have found THIS topic and the VI in it may solve my immediate problem, but I certainly looking for the right solution.

Log files need to be created for each run and my seq file uses the ModifyReportHeader callback (not sure if that matters).

I was thinking about putting my MainSequence to a subsequence and put the chamber control VI into the MainSequence calling this new subseq. This is not a good solution though because I wont get logfiles separately, plus if something goes wrong then all data will be lost.

Please advise!

Thanks.

[SercoSteveB]

Hi 1984, do you need to control the chamber all the time (does your control VI need to be running and sending commands to the chamber all the time), or do you only need to send occasional commands to set it to a particular state?

In terms of not loosing results, check out On-the-Fly Report Generation within TestStand.

Steve

[1984]

Hi Steve,

I need to monitor the chamber in every couple seconds to see if certain conditions were met. Eg: cool down the chamber to -40C then wait for 30 minutes, then execute sequence, then heat up etc, so I guess I need control over the chamber all the time.

It seems the VI I have linked will do the quick and dirty solution for now, but I am wondering how should it be done in a good way. I know that the chamber wont be controlled during the sequence, so its OK to assume that it keep the temp during the test execution.

thx

1984

[SercoSteveB]

When I said control the chamber all the time I was wondering if you needed to check and tweak the temperature of the chamber whilst the test is running (things like that), but it sounds like you are happy to set then wait for temperature to be reached and then do the tests. 

In that case I would advocate inserting calls to control the chamber into your test sequence (rather than having your chamber control VI call the test sequence).  I am not suggesting calling your existing chamber control VI, but creating individual chamber control and monitoring VIs (Set Chamber Temp VI and Read Chamber Temp VI are obvious examples) and calling them in the test sequence when required. 

Once you have your chamber control and monitoring VIs you can structure your sequence as you like, but as an example you could create a subsequence that takes in a desired chamber temp, commands the chamber to move to that that temp and then waits for that temp to be reached.

Once you have that, leaving your Tests as they are now; either loop around them setting the new temp at the top for every change in temperature you have or have a sequence of calls that set the temperature required followed by a call to your Tests.

You will need to put some work into what happens if your chamber never gets to the desired temperature and other things like that but that should be a start.

Steve

[WireWeaver]

---

@1984 wrote:

I was thinking about putting my MainSequence to a subsequence and put the chamber control VI into the MainSequence calling this new subseq. This is not a good solution though because I wont get logfiles separately, plus if something goes wrong then all data will be lost.

---

This isn't necessarily true - You can configure Sequence Call steps to run in a new execution, then they can be configured to get their own report.

As for the overall discussion, it seems like there are two main options:

1. Let a LabVIEW VI be the master/controller - like having a custom operator interface that monitors for temperatures and then spawns off executions appropriately.
2. Let a TestStand Sequence be the master/controller - similar to what Steve has suggested. One addendum to this is that instead of polling for the temperature constantly in a loop from TestStand, you could do that in a code module that blocks until a certain temperature is reached (e.g. Wait Chamber Temp VI). Be sure to use Termination Monitor if you do this.

There's also a third option that would be a combination of the above two: Read & control the temperature solely from your OI, send UI messages from the Sequence to the OI to trigger a setpoint temperature, and then wait on a notification from the OI that the setpoint has been hit before continuing the sequence. This would add extra complexity, but also add some potentially useful flexibility - like being able to override temp settings manually from the OI without having to kill your execution.

Hope this helps!

Trent

[1984]

Alright... first off, thanks to both of you for the useful suggestions.

I'd like teststand to be the master controller of everything and to call my current MainSequence as subsequence. This would make my life a LOT easier. 

I just need to figure out how to create a separate logs for my current MainSequence which will become a subsequence. Is there like a quick way to do it?

[SercoSteveB]

Do you want an individual results file each time your Tests are run?  So for the example I gave above with 3 changes of temperature and 3 lots of tests you would like 3 separate results files?

[1984]

Yes, getting 3 separate logfiles would be the ideal for me. Is it possible?

[1984]

I have just found THIS page which seems to be the solution to my problem. We'll see.

[SercoSteveB]

I have not done that before so I am not sure if there is an easy way to do it or if things will need to get a little bit more complicated.   I am sure someone will jump in if there is an easier way (than below)

One possibility comes to mind, but is getting into more advanced TestStand territory. 

Instead of having your testing in a SubSequence of your control sequence and calling that (as a subsequence) from your control sequence when required.  Have you tests in a separate sequence file and call that sequence file from your control sequence using the TestStand API Engine.NewExecution when required. NewExecution, as its names suggests, will give you a new execution each time, allow you to define which Execution Entry Point of your ProcessModel (the bit that controls results processing) to use and to make your call synchronous (so that your sequence will wait until the new execution is finished before continuing on).   I think doing it this way will give you a new results file for each NewExecution (but I am not sure as I have never done it).

NOTE:  You will need to modify the Process Model's Execution Entry Point to remove any operator interaction that will pause execution and to define your result file names.

Additional:  Saw your new link, that looks like the way to go.