AnsweredAssumed Answered

vrf Auto-discover LAN instruments

Question asked by VRFuser on Sep 27, 2008
Latest reply on Sep 27, 2008 by VRFuser

Like • Show 0 Likes0
Comment • 17

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-

No one else has this question

Outcomes

17 Replies

VRFuser Sep 9, 2008 8:27 AM
Mark Correct
Correct Answer
Update...

I heard from Brian, and he said the board of the LXI Consortium does in fact want to keep their discovery code for members only.

That's ok - as I mentioned I now have a complete picture of how to do it, so all I need is free time. I don't know when that will be but if the VPN keeps bouncing today I might have developments later (don't hold your breath)...
-SHAWN-

---
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 9, 2008 8:27 AM
Mark Correct
Correct Answer
Update...

I heard from Brian, and he said the board of the LXI Consortium does in fact want to keep their discovery code for members only.

That's ok - as I mentioned I now have a complete picture of how to do it, so all I need is free time. I don't know when that will be but if the VPN keeps bouncing today I might have developments later (don't hold your breath)...
-SHAWN-

---
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 20, 2008 7:31 AM
Mark Correct
Correct Answer
NOTE: There is no attachment. This is the planning stage.

> IMPLEMENTATION

Ok I've made some decisions & am ready to proceed (you thought I forgot about this, didn't you?)

The implementation will be in Ruby. This isn't necessary, but it makes things much easier. Specifically, the implementation of XDR and the IP broadcast requirement.

XDR can be implemented in VEE of course, but VEE would limit the scope of the implementation. I'm thinking of the data source here. It is convenient to specify the source as a generic IO stream. Ruby does this by default, but VEE would require specific implementations for different sources. Normally, the source will be a UDP packet, but that won't necessarily always be the case.

Then the socket. First of all, I forgot that VEE only does stream sockets.
Second, socket options have to be set to use a broadcast address. This can be done with a Winsock control, but that limits applicability: not everybody has this and those who don't probably don't want to go to the trouble of downloading it.

Therefore, the implementation takes the form of a self-contained Ruby command-line executable (just like the Excel thing - which I also have not forgotten). VEE will call the executable & process output from it.

The Ruby implementation begins with classes for XDR & SUN port mapper communication. The port mapper communicator is the middle layer - it uses the XDR implementation internally. The mapper class is capable of accepting an initialized socket for purposes of broadcast and will use a timeout for listening for replies. Multiple replies are assumed if a passed socket has its SO_BROADCAST bit true.

The top layer is a simple VXI-11 probe. It requests the VXI-11 program number from all SUN port mapper services accessible on the network. Note that this makes no mention specifically of LXI. This will widen the search a bit.

Network broadcasting takes a limited form of subnet & LAN. A subnet broadcast is sufficient to find instruments on the same side of the router as the computer trying to discover them. A LAN broadcast will find all instruments on the LAN. This could mean all instruments in your department, group or company depending on how your network is set up. It could also mean all instruments on your WAN if you're connected to a VPN (and appropriate routing is set up).

In general, the terms "subnet" and "LAN" are intended to mean "all hosts"
and "all subnets" as those terms are used in section 7 of RFC 922. The -s option (default) uses the broadcast address 255.255.255.255 and the -l option uses the broadcast address ~(subnet mask) | (host IP). If a wider broadcast area is needed, use the -b xxx.xxx.xxx.xxx option to specify a broadcast address. Exactly what address to use is something you'll have to talk to your network administrator about.

A VXI-11 protocol implementation will not be included. once VXI-11 servers are found, the local VISA implementation will be used to send an identification request to the instruments. If no local VISA implementation is found, then output will not contain instrument identification data, but will contain VXI-11 server addresses.

The implementation of XDR will probably take the longest. It's not all that difficult, but it has to be tested over the scope of the conversation with the port mapper (at least). I can spend a few hours on it today & probably a few next week, but I can't really say when this will be done to the point of found servers ready for querying.

The querying of found servers and the discovery of remote SCPI will be later phases.

All this will be free software (as usual). All this is subject to change as experimentation reveals.
-SHAWN-

---
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 20, 2008 7:31 AM
Mark Correct
Correct Answer
NOTE: There is no attachment. This is the planning stage.

> IMPLEMENTATION

Ok I've made some decisions & am ready to proceed (you thought I forgot about this, didn't you?)

