LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Telnet crashing other LabView apps?

I used LabView to make a VI for an instrument connected by serial port.  That worked great.  I subsequently replaced the serial cable with a modem and made a new altered VI using telnet.  That worked great.  Now, however, I cannot use the previous serial VI (VI freezes) and everytime I open LabView, the program freezes EXCEPT when I run the telnet VI, which still works great.  I am puzzled.  Please, are there any sugggestions?

 

Thanks!

0 Kudos
Message 1 of 5
(1,512 Views)
Doesn't make much sense to me. Are you using VISA for the serial port code? What are you using for the telnet VI? Can you show us your code? I'm also unsure why you have to use telnet just because you put a modem in there.
0 Kudos
Message 2 of 5
(1,504 Views)

Agreed, it doesn't make sense to me either.  But now I cannot duplicate the problem with the serial port, and yes I was using VISA.  Everything works fine now.  Perhaps a local computer problem - let's move on.  Here is a synopsis of the Telnet code I am using.  I use Telnet because that was the only function I found to communicate with an IP address at the time of coding.  Yesterday I noticed a thread regarding SSH - perhaps a better option? 

 

I am having difficulties with the modem/VI/instrument telemetry combination.  If I open all three in a certain order - (1) modem connected to IP address, (2) VI connected to IP address, (3) instrument turned on - everything works fine until it times out.  If I do it in any other order, I cannot get a connection.  I think I have isolated the problem to the DTR serial pin, but I cannot figure out what the issue is.  When it works properly (and a serial cable mini-tester with indicator lights is in the circuit) the DTR alternates flashing red and green once per second, which is the rate my instrument delivers data.  When it is not working properly, the DTR maintains a constant green light.  The modem's DTR is disabled (enabling it seems to kill all chances of connection), and I have tried disconnecting the instrument RTS pin and also hotwiring the DTR and RTS pins together, neither of which has resulted in any different behavior.  Does anyone think there is something I can do in LabView to alleviate this problem?  Can anyone shed some light on the serial pin dilemma?  I'll go check the previous forums for something related. 

 

Thanks for your ideas!

 

 

0 Kudos
Message 3 of 5
(1,484 Views)

The standars TCP/IP functions can also be used for TCP/IP communication.

 

What is the modem/instrument that you are trying to control/communicate with?

0 Kudos
Message 4 of 5
(1,470 Views)

Apologies for not responding earlier, I must have missed this posting.  I am using a Raven CDMA C3210 modem with Verizon as a carrier.  I am able to run everything perfectly now IF I disable the Transmit Data serial pin (modem to instrument) - I posted this current dilemma yesterday but that's the jist.  If Transmit Data serial pin is connected, then a drop in connection (modem power failure, carrier drop) sends something to my instrument that it doesn't like, a relay trips - as if there were a power surge, and it freezes until the instrument's power is cycled.  This will not work for a remotely deployed instrument in the field.  So disconnecting the Transmit Data pin allows me to listen to the instrument indefinitely (even after simulated power failures and carrier signal drops) so I believe I have isolated the issue but I don't understand what it could be.  The modem providers tell me that the modem is essentially a dummy and will send no signals to my instrument, so I'm curious to know if anyone has seen or heard of something similar to this.  Anything would help, I am essentially stumbling around in the dark and it would be very useful to speak to my instrument remotely.

 

Thanks.

0 Kudos
Message 5 of 5
(1,431 Views)