LabVIEW
Chaining Instrument Driver VISA (dup) output versus using VISA output of Initialize
Jeff Bohrer wrote:
Ravens Fan wrote:Jeff,
This thread started with you asking about whether splitting the VISA resource wire vs. using it as part of a call change mattered. And I don't think it does.
** Not true! Requesting permission to speak frankly Ravens Fan (go BILLL!,) Sure The thread started with the OP asking if passing a VISA :GPIB: INST (or any other class) variable via Dup- or Resource out COULD cause any difference! It most certainly can- "dup" out = "dup" in, "Resource out" may differ from "Resource in" (hence the "dup") as you well know!
Yes, if within a subVI, you have a VISA coming in, and the wire makes it something else, (Com1 becomes Com2) then yes they will be different. Maybe there is something different about GPIB, but I don't know because my frame of reference is from serial ports. But I would assume they should behave similiarly because otherwise they shouldn't be all grouped under "VISA". As for out vs. in. vs "dup", I don't know if that means anything other than what the programmer of the subVI used for naming the controls and indicators for passing the references in and out..
The example you just posted is showing an issue that has nothing to do with the VISA resource wire, but how the values in the property node of the resource are changing or not changing. With a valid VISA resource, the changes seem to occur just fine. And I don't think this has anything to do with the source of the purple wire.
** Exactly my point*** can you find a more effecient way of passing the properties of a method of a class? changing properties CANNOT break classes (overloaded methods are handled internal to the class so are exempted but we could argue the distinction ) This is more of an object oriented programming perspective, and whether you can truly apply that to this situation with VISA resources, I don't know.
Remember the VISA resource is basically just a pointer to a physical hardware port
*** a pointer! refer to the vi I responded with, The resource properties may or may not represent deterministic states of the instrument--- and those deterministic states are what is important in communicating with the instrument aren't they? --- *** well, technically, they are only important if you want scientific data that you can base a conclusion on (But, I digress--LV and experiments employing the "scientific method" should have ????? how much commonality? ! RF?,! D? I'm sure its overkill but, that point IS important)
(or software port in cases of TCP/IP connections.) The properties of the VISA resource are not carried along the purple wire,
-- yep----
so there is no such thing as a "stale VISA session"
nope Just a Reference who's properties do not agree with the state of the instrument....
The properties of the reference have nothing do to with the state of the instrument. If the instrument is set for 9600 baud, the VISA resource could be set for 2400 baud. One doesn't necessarily equal the other. Of course, if the resource's properties aren't set to match the instrument, you are going to have major communication problems. It is up to the programmer to know what the requirements are of the instrument and set the properties of the resource to match. If in the middle of the program you decide to change instruments, or VISA ports, or settings in the instrument, again it is up to the programmer to set all of that to match (and remember the settings as necessary through functional globals, shift registers, or regular globals .....) In reality, there is no way to determine what the properties are of an instrument at a given point in time unless you have established communication with it. I can easily go to an instrument and change its baud rate or parity using front panel push buttons. It would kill communications. How would LV know that those properties had changed?
Are we getting to a point of agreement with empiracal states yet, (I'm not MAD, just dissapointed)
So if your original port, for instance is Com 3...
++What com trree in my OP?)+++ (I just picked com3 has an example of a VISA resource)
...with a baud rate of 9600. And you change that baud rate to 2400 using the VISA resource along the lower purple wire
How? the purple wire does not affect the "resource just the resource properties!"---
, that baud rate becomes 2400 for Com3. And it stays that way whether you refer to Com3 again using the upper wire or the lower wire.vvvvv
NO RF- the purple wire in has proerties different than the purple wire out of the property node I used to make the change from P.Baudrate=9600 to P.Baudrate=2400. but you can compare those "wires" CLASSES and the result is they are equal---- VERY dangerous if you want to know the dynamic state of the instrument AND comminicate with it dynamically...
No, the purple wire has no properties other than saying "hey we want to be referring to Com1, or Com3, or GPIB5, or ....,)
Really- this isn't rocket science.
instrument state = VISA resource properties.
You can only mix them up by using "Dup resource out" or failing to use a shift register and / or an AE when necessary, to co-ordinate the instrument and VISA property settings
Exactly, up to the programmer to handle all these details and track them. And possibly the user of the program to tell the program when an instrument has changed. If the user was using instrument 1 on Com1, but is now using instrument 2 on a GPIB bus, there is no way for the program to know the user's intentions. The user makes some change in the front panel to signal their intentions, and the programmer handles those details of what resource to use and how to set the resource's properties so that they match the instrument's properties by the way of writing good programming code.
Sorry to rant but...WTF guys?
I'm not taking it as a rant. The only thing that worries me is that we are debating something and then only to find out the details we are debating are actually about two completely different things.
Maybe it is all semantics. To me, the purple wire is a pointer to a VISA resource. I'll use the term pointer "loosely" as I know it can have very specific meanings in OO languages and other high level languages such as C. The VISA resource is basically a hardware port such as serial or parallel, or a software port such as a TCP/IP machine/port, or aGPIB board and address, or .... That port has properties that must be set to communicate with an instrument or device. That instrument/device could be another piece of hardware at the end of the cable or another PC. That instrument on the other end has its own set of properties for communciation. If you set the properties of the VISA resource to match the properties of the instrument, you should have communication. If the properties don't match, you probably won't have communication, or at best corrupted communication. If you change the instrument, or change the VISA resource you want to connect to it with, then you will have to program things so that those properties match.
Jeff Bohrer wrote:OMG!
I think I thought through the communications block. I Sincerly appologize for any offence.
VISA Resource,<property>.<value> seems dynamic from LabVIEW
AND INSTRUMENT,<property>.<value> seems STATIC from LabVIEW.
Duh- (my lack of detailed explaination not your ability to understand) VISA was developed to account for the fact that there are Instruments with dynamic communication properties. not just different Instruments who's properties are not the same.
OOFDA-
No offense.
Unfortunately I just saw your new post after I did a lot of replying to your previous message. Hopefully what I added there will show we are thinking on the same page now.
What does OOFDA mean?
Ravens Fan wrote:
Jeff Bohrer wrote:
Ravens Fan wrote:Jeff,
This thread started with you asking about whether splitting the VISA resource wire vs. using it as part of a call change mattered. And I don't think it does.
** Not true! Requesting permission to speak frankly Ravens Fan (go BILLL!,) Sure The thread started with the OP asking if passing a VISA :GPIB: INST (or any other class) variable via Dup- or Resource out COULD cause any difference! It most certainly can- "dup" out = "dup" in, "Resource out" may differ from "Resource in" (hence the "dup") as you well know!
Yes, if within a subVI, you have a VISA coming in, and the wire makes it something else, (Com1 becomes Com2) then yes they will be different. Maybe there is something different about GPIB, but I don't know because my frame of reference is from serial ports. But I would assume they should behave similiarly because otherwise they shouldn't be all grouped under "VISA". As for out vs. in. vs "dup", I don't know if that means anything other than what the programmer of the subVI used for naming the controls and indicators for passing the references in and out..
The example you just posted is showing an issue that has nothing to do with the VISA resource wire, but how the values in the property node of the resource are changing or not changing. With a valid VISA resource, the changes seem to occur just fine. And I don't think this has anything to do with the source of the purple wire.
** Exactly my point*** can you find a more effecient way of passing the properties of a method of a class? changing properties CANNOT break classes (overloaded methods are handled internal to the class so are exempted but we could argue the distinction ) This is more of an object oriented programming perspective, and whether you can truly apply that to this situation with VISA resources, I don't know.
Remember the VISA resource is basically just a pointer to a physical hardware port
*** a pointer! refer to the vi I responded with, The resource properties may or may not represent deterministic states of the instrument--- and those deterministic states are what is important in communicating with the instrument aren't they? --- *** well, technically, they are only important if you want scientific data that you can base a conclusion on (But, I digress--LV and experiments employing the "scientific method" should have ????? how much commonality? ! RF?,! D? I'm sure its overkill but, that point IS important)
(or software port in cases of TCP/IP connections.) The properties of the VISA resource are not carried along the purple wire,
-- yep----
so there is no such thing as a "stale VISA session"
nope Just a Reference who's properties do not agree with the state of the instrument....
The properties of the reference have nothing do to with the state of the instrument. If the instrument is set for 9600 baud, the VISA resource could be set for 2400 baud. One doesn't necessarily equal the other. Of course, if the resource's properties aren't set to match the instrument, you are going to have major communication problems. It is up to the programmer to know what the requirements are of the instrument and set the properties of the resource to match. If in the middle of the program you decide to change instruments, or VISA ports, or settings in the instrument, again it is up to the programmer to set all of that to match (and remember the settings as necessary through functional globals, shift registers, or regular globals .....) In reality, there is no way to determine what the properties are of an instrument at a given point in time unless you have established communication with it. I can easily go to an instrument and change its baud rate or parity using front panel push buttons. It would kill communications. How would LV know that those properties had changed?
Are we getting to a point of agreement with empiracal states yet, (I'm not MAD, just dissapointed)
So if your original port, for instance is Com 3...
++What com trree in my OP?)+++ (I just picked com3 has an example of a VISA resource)
...with a baud rate of 9600. And you change that baud rate to 2400 using the VISA resource along the lower purple wire
How? the purple wire does not affect the "resource just the resource properties!"---
, that baud rate becomes 2400 for Com3. And it stays that way whether you refer to Com3 again using the upper wire or the lower wire.vvvvv
NO RF- the purple wire in has proerties different than the purple wire out of the property node I used to make the change from P.Baudrate=9600 to P.Baudrate=2400. but you can compare those "wires" CLASSES and the result is they are equal---- VERY dangerous if you want to know the dynamic state of the instrument AND comminicate with it dynamically...
No, the purple wire has no properties other than saying "hey we want to be referring to Com1, or Com3, or GPIB5, or ....,)
Really- this isn't rocket science.
instrument state = VISA resource properties.
You can only mix them up by using "Dup resource out" or failing to use a shift register and / or an AE when necessary, to co-ordinate the instrument and VISA property settings
Exactly, up to the programmer to handle all these details and track them. And possibly the user of the program to tell the program when an instrument has changed. If the user was using instrument 1 on Com1, but is now using instrument 2 on a GPIB bus, there is no way for the program to know the user's intentions. The user makes some change in the front panel to signal their intentions, and the programmer handles those details of what resource to use and how to set the resource's properties so that they match the instrument's properties by the way of writing good programming code.
Sorry to rant but...WTF guys?
I'm not taking it as a rant. The only thing that worries me is that we are debating something and then only to find out the details we are debating are actually about two completely different things.
Ravens Fan! I love you!
Exactly- and I Requote (because it is key!) ""If you set the properties of the VISA resource to match the properties of the instrument, you should have communication. If the properties don't match, you probably won't have communication, or at best corrupted communication. ""
so why are you busting mine?
Keep the " properties of the VISA resource" matching the "properties of the instrument" by maintaining the "VISA resource" (and all of its properties and methods) dynamically registered on a chain, (top left cnnector in) (top right connector out), SR, or AE isn't bad.. Refusing to complicate code and add risks with "dup" is a risk
Why not use SR's like in ar chain? of course, recognize it is not an error chain - it is a resource specific chain)(i
.e. "Resource" is not = to (no error). (code bypass on error in is common. NOT Rsource valid =F and / or VISA actions are rare [yes, its a <ctl>-H thing])
Love ya all,
jb
