Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: CML/Driver - Async Macros
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Let's say I'm in a poll event* ... I'd like to fire off a macro (or other hunk of CML code) that may take some time or require waiting for a device. I don't want to block my thread/driver. I don't even particularly care for a call back. I'll either assume it worked or check it later.

Can I do this? if so, is there an example out there or a document?










*Outside of a dog, a poll event is man's best friend. Inside of a dog, it's too dark to poll.
CML is strictly single threaded. So you just have to use state machine like flags to track your state and start the operation, then return and later check for the completion and in the meantime keep up with the fact that the device is incommunicado until it's responded.
Dean Roddey Wrote:CML is strictly single threaded. So you just have to use state machine like flags to track your state and start the operation, then return and later check for the completion and in the meantime keep up with the fact that the device is incommunicado until it's responded.

So, I could do this:

Driver A - exposes fields (for the user) and talks to the device.
Driver B - Does stuff via backdoor or "command fields"

Driver A in it's poll sets a field in driver B that causes Driver B to execute a (for argument) 30 sec process. Driver B blocks for 30 seconds, but Driver A should return immediately. Thus being responsive.

Of course, if you try to talk to Driver B again, immediately, you'll have trouble, but this would keep the fields in Driver A updating and responsive.

Right?
In theory you could do that. I'm not sure I would though. I don't think it gains you much relative to just starting it in the first driver and remembering it's started and acting accordingly. It's more complexity to get to the same place.
Dean Roddey Wrote:In theory you could do that. I'm not sure I would though. I don't think it gains you much relative to just starting it in the first driver and remembering it's started and acting accordingly. It's more complexity to get to the same place.

I guess it would depend on if it's something that I need to wait for a response. If I have to wait I don't want to block the driver. I don't even remember what the application I was thinking of was Smile...
You don't have to block in order to wait. You jsut remember you are waiting for a response and keep checking for it to arrive until you get it or give up. But, either way, you've effectively blocked the driver in most cases sine you generally cannot then send any outgoing messages to the device until it's responded, so you'd have to reject writes. That's better the just blocking definitely.