Ddp Questions

[SteveMyres]

I don't see anything about custom protocols on the forum, so I thought it might be helpful to have a thread (and perhaps even a subsection under the comm section) to collect questions and answers about implementing them.

 

So the standard protocol UI doesn't seem to allow for deleting or renaming functions or I/O types.  Is there a way I'm missing?  If not, it is safe to edit the DDP file offline in a text editor, to delete and or rename elements, and or the internal driver name, etc?  Or must we create a new DDP from scratch, copy the stuff we want to keep, delete the original and rename the new one?

 

Also, what's a quick summary of the difference between a custom device and a custom protocol?

[AzeoTech]

To rename or delete, just edit the ddp file.  Its safe to edit as long as you don't mess up the formatting, which is pretty apparent.  Also, the file is loaded on startup, so you'll have to restart to update with any changes.

 

The only difference between a custom protocol and device is the scope they run in.  Devices run in global scope, while custom protocols run in the scope of the port they are attached with to create a comm device.  So, with a custom protocol you have access to write(), read(), etc, functions of the port, and DAQFactory automatically uses the port that the protocol is assigned to.  These functions aren't accessible in a custom device because there is no port.

[SteveMyres]

Thank you! Is there a way to know how many chars are in the port receive buffer?

[AzeoTech]

No, but you can do:

 

read(0)

 

and it will return whatever is in the buffer without blocking (which may be an empty string).  Those characters are removed from the buffer.

[SteveMyres]

True, and that's what I'm doing now, but then I have to either do it repeatedly, or wait long enough before so to ensure the response has probably been received. You'd get more transactions per second out of the driver if you can grab the response as soon as the proper number of characters are in.

Still if you had to recursively call read(0) till it dried up that wouldn't be terrible.

[AzeoTech]

If there was a function to get the number of characters you'd still have the same problem of having to call the function repetitively (not recursively, that's something else).

 

That all said, you could always use the OnReceive callback.  That gets called as soon as a character comes in.  That's the event driven function you want to get the best performance.  The tricky part is synchronizing it, since it gets called in its own thread, separate from the one the channel query uses.  I'd probably set it up so the channel query sets some local variable with the information about the query, then OnReceive uses that once it receives all the data to put the result into the right place.  If you use LockPort() correctly, you can at least ensure that your local variable isn't going to get changed out from under you.  You will, however, need to implement your own timeout as well.

[SteveMyres]

Right, sorry, shouldn't have said recursively.   Repeatedly.

 

Good ideas, thanks!

[SteveMyres]

Must the OnLoad() function complete and exit before the channel table sends requests?  I have a working protocol, and I wanted to add some code at the end of OnLoad() to watch for changes in the channel table (at least changes in number of channels).  Translating the controller addresses into bytes on the wire is time-consuming, so I'm precalculating most of the query string and storing it in the MyChannel.strNotes field.  If the channel table changes significantly, I need to redo the channel grouping for bulk reads and the query precalculation, so I put a while(1) loop at the end of OnLoad() to look for changes, but then it seems like the protocol I/O types don't receive any requests from the channel table.  I commented out that loop and everything works again.

 

I was originally thinking it would be cool if we could have access to the event when we push the "Apply" button on the channel table; then I'd just trigger this stuff off that.  Maybe a built-in OnApply() function in the protocol or something like that.