DQMH Consortium Toolkits Discussions
Struggling with adapting DQMH to be a driver for this particularly hardware scenario.
I am writing a driver for a newly acquired instrument to interface with an already established "master" controller that coordinates a bunch of instruments in a robotic work cell.
DQMH has brought out the best in my abilities so naturally that's the framework that is my goto.
The thing is, the way the API interface for the instrument is setup, I'm struggling to figure out how to do this in the best way.
Essentially, communication is through a DLL that abstracts a few low level things away (like the physical interface, LAN, USB, serial, etc...). Just to be clear, this DLL is provided by the manufacturer. There are basic commands to distinct functions, things like open/close interface, connect/disconnect, attach event callbacks, etc... Beyond those, the real "useful" functions of the instrument are dealt with via a Send function of the DLL, where you send XML-like commands through it. Responses to these commands ((and spontaneous events) are received by calling a ReadResponse, ReadEvent, and ReadError DLL function, the actual responses are also XML-like. You know to call these Read functions by being notified via the event/callback that you associate/attach to that particular event pipe (the different pipes are Response, Event, Error, etc). For each call to a DLL function, an error status is returned (0-successful, 1-no data, 2-error blah blah, 3-error meh meh, etc..) The DLL calls return nearly instantaneously. Most of them actually mean the call/result was successful/not. However, there are some, like uploading a certain "run files" to the instrument, where the return is simply the status of whether that command was received, and a later event is sent when the actual upload/download operation is completed successfully/not.
So here's the thing. I want a DQMH module to be the driver, other labview developers will interface with my module and not the manufacturer api directly. So lets say they want to connect to the instrument. I would make a Request & Wait for Reply event for both the OpenSession and Connect DLL functions. Those request vis will return the error/status that the dll gives my module to whoever is using those vis. OK so far. But now we get to the actual using of the instrument. Let's say someone wants to upload a run file, request that the instrument list all the run files in its memory, and then run one of those files. Upload is a dll function. It will return immediately with the status of whether the upload was started successfully. And then later on, asynchronously, an event will be received that actually says if the upload completed successfully. A DQMH Request & Wait for Reply has some potential problems. Most of these transfers take about 3-6 seconds, so right there it's hit or miss whether it will timeout on the default DQMH 5sec timer. Secondly, I don't really want a call like that to block for such a significant amount of time (to me, anything noticeable to a user interacting with a UI is "significant" and undesirable - so like 200-300ms is about the limit before I explore implementation alternatives that don't block interaction). I can see where a Request & Wait for Reply and broadcast might be a solution to this but that also certainly forces some constraints on how my driver is implemented (needs an event structure).
But lets move on to the next command. Someone wants a list of the run files that are on the instrument. This is one of those XML commands sent via the Send dll function. The Send function will return with whether the send was successful/not pretty much instantaneously... But that's not the whole story. A "Response" event notification will be received when the list has been sent back from the instrument, then the ReadResponse function needs to be called (yet another instance where a status return is received, must know if the ReadResponse was successful) and the list is received along with status/error regarding the XML command sent ("ListRunFiles" ok=true/false). It is almost certain that anyone using my driver will want the list synchronously (eg, as an output from a "List Run Files.vi" request). The actual operation is fast enough to where I'm not worried about blocking with a Request & Wait for Reply event but the underlying structure is not at all easy to map to a Request and Wait for Reply, especially considering there are really a number external calls and their associated returns underneath it all. To top it all off, any Response received is not at all guaranteed to be related to the most recently sent (or least recently sent) command. If I send a few commands quickly, depending on what they are, the order of the responses I get back is not at all guaranteed to be in the same order as the commands.
I can see how to attempt to abstract all this away and basically make it behave like a purely synchronous communication scenario to a person utilizing my api. Although I feel this will be the way almost everyone will want it, I can envision scenarios where it would be actually undesirable. I suppose you could say I'm struggling with how to have it both dummed down (synchronous), hiding a bunch of things that are going on to make what seems like a singular command (eg. ListRunFiles) work, but also having it where everything is optionally exposed (like the status/error returns of the Send and ReadResponse functions, in addition to the return of the XML commands like "ListRunFiles").
Huge thanks to anyone who has followed along this far. I feel like I may have done a terrible job describing what is crystal clear in my own head after spending significant time considering how to tackle this situation. Hopefully it's not as terrible as I'm imagining it.
Hi Doctor,
This is how I would start. It assumes the DLL calls do not lock up your DQMH module.
I would create two DQMH events:
"Start Upload" is a request event that starts the run file upload, it also sets a boolean flag for whether or not the update is complete to false. When the DLL comes back and says it is finished, set this to true inside the module.
"Check Upload Status" is a request and wait for reply event that just asks the DQMH module for the status.
Then I would combine these into a simple VI that starts the upload, and waits for the upload status to be true, or a timeout condition to occur. This is the VI that most users will use. You can hide the other two VIs in an "advanced" subfolder, in case some users want more flexibility.
