MSComm: Error 97 : Null Refnum was passed in as input.

[1eyedjack]

I hope someone is familiar with this older way of serial input.

I am having issues bringing a vi onto a new computer. I've seemed to narrow the issue with how the IMSComm property is referenced.

The program has a control written into the reference, but it shows up as "Could not be loaded". When I try to run the program it throws an Error 97: Null Refnum was passed in as input. I found that error in a older post which directs to this Knowledgebase Article [broken link removed].

I'm unclear on what actually should be the control here or what it should point to, or look like. Could anyone point me in the right direction?

I've attached a screenshot and the program here.

[Bob_Schor]

I do hope you didn't write this VI (five years ago).  I also hope you have sufficient experience with LabVIEW that when I suggest "Starting over" and designing a proper LabVIEW Project, you won't faint.

However, before I go too much farther, you did mention a new computer.  What version of LabVIEW was installed on the new machine?  LabVIEW 2013?  What version of LabVIEW was used to write the original code?  LabVIEW 2013?  [I mention this because the VI you thoughfully included, thank you, was written in LabVIEW 2013, and I didn't know if this was "original code" or "migrated code"].  There seems to be device (or at least code) with letters QSB -- what is this, and have you moved these libraries (or whatever) to the new computer?

OK, back to the code.  

• Put it into a LabVIEW Project and manage it from there.
• Make sure that every Block Diagram fits on a single Laptop Screen, as does every Front Panel.
• To accomplish the previous goal, create sub-VIs that "do one thing".  Make sure you make an Icon for each sub-VI (something as simple as a Square holding three or 4 short lines, e.g. "Open Files" or "Init Serial Port").  A 32x32 pixel sub-VI is much more compact than a dozen functions.
• All sub-VIs should use the 4-2-2-4 Connector Pane, with lower left and lower right being Error In and Error Out.  (Almost) no exceptions -- if you need 8 inputs, you're either "doing too much" or not using Clusters appropriately.
• It's not a bad idea to write a one-page Document about what you want the code to do (forget about how to do it, just get down the "what") before you start coding.  Knowing the Big Picture first helps "put off dealing with the details".
• Do not use Local Variables.  Learn about Wires on Shift Registers, Simple State Machine (there's a Template that generates an SSM for you to study, at least in newer versions of LabVIEW -- try Create Project, Template, Simple State Machine).
• I've done several "start-overs" of Bloated Monsters.  It took a little time, but until I realized something "radical" was needed, I probably frittered away more time than it took to "do it right".  I ended up with code that was smaller, faster, more intuitive, modifiable, and worked. 

Bob Schor

[RavensFan]

Do you really want to us MSComm?  Is that the old ActiveX control that Microsoft created for using serial ports within applications like Excel?

If so, I would stay far away from it.

National Instruments and LabVIEW already have a means of communicating with serial devices (and other things as well) called NI-VISA.  Look in LabVIEW for serial port examples to get started.  I would lean towards the Advanced Serial example more than the basic example.  The basic example highlights using Bytes at Port to determine how many bytes to read, and that is the wrong thing to use about 95% of the time.

[1eyedjack]

Hi Bob,

Thank you for the input. Programs that I write I do try to follow the state machine architecture with shift registers instead of local variables. I didn't write this program and I do realize it violates many of your suggestions.

I don't know what version this was originally written in, but it was working previously in LabVIEW 2013 on the old computer harddrive. I thought of re-writing it, but thought it a big undertaking for just my lack of understanding of MSComm and what it needs as a reference to work, since it was working fine before.

QSB is a linear-encoder which is also usb connected. I've enclosed a zip file with the project and all the dependencies here.

[1eyedjack]

Thanks for the input. Yes, I believe it is.

Now that you are putting it clearly, perhaps the issue is in the updated version of excel on the computer too, haha.

I realize its not ideal. I just feel like there is a slight gap in my understanding of MSComm that is the issue in fixing the reference.

Best,

Arthur J.

[RavensFan]

It's not just that it is not ideal, it is just a bad idea.  Even in 2013, it was a bad idea to use MSComm activeX.

You'll be much better off rewriting this using VISA.  You'll be able to get it working faster than you can trying to figure out what broke behind the scenes with that ActiveX control.