The implementation will be in Ruby. This isn't necessary, but it makes things much easier. Specifically, the implementation of XDR and the IP broadcast requirement.

XDR can be implemented in VEE of course, but VEE would limit the scope of the implementation. I'm thinking of the data source here. It is convenient to specify the source as a generic IO stream. Ruby does this by default, but VEE would require specific implementations for different sources. Normally, the source will be a UDP packet, but that won't necessarily always be the case.

Then the socket. First of all, I forgot that VEE only does stream sockets.
Second, socket options have to be set to use a broadcast address. This can be done with a Winsock control, but that limits applicability: not everybody has this and those who don't probably don't want to go to the trouble of downloading it.

Therefore, the implementation takes the form of a self-contained Ruby command-line executable (just like the Excel thing - which I also have not forgotten). VEE will call the executable & process output from it.

The Ruby implementation begins with classes for XDR & SUN port mapper communication. The port mapper communicator is the middle layer - it uses the XDR implementation internally. The mapper class is capable of accepting an initialized socket for purposes of broadcast and will use a timeout for listening for replies. Multiple replies are assumed if a passed socket has its SO_BROADCAST bit true.

The top layer is a simple VXI-11 probe. It requests the VXI-11 program number from all SUN port mapper services accessible on the network. Note that this makes no mention specifically of LXI. This will widen the search a bit.

Network broadcasting takes a limited form of subnet & LAN. A subnet broadcast is sufficient to find instruments on the same side of the router as the computer trying to discover them. A LAN broadcast will find all instruments on the LAN. This could mean all instruments in your department, group or company depending on how your network is set up. It could also mean all instruments on your WAN if you're connected to a VPN (and appropriate routing is set up).

In general, the terms "subnet" and "LAN" are intended to mean "all hosts"
and "all subnets" as those terms are used in section 7 of RFC 922. The -s option (default) uses the broadcast address 255.255.255.255 and the -l option uses the broadcast address ~(subnet mask) | (host IP). If a wider broadcast area is needed, use the -b xxx.xxx.xxx.xxx option to specify a broadcast address. Exactly what address to use is something you'll have to talk to your network administrator about.

A VXI-11 protocol implementation will not be included. once VXI-11 servers are found, the local VISA implementation will be used to send an identification request to the instruments. If no local VISA implementation is found, then output will not contain instrument identification data, but will contain VXI-11 server addresses.

The implementation of XDR will probably take the longest. It's not all that difficult, but it has to be tested over the scope of the conversation with the port mapper (at least). I can spend a few hours on it today & probably a few next week, but I can't really say when this will be done to the point of found servers ready for querying.

The querying of found servers and the discovery of remote SCPI will be later phases.

All this will be free software (as usual). All this is subject to change as experimentation reveals.
-SHAWN-

---
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 21, 2008 4:17 PM
Mark Correct
Correct Answer
Shawn,

Looking forward to seeing the results, (note: I avoided using "Finished Product" 'cause I know it's never "really" finished J)

We are starting to see more Ethernet enabled Test Equipment and from a Unit Under Test, point of view, it would be nice to auto-find it on the network, (Quicker to connect RJ 45 than GPIB) then I’d be able to query the model, serial Number, etc, to ensure it is the correct one.

It’s a Pity Agilent haven’t done something like this already. Especially for Newbie Programmers, it would make VEE far more usable and attractive. Just my 2 Bobs worth.

