LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW steals communication with external software

Solved!
Go to solution

Good morning,

 

I am curently developing a software in LabVIEW and it already operates perfectly as I want.

The whole setup is made up of 4 instruments communicated via USB (VISA).

 

The problem occurs when I try to run an external osciloscope software (not NI domain) while running the LabVIEW one. After about 1min, the external software loses communication with the osciloscope and says that another program is using the device. Then I need to restart LabVIEW so the osciloscope can communicate again.

 

No, the osciloscope is not being used by LabVIEW in any way.

 

And the communication with the osciloscope is being made by USB too.

 

Anyone knows how to "block" the communication of this COM port to LabVIEW or other solution to this?

 

Thanks!

0 Kudos
Message 1 of 8
(1,091 Views)

@GabrielTo wrote:

Good morning,

 

I am curently developing a software in LabVIEW and it already operates perfectly as I want.

The whole setup is made up of 4 instruments communicated via USB (VISA).

 

The problem occurs when I try to run an external osciloscope software (not NI domain) while running the LabVIEW one. After about 1min, the external software loses communication with the osciloscope and says that another program is using the device. Then I need to restart LabVIEW so the osciloscope can communicate again.

 

No, the osciloscope is not being used by LabVIEW in any way.

 

And the communication with the osciloscope is being made by USB too.

 

Anyone knows how to "block" the communication of this COM port to LabVIEW or other solution to this?

 

Thanks!


Two applications cannot access the same COM port at the same time.  Period.  This isn't really a LabVIEW issue, as much as an OS one.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 8
(1,043 Views)

In one sentence you say you are running both the LabVIEW and the non-LabVIEW oscope software at the same, time, then the next sentence you appear to say this is not the case.  Did I misunderstand something?

 

Thanks.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 8
(1,036 Views)

Thanks for your reply.

 

I am running both softwares at the same time, but they are not acessing the same COM port.

 

LabVIEW deals with the other 4 instruments while the osciloscope software deals only with the osciloscope.

0 Kudos
Message 4 of 8
(1,032 Views)

For the instruments it does use, did you write all of the communication code yourself?  Or are you using some drivers from the manufacturer in LabVIEW, or possibly some DLL or ActiveX?

 

I ask because some hardware I have seen has manufacturer's drivers that, in an effort to be "easy to use", have some sort of "scan" function that will attempt to send an ID request on all COM ports that exist on the PC and then report back which ones have identified themselves properly.  If any of the 4 instruments you are using have some sort of autodetect code running, that could do it.

Message 5 of 8
(1,018 Views)
Solution
Accepted by topic author GabrielTo

After a few tests, i found out that LabVIEW was not the problem.

 

The problem was with my PC USB hub that when I communicate with the other device connected to it the osciloscope just shut down.

 

Thanks everyone that tried to help me! 

Message 6 of 8
(962 Views)

@GabrielTo wrote:

The problem was with my PC USB hub that when I communicate with the other device connected to it the osciloscope just shut down.


Yet another reason I hate using USB.  If possible, switch to using Ethernet for communicating with external instruments, preferably on a private network.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 8
(955 Views)

USB hubs has caused many problems over the years. It seems to be a little better if they're powered ...

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 8
(937 Views)