I think you can just do the following:
1) Talk to the instruments that have the common setup
2) Perform an Execute Close on the serial port using Direct I/O
3) Talk to the instruments with the other setup
4) Perform another execute close.
5) Repeat
I have done this when I used a common serial port with two programs and needed to release the port.
Dave Andersen
-----Original Message-----
From: Shawn Fessenden [mailto:shawnfess@comcast.net]
Sent: Tuesday, March 28, 2006 2:11 PM
To: VRF
Subject: RE: [vrf] Communications changes
Define two serial instruments, one with no parity and one with even parity. Try communicating with one. Feed an error pin to a close transaction and then try the other. You can do the same thing by varying the parameters dynamically, but the port has to be closed when you change parameters.
-SHAWN-
---
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 "www.oswegosw.com/vrf_archive/".
I think you can just do the following:
1) Talk to the instruments that have the common setup
2) Perform an Execute Close on the serial port using Direct I/O
3) Talk to the instruments with the other setup
4) Perform another execute close.
5) Repeat
I have done this when I used a common serial port with two programs and
needed to release the port.
Dave Andersen
-----Original Message-----
From: Shawn Fessenden [mailto:shawnfess@comcast.net]
Sent: Tuesday, March 28, 2006 2:11 PM
To: VRF
Subject: RE: [vrf] Communications changes
Define two serial instruments, one with no parity and one with even
parity. Try communicating with one. Feed an error pin to a close
transaction and then try the other. You can do the same thing by varying
the parameters dynamically, but the port has to be closed when you
change parameters.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.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 "www.oswegosw.com/vrf_archive/".
~100 and even within half of that is fairly rare to have to deal with.
I was originally hoping to be able to just dictate the comm settings to
be used, however there is one unit that needs to be monitored on which
the parity cannot be changed.
Would you be able to elaborate on the possible solutions you mentioned,
as well as the MS COMM control?
-----Original Message-----
From: Shawn Fessenden [mailto:shawnfess@comcast.net]
Sent: Tuesday, March 28, 2006 14:52
To: Sean Watson; 'VRF'
Subject: RE: [vrf] Communications changes
> I have tried several solutions along
> the lines of simply sending an extra
> message with the settings for X
> before actually trying to
> communicate with the units, but this
> has not helped.
It won't. You have to set up parameters before the port is opened. If
there's absolutely no way you can dictate comm parameters then there are
a few different ways to go about it, but each has different advantages
and disadvantages. Principal among the disadvantages is that all methods
involve an error output. If the application is to be a long-running
solution (involving hundreds of thousands of units) then stay away from
any solution that uses error pins.
Ultimately an alternative comm scenario is probably desirable. MS COMM
control is available to almost any computer if you stay away from design
time requirements and is easy to use.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.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 "www.oswegosw.com/vrf_archive/".
Â
I am trying to communicate with a set of different units in a cycle (unit 1 - unit 2 - ... - unit 1 - ...), but not all of them have the same communications settings. Now, if I have unit X and unit Y in the instrument manager with the following settings:
                                X                              Y   Â
Baud Rate:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 9600Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 9600
Character Size:Â Â Â Â Â Â Â Â Â Â 7Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 7
Stop Bits:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 1Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 1
Parity:                       Even                         None
Handshake:               None                         None
Receive Buffer Size:Â Â Â 4096Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4096
Â
So in a loop of several units of type Y and one of type X what I find is that all the units of type Y will respond to inquiries while the unit of type X does not. If there are two or more of type X, then only the first does not respond and any successive units will.
Â
I have tried several solutions along the lines of simply sending an extra message with the settings for X before actually trying to communicate with the units, but this has not helped.
Â
Does anyone have a possible explanations or solutions for this problem?
Â
Â
Â
Thanks,
Â
Sean
---
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 "www.oswegosw.com/vrf_archive/".
> the lines of simply sending an extra
> message with the settings for X
> before actually trying to
> communicate with the units, but this
> has not helped.
It won't. You have to set up parameters before the port is opened. If there's absolutely no way you can dictate comm parameters then there are a few different ways to go about it, but each has different advantages and disadvantages. Principal among the disadvantages is that all methods involve an error output. If the application is to be a long-running solution (involving hundreds of thousands of units) then stay away from any solution that uses error pins.
Ultimately an alternative comm scenario is probably desirable. MS COMM control is available to almost any computer if you stay away from design time requirements and is easy to use.
-SHAWN-
I was originally hoping to be able to just dictate the comm settings to be used, however there is one unit that needs to be monitored on which the parity cannot be changed.
Would you be able to elaborate on the possible solutions you mentioned, as well as the MS COMM control?
-----Original Message-----
From: Shawn Fessenden [mailto:shawnfess@comcast.net]
Sent: Tuesday, March 28, 2006 14:52
To: Sean Watson; 'VRF'
Subject: RE: [vrf] Communications changes
> I have tried several solutions along
> the lines of simply sending an extra
> message with the settings for X
> before actually trying to
> communicate with the units, but this
> has not helped.
It won't. You have to set up parameters before the port is opened. If there's absolutely no way you can dictate comm parameters then there are a few different ways to go about it, but each has different advantages and disadvantages. Principal among the disadvantages is that all methods involve an error output. If the application is to be a long-running solution (involving hundreds of thousands of units) then stay away from any solution that uses error pins.
Ultimately an alternative comm scenario is probably desirable. MS COMM control is available to almost any computer if you stay away from design time requirements and is easy to use.
-SHAWN-
---
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 "www.oswegosw.com/vrf_archive/".
-SHAWN-