<General Interest> A Bob was the British and hence Australian nick name for a Shilling or 12 Pence piece, so 2 Bob, was worth 24 Pence [Pre Decimalisation]) </ General Interest >

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: Sunday, 21 September 2008 12:30 AM
To: VRF
Subject: RE: [vrf] Auto-discover LAN instruments

NOTE: There is no attachment. This is the planning stage.

> IMPLEMENTATION

Ok I've made some decisions & am ready to proceed (you thought I forgot

about this, didn't you?)

The implementation will be in Ruby. This isn't necessary, but it makes

things much easier. Specifically, the implementation of XDR and the IP

broadcast requirement.

XDR can be implemented in VEE of course, but VEE would limit the scope of

the implementation. I'm thinking of the data source here. It is convenient

to specify the source as a generic IO stream. Ruby does this by default, but

VEE would require specific implementations for different sources. Normally,

the source will be a UDP packet, but that won't necessarily always be the

case.

Then the socket. First of all, I forgot that VEE only does stream sockets.

Second, socket options have to be set to use a broadcast address. This can

be done with a Winsock control, but that limits applicability: not everybody

has this and those who don't probably don't want to go to the trouble of

downloading it.

Therefore, the implementation takes the form of a self-contained Ruby

command-line executable (just like the Excel thing - which I also have not

forgotten). VEE will call the executable & process output from it.

The Ruby implementation begins with classes for XDR & SUN port mapper

communication. The port mapper communicator is the middle layer - it uses

the XDR implementation internally. The mapper class is capable of accepting

an initialized socket for purposes of broadcast and will use a timeout for

listening for replies. Multiple replies are assumed if a passed socket has

its SO_BROADCAST bit true.

The top layer is a simple VXI-11 probe. It requests the VXI-11 program

number from all SUN port mapper services accessible on the network. Note

that this makes no mention specifically of LXI. This will widen the search a

bit.

Network broadcasting takes a limited form of subnet & LAN. A subnet

broadcast is sufficient to find instruments on the same side of the router

as the computer trying to discover them. A LAN broadcast will find all

instruments on the LAN. This could mean all instruments in your department,

group or company depending on how your network is set up. It could also mean

all instruments on your WAN if you're connected to a VPN (and appropriate

routing is set up).

In general, the terms "subnet" and "LAN" are intended to mean "all hosts"

and "all subnets" as those terms are used in section 7 of RFC 922. The -s

option (default) uses the broadcast address 255.255.255.255 and the -l

option uses the broadcast address ~(subnet mask) | (host IP). If a wider

broadcast area is needed, use the -b xxx.xxx.xxx.xxx option to specify a

broadcast address. Exactly what address to use is something you'll have to

talk to your network administrator about.

A VXI-11 protocol implementation will not be included. once VXI-11 servers

are found, the local VISA implementation will be used to send an

identification request to the instruments. If no local VISA implementation

is found, then output will not contain instrument identification data, but

will contain VXI-11 server addresses.

The implementation of XDR will probably take the longest. It's not all that

difficult, but it has to be tested over the scope of the conversation with

the port mapper (at least). I can spend a few hours on it today & probably a

few next week, but I can't really say when this will be done to the point of

found servers ready for querying.

The querying of found servers and the discovery of remote SCPI will be later

phases.

All this will be free software (as usual). All this is subject to change as

experimentation reveals.

-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: 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".
Like • Show 0 Likes0
Actions
VRFuser Sep 21, 2008 4:17 PM
Mark Correct
Correct Answer
Shawn,

Looking forward to seeing the results, (note: I avoided using "Finished Product" 'cause I know it's never "really" finished J)

We are starting to see more Ethernet enabled Test Equipment and from a Unit Under Test, point of view, it would be nice to auto-find it on the network, (Quicker to connect RJ 45 than GPIB) then I’d be able to query the model, serial Number, etc, to ensure it is the correct one.

