Serial port remains blocked

[heinasirkka]

Dear NI forum members,

I'm trying to connect a power meter of Siemens (slave) to PC (master), eventually read out power values from LV. I use Modbus RTU for the communication between the master and the slave. The device has RS-485 output, and I use a Siemens-verified RS-485 to RS-232 converter. The problem is that the serial port (COM3, this is a real serial port) remains busy and unreachable after one successful operation at the beginning. When this problem appears once, I can communicate with the device neither via NI-MAX nor a Modbus communicator software (Simply Modbus 8.0.6 and the vendor's own software Siemens Parametrization Software). I cannot find out what is causing this blockage despite all my trials. The different things (or various combinations of them) I did for solving this problem:

- Making sure the connection configurations are correct (baud rate, parity etc..)

- Closing the VISA session with a VI

- Resetting the device and the PC

- Making sure that there is no other program using the serial port (vendor's own software, another open/running VI, firewall). I also checked from the Procexp by searching for "Serial", and nothing appears. 

- Change the setting at: LabView Tools->Options->Environment->Automatically Close VISA sessions to make sure all VISA sessions are closed

- Tried with another serial port (virtual and non virtual)

- Tried with another PC

- Reinstalled all the drivers

- Changed the LabView from 2011 to 2016

- Bought a new PCIe card with two real COM ports (by hoping that they have more buffer and won't get "choked" by data coming from an unidentified mysterious serial source)

- Went from Windows 7 to 10

The problem did not appear only once when I made a completey new system. Afterwards same thing happened. I cannot perform a loopback test via NI-MAX. NI-MAX recognizes the device but cannot communicate (see picture 1). The log of the NI-I/O Trace is at the Picture 2.

I'd be very happy and thankful to hear any of your comments,

Kind regards,

Kaya

[AJost]

Hi Kaya,

You did already quite extensive troubleshooting and I am not sure how much I am able to add here.

As you already know the error means that some device is blocking the access to the COM port as in this knowledge base:

Error -1073807246 Using VISA VIs

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019NeQSAU&l=en-US

1) Can you communicate with the device using the Siemens Software, before the communication is blocked? This would show that there is no actual problem with the power meter. If this is working you can use try using I/O trace to sniff on the communication and understand if there is any difference

2) Did you already check with Siemens if this is a known problem? From what you describe I can see nothing wrong in the way you use the COM ports, this it might be that we are doing something wrong which is specific about the power meter

Best Regards,
Andreas

[heinasirkka]

Dear Andreas,

Sorry for my late answer. Other types of worked showed up in between. 

I don't think there is a problem with the device since I can communicate with it through other Modbus software (vendor's software Siemens P PAR, and another software called Simply Modbus). However it is crucial for me to link the Modbus holding register readings with the LV block diagram of the system I'm trying to control. So when I try to communicate with the device via NI DSC module or another Modbus library (http://www.ni.com/example/29756/en/), the master (PC) cannot communicate with the slave device (power meter) and then the COM port remains blocked. This means that I cannot access it anymore even with the previously working software. I do everything to release the COM port like restarting the PC and the device, however it remains the same. For example, half an hour ago, I was able to read my registers via the Simply Modbus software. Then I wanted to give it another try to work with NI DSC module (because the examples on internet seem to be very simple and straightforward). I used the NI's own examples. It prompted communication error. Now I also cannot use the Simply Modbus anymore. A snapshot of the program and the report of NI I/O Trace is attached. As far as I understand, the warning corresponds to "VI_ERROR_RSRC_BUSY => ("VI_ERROR_RSRC_BUSY", "The resource is valid, but VISA cannot currently access it.". It seems like it cannot access the device, which was working perfectly with other software. As an addition, the try-out with LV blocks the entire COM port, as I said before. I looked up a lot for the ways to release the COM port or identify what is blocking it, but nothing has worked yet. I see similar problems on the NI forums and all of them remain unsolved:

https://forums.ni.com/t5/Industrial-Communications/Communication-with-modbus-devices/td-p/2928696

https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Periodically-losing-serial-communications-La...

I used the converter cable recommended by Siemens and it solved some of the issues. However, the core problem persists and the Siemens people remain clueless about the issue. They also show no interest for issues regarding LV, since the device actually seems to be working with their own software. They can give no comment about the COM port.

Kind regards,

Kaya

[heinasirkka]

I wanted to give an update about releasing the COM port. If I stop the processes at the NI Distritubuted System Manager, I see that the COM port becomes free. I can communicate with the device using Simply Modbus. Apparently the I/O server remains ON and their VISA process needs to be stopped with "Stop Process. It won't stop even when you close the LabView. I hope this will help someone. However the main issue regarding the use of DSC module for Modbus remains a mystery.

Kind regards,

Kaya

[AJost]

Hi Kaya,

Yes the modbus server is pretty much independent of LabVIEW and now you mention it it makes senses that it stays connected after you stop the LabVIEW program.

 The error code from the IO trace is indeed "The resource is valid, but VISA cannot currently access it.", but this we knew already.
My original idea was to compare an IO trace of the working Simply Modbus with an IO trace of the failing LabVIEW Modbus. This should allow us to find the difference between those two programs and eventually fix it.

Andreas