Thread: [vrf] Auto-discover LAN instruments


Permlink Replies: 17 - Pages: 2 [ Previous | 1 2 ] - Last Post: Sep 9, 2008 9:27 AM Last Post By: VRF user
VRF user

Posts: 16,231
Registered: 11/05/08
[vrf] Auto-discover LAN instruments
Posted: Sep 24, 2008 10:51 PM   in response to: VRF user in response to: VRF user
Click to report abuse...   Click to reply to this thread Reply
I had a quick look and it appears that the Interface type drop-down selection box has initial value set to GPIB and "Wait for input" to false. So, it would surely go ahead and do a GPIB search first.

Regards,
Uday

-----Original Message-----
From: Voltz, Gary mailto:gary.voltz@AirservicesAustralia.com
Sent: Thursday, September 25, 2008 7:09 AM
To: VRF
Subject: RE: vrf Auto-discover LAN instruments

Shawn,

I've attached a Program I originally wrote to query New Rohde & Schwarz Signal Generators, so we could check serial numbers and options.

My preference was to use TCP/IP as the connection is quick and Simple. However, despite working well initially, something has gone wrong, and it will only work on GPIB.

The thing I really find bizarre, is that it always queries all instruments on the GPIB even when TCP/IP is selected.

I thought that with you experience, or that of other VRFers that you might be able to pout your finger on what it is that I'm missing.

I also thought it might point to a possible simpler solution to what we all want.

Development Machine and Runtime Machine:
VEE 7.52 Windows XP Home SP3.

Cheers,
Gary


Gary Voltz
Technical Officer (SASTO4)

Test Equipment Maintenance and Calibration Centre (TEMACC) Facilities Management Services Technology and Asset Services Airservices Australia

E-mail: gary.voltz@airservicesaustralia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Airservices Australia
Ph 1300 301 120 (within Australia)
07 3886 3382
Ph +61 7 3866 3382 (outside Australia)
Fax +61 7 3866 3531
www.airservicesaustralia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CAUTION: This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail and delete the document.

Airservices Australia does not represent, warrant or guarantee that the integrity of this communication is free of errors, virus or interference.

-----Original Message-----
From: Shawn Fessenden mailto:shawn@vrfarchive.com
Sent: Tuesday, 23 September 2008 12:24 PM
To: VRF
Subject: RE: vrf Auto-discover LAN instruments

> No idea why it is suddenly "secret".

Do you know if any of this survives anywhere?

I'm just completely perplexed at the lack of any directional material anywhere within my own references or on the internet. Out of hours of searching, all I came up with is that one simple paragraph from one Consortium publication.

Here I am watching a documentary on the Rosicrucians and it's simply reinforcing ridiculous conspiratorial thoughts! I don't really think the "Priests" are to blame <g> but it's difficult to understand how such a crucial component of zero-config automation could have been overlooked.
-SHAWN-




---
You are currently subscribed to vrf as: gary.voltz@airservicesaustralia.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".


---
You are currently subscribed to vrf as: udaya.nandiwada@broadcom.com To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".



---
You are currently subscribed to vrf as: hua_jing@agilent.com To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".

VRF user

Posts: 16,231
Registered: 11/05/08
[vrf] Auto-discover LAN instruments
Posted: Sep 27, 2008 11:58 AM
Click to report abuse...   Click to reply to this thread Reply
STATUS

There was a bit more work to do with respect to XDR.

The XDR specification (RFC 1014 is the document I'm using) defines not only a wire protocol, but a notational convention used to describe complex types. As I was writing the sunrpc class, it occurred to me that I was needlessly limiting what it could do by building in call sequences to read and write XDR entities. Furthermore, XDR entities can contain other XDR entities and this self-referential schema couldn't be handled by my own implementation.

Therefore, I decided to pile a couple more layers on top of the XDR primitive class. Today's goal is to finish & test XdrEntity, a class responsible for parsing XDR entity specifications & translating them into primitive read and write calls.

The top class will be a light wrapper that manipulates the lower-level APIs.

The current sunrpc work is simplified by this decision. I didn't really waste any time, just decided to rearrange things a little.

In the end, I don't think I'll get to talking to instruments today. I can spend another four hours or so on this, then I have to switch back to real work. Sunday needs real work done too.

So, talking to instruments will have to wait until next weekend.
-SHAWN-
VRF user

Posts: 16,231
Registered: 11/05/08
[vrf] Auto-discover LAN instruments
Posted: Sep 27, 2008 11:58 AM   in response to: VRF user in response to: VRF user
Click to report abuse...   Click to reply to this thread Reply
STATUS

There was a bit more work to do with respect to XDR.

The XDR specification (RFC 1014 is the document I'm using) defines not only a wire protocol, but a notational convention used to describe complex types. As I was writing the sunrpc class, it occurred to me that I was needlessly limiting what it could do by building in call sequences to read and write XDR entities. Furthermore, XDR entities can contain other XDR entities and this self-referential schema couldn't be handled by my own implementation.

Therefore, I decided to pile a couple more layers on top of the XDR primitive class. Today's goal is to finish & test XdrEntity, a class responsible for parsing XDR entity specifications & translating them into primitive read and write calls.

The top class will be a light wrapper that manipulates the lower-level APIs.

The current sunrpc work is simplified by this decision. I didn't really waste any time, just decided to rearrange things a little.

In the end, I don't think I'll get to talking to instruments today. I can spend another four hours or so on this, then I have to switch back to real work. Sunday needs real work done too.

So, talking to instruments will have to wait until next weekend.
-SHAWN-

Point your RSS reader here for a feed of the latest messages in all forums