It’s a Pity Agilent haven’t done something like this already. Especially for Newbie Programmers, it would make VEE far more usable and attractive. Just my 2 Bobs worth.

<General Interest> A Bob was the British and hence Australian nick name for a Shilling or 12 Pence piece, so 2 Bob, was worth 24 Pence [Pre Decimalisation]) </ General Interest >

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: Sunday, 21 September 2008 12:30 AM
To: VRF
Subject: RE: [vrf] Auto-discover LAN instruments

NOTE: There is no attachment. This is the planning stage.

> IMPLEMENTATION

Ok I've made some decisions & am ready to proceed (you thought I forgot

about this, didn't you?)

The implementation will be in Ruby. This isn't necessary, but it makes

things much easier. Specifically, the implementation of XDR and the IP

broadcast requirement.

XDR can be implemented in VEE of course, but VEE would limit the scope of

the implementation. I'm thinking of the data source here. It is convenient

to specify the source as a generic IO stream. Ruby does this by default, but

VEE would require specific implementations for different sources. Normally,

the source will be a UDP packet, but that won't necessarily always be the

case.

Then the socket. First of all, I forgot that VEE only does stream sockets.

Second, socket options have to be set to use a broadcast address. This can

be done with a Winsock control, but that limits applicability: not everybody

has this and those who don't probably don't want to go to the trouble of

downloading it.

Therefore, the implementation takes the form of a self-contained Ruby

command-line executable (just like the Excel thing - which I also have not

forgotten). VEE will call the executable & process output from it.

The Ruby implementation begins with classes for XDR & SUN port mapper

communication. The port mapper communicator is the middle layer - it uses

the XDR implementation internally. The mapper class is capable of accepting

an initialized socket for purposes of broadcast and will use a timeout for

listening for replies. Multiple replies are assumed if a passed socket has

its SO_BROADCAST bit true.

The top layer is a simple VXI-11 probe. It requests the VXI-11 program

number from all SUN port mapper services accessible on the network. Note

that this makes no mention specifically of LXI. This will widen the search a

bit.

Network broadcasting takes a limited form of subnet & LAN. A subnet

broadcast is sufficient to find instruments on the same side of the router

as the computer trying to discover them. A LAN broadcast will find all

instruments on the LAN. This could mean all instruments in your department,

group or company depending on how your network is set up. It could also mean

all instruments on your WAN if you're connected to a VPN (and appropriate

routing is set up).

In general, the terms "subnet" and "LAN" are intended to mean "all hosts"

and "all subnets" as those terms are used in section 7 of RFC 922. The -s

option (default) uses the broadcast address 255.255.255.255 and the -l

option uses the broadcast address ~(subnet mask) | (host IP). If a wider

broadcast area is needed, use the -b xxx.xxx.xxx.xxx option to specify a

broadcast address. Exactly what address to use is something you'll have to

talk to your network administrator about.

A VXI-11 protocol implementation will not be included. once VXI-11 servers

are found, the local VISA implementation will be used to send an

identification request to the instruments. If no local VISA implementation

is found, then output will not contain instrument identification data, but

will contain VXI-11 server addresses.

The implementation of XDR will probably take the longest. It's not all that

difficult, but it has to be tested over the scope of the conversation with

the port mapper (at least). I can spend a few hours on it today & probably a

few next week, but I can't really say when this will be done to the point of

found servers ready for querying.

The querying of found servers and the discovery of remote SCPI will be later

phases.

All this will be free software (as usual). All this is subject to change as

experimentation reveals.

-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: 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".
Like • Show 0 Likes0
Actions
VRFuser Sep 21, 2008 6:12 PM
Mark Correct
Correct Answer
> It’s a Pity Agilent haven’t done something like this already.

I'm puzzled.
Certainly *somebody* should have.
Kinda makes you go "hmmm..."

Then again there was that one Rush album. Back in 1976.

