What is replacement for instrfind function?

Hello,

I just saw that "instrfind" function will be removed in the future releases.I am using this function frequently to detect open COM ports and close them before re-running application.

eg.

out = instrfind('Port',['COM',int2str(ComNum)]);
if ~isempty(out)
    fclose(out);
    delete(out)
    clear out
end

What procedure do you recommend to use in order to access already open COM port?

I see this step as extremeny useful, otherwise "serialport" will report an error (Unable to connect to the serialport device at port...)

Best regards,

Ivan Sojic

Answer 1

[Steven Lord]

The Compatibility Considerations section of the instrfind function documentation page gives a list of replacement functions for various uses of instrfind. Quickly skimming through the options suggests the serialport interface family of functions is the correct replacement. See this documentation page for more information.

[dpb]

But there's no reference to a replacement function or syntax to instrfind at any of those links, @Steven Lord. One's left to have to figure out a replacement functionality on one's own, it appears, there's no specific suggestion of what replaces the to-be-removed function itself.

[Ivan Sojic]

Maybe to ask my question differently. If COM port is already open, and I lost a link to my serial object, how I can close or reopen a COM port to run my application again?

[dpb]

I think (as you @Ivan Sojic as well, I think <vbg>) the transition documentation should itemize each and every one of the old serial object related functions in its transition section to at least attempt to provide answers for such questions. When TMW decides to break existing functionality, it is imperative on them to provide ALL the needed information. Automated transitioning toolsets would be better or even better would be to not break syntax but update existing functionality.

Reading the doc, it doesn't appear that TMW has deigned to retain the feature of giving the user access to the global collection of serial port objects going forward. This would appear to in keeping with the recent penchant towards hiding graphics object handles so one can't make user modifications easily.

It looks like the only choice in this case with the new serialport objects would be to compare the list from serialportlist('available') to that of all serial ports. But then, it's not clear how (or if) one could get access to those open if the device handle/object variable has been inadvertently lost.

Would definitely be a potential issue and one to make sure that "don't do that!" -- debugging could get a whole lot tougher, indeed, if a syntax error crashes while context was in a function back to the command line and the local variable now isn't there any longer. Will an internal error cleanup close that port on the crash?

If TMW doesn't answer this Q?, I think it worthy of technical support question after trying a few of the obvious things like the above to see what the new object behavior is.

[dpb]

ADDENDUM

It would seem about the only available workaround/kludge available to the user code would be to create a global array or struct that holds the serialport object handles. While globals tend to be ugly and messy, that would at least reduce the likelihood of many of the ways one might otherwise get orphaned handles.

Of course, ideally, one doesn't ever have that occur, but "stuff" happens...

[dpb]

ADDENDUM SECOND

s=serialport

without any arguments will connect to the last cleared serialport object instance.

This gives one-step recovery, but doesn't let one retrieve status of any port by name as does instrfind

This machine has only one COM port so can't see what happens with more than one -- would a subsequent use of

s(2)=serialport;

reopen the previous second-to-last cleared serialport object instance or ...???