Asynchronous Custom Device "Go" Channel

[Pie566942.0]

Hi All,

I'm building an asynchronous custom device for VeriStand 2013.  I'd like to make a "Go" channel.  The behavior of the "Go" channel is when it's set to not-zero, the custom device starts a task.  When the custom device is done with the task, it sets the "Go" channel back to zero.  In my mind, this is like the latching behavior of LabVIEW Boolean controls.

Ideally, I could write the value of an input channel from the RT driver itself.  I don't think I can use channel data references in an asynchronous custom device, right?

I don't want to implement anything that requires manual configuration in the system definition outside of the custom device area, e.g. calculated channel or alarm/procedure.  These techniques would limit the reuse potential for the custom device.  We don't use the Workspace, so I can't implement this in a custom workspace object.  A custom device message is pretty close to what I need, but a "Go" message doesn't pass my sniff test; it feels like overkill. 

Given I have workarounds, is there a native way to set an asynchronous device input channel value from the driver, or another way to get a "Go" channel?

Thank you,

Steve K

[Jarrod_S.]

Probably the most straightforward way to do this is to write an inline custom device that spawns a background VI in the Start case and sends it data manually using FIFOs. Then in the inline portion you can easily do the latching commands like you mentioned. The Embedded Data Logger does exactly that. You can find an old version of it online for reference.

Alternatively, if you really want to stick with an async device, I could envision doing this with a mix of separate command and status channels. You might have an input channel to represent Go. You signal this by incrementing the value. Then you have a separate status channel called Last Command that you set to the value passed to Go once the command has been processed. That allows the client to send new commands and tell when they're complete. A little quirky, but something like this might do the trick.

[thumble]

Hello,

I agree with Jarrod's second proposition, as I think it's safer to have a status separated from command to avoid strange side effects depending on the way the command is controlled. It also allows you using the simplest code template.

[Pie566942.0]

Thanks for taking a look and for your reply.  I'd prefer not to make my users keep track of a command counter, so maybe the inline device is the cleanest interface.  

Best,

Steve L