XDR is finished. Next weekend I'll do the pmap stuff & start playing with real instruments.
-SHAWN-
Like • Show 0 Likes0
Actions
VRFuser Sep 21, 2008 6:12 PM
Mark Correct
Correct Answer
> It’s a Pity Agilent haven’t done something like this already.

I'm puzzled.
Certainly *somebody* should have.
Kinda makes you go "hmmm..."

Then again there was that one Rush album. Back in 1976.

XDR is finished. Next weekend I'll do the pmap stuff & start playing with real instruments.
-SHAWN-
Like • Show 0 Likes0
Actions
VRFuser Sep 22, 2008 4:43 PM
Mark Correct
Correct Answer
Actually, it was done several times. First, there was a mod to the VISA search routines to accommodate lan for plug&play. Then we did auto search as part of IntuiLink. I believe the lan auto search was released as part of the I/O toolbox examples. Our company also did something as part of the ill fated Test Express development. No idea why it is suddenly "secret".

Jay Nemeth-Johannes
3420 Riverside Street
Rockford, Illinois 61103
(815) 708-0423
(970) 290-9797 (Cell)
www.SmartSensorSystems.com

> -----Original Message-----
> From: Shawn Fessenden [mailto:shawn@vrfarchive.com]
> Sent: Sunday, September 21, 2008 8:12 PM
> To: VRF
> Subject: RE: [vrf] Auto-discover LAN instruments
>
> > It's a Pity Agilent haven't done something like this already.
>
> I'm puzzled.
> Certainly *somebody* should have.
> Kinda makes you go "hmmm..."
>
> Then again there was that one Rush album. Back in 1976.
>
> XDR is finished. Next weekend I'll do the pmap stuff & start playing
> with real instruments.
> -SHAWN-
>

---
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 22, 2008 4:43 PM
Mark Correct
Correct Answer
Actually, it was done several times. First, there was a mod to the VISA search routines to accommodate lan for plug&play. Then we did auto search as part of IntuiLink. I believe the lan auto search was released as part of the I/O toolbox examples. Our company also did something as part of the ill fated Test Express development. No idea why it is suddenly "secret".

Jay Nemeth-Johannes
3420 Riverside Street
Rockford, Illinois 61103
(815) 708-0423
(970) 290-9797 (Cell)
www.SmartSensorSystems.com

> -----Original Message-----
> From: Shawn Fessenden [mailto:shawn@vrfarchive.com]
> Sent: Sunday, September 21, 2008 8:12 PM
> To: VRF
> Subject: RE: [vrf] Auto-discover LAN instruments
>
> > It's a Pity Agilent haven't done something like this already.
>
> I'm puzzled.
> Certainly *somebody* should have.
> Kinda makes you go "hmmm..."
>
> Then again there was that one Rush album. Back in 1976.
>
> XDR is finished. Next weekend I'll do the pmap stuff & start playing
> with real instruments.
> -SHAWN-
>

---
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 22, 2008 7:25 PM
Mark Correct
Correct Answer
> 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: 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".
Like • Show 0 Likes0
Actions
VRFuser Sep 22, 2008 7:25 PM
Mark Correct
Correct Answer
> 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: 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".
Like • Show 0 Likes0
Actions
VRFuser Sep 24, 2008 6:41 PM
Mark Correct
Correct Answer
I'd like to compress data on the disk. Certianly PKZIP command-line interface work, but I'm thinking that the .NET capabilties would run faster. I've found information about the System.IO.Compression namespace but I'm having trouble accessing in VEE 7.52. Are there any VEE examples on how to use this .. to compress group of file into one zip file?

Kathy Wright

