When is ActionVIOnDownload executed

[beavercreek]

Hello all,

I have a VI that I've been using as a custom tool from the workspace.  Essentially it calibrates some offsets.  The offsets that get zero'd are output from a custom device.  There is a desire to have this zeroing happen automatically at every SDF deploy.  So at first I was thinking the ActionVIOnDownload is perfect for this, but now I'm having second thoughts.

Since the zeroing VI's cannot run until the custom device is already functioning (for at least ~300ms), I don't believe the OnDownload action vi will work, because I believe it executes before any custom devices would be operating?

If I'm correct about this, what are my choices?   The VI's I have written execute on the host PC, could I trigger something to run on the host PC at loop 100 of a custom device engine?

Target is Pharlap

Win 7 Enterprise

LabVIEW & Veristand 2015

[PedroMunoz]

Hi,

Instead of the ActionVIOnDownload you can also consider the ActionVIOnLoad, which is basically going to execute when VeriStand loads the custom device into memory:

http://zone.ni.com/reference/en-XX/help/372846H-01/veristandmerge/cd_actionvi_templates/#onload

Pedro M.

[beavercreek]

>Since the zeroing VI's cannot run until the custom device is already functioning (for at least ~300ms), I don't believe the OnDownload action vi will work, because I believe it executes before any custom devices would be operating?

Yes, my guess was correct, you can see from the deploy log "Processing Action on Deploy VI's..." occurs well before the "Current Sampling Engine Waveform.llb" is even downloaded, let alone running.  I don't really know what I did wrong the first time I tried to use an OnDownload action vi with a 30 second pause in it.  I suspect the problem was where I positioned it in the custom device .XML file.  The first time I put it after <Item2Launch>...</Item2Launch>  but i put it in a sub page instead of after the main page <Item2Launch>

>If I'm correct about this, what are my choices?   The VI's I have written execute on the host PC, could I trigger something to run on the host PC at loop 100 of a custom device engine?

This is essentially what I have done (see attached pdf)  The OnDownload Action VI has only one function "start asynchronous call" that runs a SubVI.  SubVI starts trying to talk to the custom device, when it gets the right answer, it launches the calibration process.  Which brings me to the latest battle.

The calibration process takes ~13 seconds after it is initiated  (its not the analog signal gathering that is lengthy, but rather the ~48 calls to "NI VeriStand - Set Calibration.vi" that consume the majority of the time).  The problem is how do I make sure that no sequence/stimulus profile is executed before the zeroing is done?  With the amount of automation in the test system, it is likely we could attempt/start a sequence in that amount of time?  Any Ideas?

[joshe]

Hi Beavercreek,

Why don't you just have a user channel get set when your calibration is done.  Then in your Stimulus Profile you can check the User Channel value before the main sequence is allowed to run. I might not fully understand your process but this would be a simple solution.

[beavercreek]

Hmm, that probably would work well.  We'd have to go back and modify many sequences, but it is of course do-able.

I did find this deprecated function today:

http://zone.ni.com/reference/en-XX/help/372846H-01/veristandmerge/vs_reserve_stimulus_profile_manage...

alas, it is deprecated and does not seem to have current equivalent.  Perhaps I'll just hold my nose and use it.  😛

[StephenB · Accepted solution]

Can you add your workspace tool to the project as a service? Then it runs on every deployment. You can also set that it must finish

[beavercreek]

Ha! after fighting with my source distribution for a while, indeed you can do this as a service!  I did not know you could require a service to complete.   Thanks for that!   I'll probably put more thoughts together later on the differences between doing prep work as an OnDownload Action VI versus a terminal (short lived) Service.

This brings me to my next question about Services.  The help seems to indicate that both "Wait For This Item To Complete" & "Wait For This Item to Synchronize" delay the launching of the workspace.  But I actually hope the documentation is a bit off, I hope "Wait For This Item to Synchronize" does more what i need (ie prevent any sequence from executing until the service is complete).  Since we are mostly using the system as a "headless" test executor, the appearance/launch of the workspace is really inconsequential.

Does the "Engine Sync" Boolean notifier actually do something different?  I think it must, why else have two methods of delaying the workspace visibility?  I fear the "Engine Sync" will prevent the engine from running until the Service is complete, but I need the engine running to read/write the RT FIFO's so that the asynchronous custom device can get a good zero.  I think I  need an Execution Mode like "Wait for This Item to Complete & Delay Sequences"

• Execution Mode—[Service Component: Custom VI] Specifies whether and how to synchronize the service with the Workspace. If you do not select an Execution Mode, the Workspace does not wait on the service to do anything.
  • Wait For This Item To Complete—The Workspace does not launch until the service finishes executing.
  • Wait For This Item to Synchronize—The Workspace does not launch until the service returns a Boolean notifier. To use this option, the service must include a front panel indicator labeled Engine Sync.
  • Timeout (ms)—[Execution Mode: Wait For This Item To Synchronize] Specifies the time in milliseconds to wait for the Boolean notifier before timing out the service and allowing the Workspace window to launch.

[beavercreek]

In case anybody is interested in the final solution..

In the end I chose not to use the ActionVIOnDownload.  I followed the suggestion to have a service launched with the system deployment.  Mainly I liked the service approach better because that let me update the custom device independently of updating projects.  Had I used the ActionVIOnDownload the action vi itself would have to be working perfectly when the updated custom device was launched.  The service can be easily added to any particular projects that wish to use it.  The only changes made to the custom device are for it to listen and respond to a few messages from the host PC.

The service:

1. Sends messages to a custom device repeatedly, at first clearing the errors (when the custom device is not yet running/ready to respond).

The  custom device responds to the queries with two different messages, if it has been running long enough to fill its internal buffers and generate a good zero, the service moves on to the next step.

2. Calls the calibration custom tool asynchronously, waiting for completion.

This same custom tool is available in the workspace, so I had to add/set a Boolean control to let it know not to display any vi front panels or dialogs, just do its job and quit.

3. Tell the custom device the zeroing is complete.

Why would the custom device care?  it really doesn't BUT, our test automation needed a way to know if the zeroing was complete so it could either wait longer or start running sequences on the system.  The test automation was updated to send/receive messages from the custom device.

I hope this fully explains what we've done.