How can i use the TCP/IP to control the instrument via VISA resource?

[billko]

---

@WIILE wrote:

The architecture of Ethernet connect as below:

Control PC <=====> Anrutsu MT8870A(instrument)

The control PC is direct connect to the instrument via ethernet cable.
There is not use the Router or Hub.
The IP Setting of control PC and the instrument is set the fixed IP.

The Control PC IP Address is: 192.168.1.100
The Instrument IP Address is: 192.168.1.1

Open the Windows command prompt an type "ping 192.168.1.1",
Can got the response from the instrument.

---

@billko  已寫：

If you are using IP addresses in the 192.168.x.x range, I suppose you are using some kind of router.  Are you sure the router isn't sitting at 192.168.1.1???

---

---

What I was getting at is it seems you are probably using a router.  Many routers have their IP addresses set to 192.168.1.1 by default.  If your device is set to the same IP address, you will have issues.  Also, if you have static IP addresses in a DHCP environment, you will have to reserve those addresses so the router doesn't place them in the address pool.

[WIILE]

The control PC is direct connect to the instrument via ethernet cable.
The connect environment is not use any Hub or Router.
Maybe you don't believe it, But it it can work properly!

There are most ethernet port in PC is supported crossover, so it can connect direct both.

The Control PC IP Address is: 192.168.1.100 (DHCP disable, Static IP address)
The Instrument IP Address is: 192.168.1.1 (DHCP disable, Static IP address)

---

@billko

---

What I was getting at is it seems you are probably using a router.  Many routers have their IP addresses set to 192.168.1.1 by default.  If your device is set to the same IP address, you will have issues.  Also, if you have static IP addresses in a DHCP environment, you will have to reserve those addresses so the router doesn't place them in the address pool.

---

[billko]

---

@WIILE wrote:

The control PC is direct connect to the instrument via ethernet cable.
The connect environment is not use any Hub or Router.
Maybe you don't believe it, But it it can work properly!

There are most ethernet port in PC is supported crossover, so it can connect direct both.

The Control PC IP Address is: 192.168.1.100 (DHCP disable, Static IP address)
The Instrument IP Address is: 192.168.1.1 (DHCP disable, Static IP address)

---

@billko

---

What I was getting at is it seems you are probably using a router.  Many routers have their IP addresses set to 192.168.1.1 by default.  If your device is set to the same IP address, you will have issues.  Also, if you have static IP addresses in a DHCP environment, you will have to reserve those addresses so the router doesn't place them in the address pool.

---

---

LOL - does it help if I say I believe you now?

[WIILE]

No...I just want tell you, My environment is not use any Hub or Router.

The control PC is direct connect to the instrument via ethernet cable. (crossover)

Thanks for your help!

---

@billko  已寫：

---

@WIILE wrote:

The control PC is direct connect to the instrument via ethernet cable.
The connect environment is not use any Hub or Router.
Maybe you don't believe it, But it it can work properly!

There are most ethernet port in PC is supported crossover, so it can connect direct both.

The Control PC IP Address is: 192.168.1.100 (DHCP disable, Static IP address)
The Instrument IP Address is: 192.168.1.1 (DHCP disable, Static IP address)

---

@billko

---

What I was getting at is it seems you are probably using a router.  Many routers have their IP addresses set to 192.168.1.1 by default.  If your device is set to the same IP address, you will have issues.  Also, if you have static IP addresses in a DHCP environment, you will have to reserve those addresses so the router doesn't place them in the address pool.

---

---

LOL - does it help if I say I believe you now?

---

[wiebe@CARYA]

Yes, two devices within the same IP range (specified by the subnet mask) can communicate directly over a normal cable. But only if at least one of them has a modern NIC.

Years ago, that would require a cross cable (IIRC, AKA patch cable). That cable would have RX and TX crossed...

Modern NICs can switch that automatically, so you can use any cable (crossed or straight). One (or both) of the NICs will switch until it works. Not sure when this change happened, I think around 10-15 years ago. Sure saves a lot of headaches. Getting flashbacks now...

[rolfk]

For some time after autonegotiation got introduced you could have some trouble if both sides were autonegotiation capable as they could be trying to autonegate over and over again and never come to a stable connection. Haven't seen that in recent years but anything more than 10 years old is definitely suspect.

[WIILE]

Update...

I tried to use the Instrument I/O Assistant to verify this problem.
In the Instrument I/O Assistant, The connection is working properly.
But, After finish the Instrument I/O Assistant, Back to Block Diagram,
The VISA Write Error is shown up.
Convert the Instrument I/O Assistant to VI component.
The VISA Write Error is still showing up.

Step1: Add the step : instrument source, write, read and parse.

Step2: Verify the SCPI Command. "Wirte" and "read and parse" ("queries" also work!)

Step3: In the NI I/O Trace, The command and response is normal after execute above the step.

Step4: After finish the Instrument I/O Assistant, Back to Block Diagram, The VISA Write Error is shown up.

Step5: Convert the Instrument I/O Assistant to VI component. The VISA Write Error is still showing up.

Step6: In the NI I/O Trace, Found a VISA Write error after execute above the step.

Until now, The status of VISA Write issue is below:

1. NI MAX => working

2. IN the LabVIEW Block Diagram => not working

3. Instrument I/O Assistant => working

4. In the LabVIEW Block Diagram after finish the Instrument I/O Assistant => not working

5. Convert the Instrument I/O Assistant to VI component in the LabVIEW=> not working

[Mancho00]

Are you sure that constant *IDN?\r is in '\' Codes display mode?

Edit: I've seen you using two different term characters.  You might want to verify you are using the correct one.

[Mark_Yedinak]

Would it be possible for you to get a Wireshark trace of the communications with the device? Get a capture of both a working connection and one from your code that is getting the error. Post the trace here. Something very odd is going on and seeing the packets might help to identify that.

[wiebe@CARYA]

Still no feedback on setting the port.

TCPIP[board]::host address[::host name]::port::SOCKET

There's a lot you can specify in a VISA TCP\IP resource. The port could be significant, as MAX might use another default than LabVIEW.

The board is another one. MAX might use a fixed connection, LabVIEW could be using WIFI? Who knows. Better to be explicit.