----- Original Message ----
From: "Voltz, Gary" <gary.voltz@AirservicesAustralia.com>
To: VRF <vrf@agilent.com>
Sent: Thursday, September 25, 2008 8:38:49 AM
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: HYPERLINK "mailto:gary.voltz@airservicesaustralia.com"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
HYPERLINK "http://www.airservicesaustralia.com/"
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:HYPERLINK "mailto:shawn@vrfarchive.com"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: HYPERLINK "mailto:gary.voltz@airservicesaustralia.com"gary.voltz@airservicesaustralia.com
To subscribe please send an email to: "HYPERLINK "mailto:vrf-request@lists.it.agilent.com"vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "HYPERLINK "mailto:leave-vrf@it.lists.it.agilent.com"leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "HYPERLINK "mailto:vrf@agilent.com"vrf@agilent.com".
If you need help with the mailing list send a message to
"HYPERLINK "mailto:owner-vrf@it.lists.it.agilent.com"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 "HYPERLINK "http://vee.engineering.agilent.com/"
http://vee.engineering.agilent.com".

---
You are currently subscribed to vrf as: HYPERLINK "mailto:kathy_wright_ca@yahoo.com"kathy_wright_ca@yahoo.com
To subscribe please send an email to: "HYPERLINK "mailto:vrf-request@lists.it.agilent.com"vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "HYPERLINK "mailto:leave-vrf@it.lists.it.agilent.com"leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "HYPERLINK "mailto:vrf@agilent.com"vrf@agilent.com".
If you need help with the mailing list send a message to
"HYPERLINK "mailto:owner-vrf@it.lists.it.agilent.com"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 "HYPERLINK "http://vee.engineering.agilent.com/"
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 24, 2008 6:41 PM
Mark Correct
Correct Answer
I'd like to compress data on the disk. Certianly PKZIP command-line interface work, but I'm thinking that the .NET capabilties would run faster. I've found information about the System.IO.Compression namespace but I'm having trouble accessing in VEE 7.52. Are there any VEE examples on how to use this .. to compress group of file into one zip file?

Kathy Wright

----- Original Message ----
From: "Voltz, Gary" <gary.voltz@AirservicesAustralia.com>
To: VRF <vrf@agilent.com>
Sent: Thursday, September 25, 2008 8:38:49 AM
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: HYPERLINK "mailto:gary.voltz@airservicesaustralia.com"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
HYPERLINK "http://www.airservicesaustralia.com/"
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:HYPERLINK "mailto:shawn@vrfarchive.com"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: HYPERLINK "mailto:gary.voltz@airservicesaustralia.com"gary.voltz@airservicesaustralia.com
To subscribe please send an email to: "HYPERLINK "mailto:vrf-request@lists.it.agilent.com"vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "HYPERLINK "mailto:leave-vrf@it.lists.it.agilent.com"leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "HYPERLINK "mailto:vrf@agilent.com"vrf@agilent.com".
If you need help with the mailing list send a message to
"HYPERLINK "mailto:owner-vrf@it.lists.it.agilent.com"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 "HYPERLINK "http://vee.engineering.agilent.com/"
http://vee.engineering.agilent.com".

---
You are currently subscribed to vrf as: HYPERLINK "mailto:kathy_wright_ca@yahoo.com"kathy_wright_ca@yahoo.com
To subscribe please send an email to: "HYPERLINK "mailto:vrf-request@lists.it.agilent.com"vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "HYPERLINK "mailto:leave-vrf@it.lists.it.agilent.com"leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "HYPERLINK "mailto:vrf@agilent.com"vrf@agilent.com".
If you need help with the mailing list send a message to
"HYPERLINK "mailto:owner-vrf@it.lists.it.agilent.com"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 "HYPERLINK "http://vee.engineering.agilent.com/"
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 24, 2008 9:51 PM
Mark Correct
Correct Answer
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 24, 2008 9:51 PM
Mark Correct
Correct Answer
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 27, 2008 10:58 AM
Mark Correct
Correct Answer
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-
Like • Show 0 Likes0
Actions

vrf Auto-discover LAN instruments

Outcomes

Related Content

Recommended Content