Jump to content

Shift registers with VISA--and when to use


Recommended Posts

In the past few months I have built Labview programs at my university and haven't used shift registers with my VISA wires when taking data in a while loop...the data was collected fine. I was wondering when its necessary to use them for VISA sessions, when/if its OK to sometimes not use them and why. Thanks in advance.

Link to comment

I have made an example for you where you can see, how you get an error without shift-registers ('Iterations' must be set to '0').

For getting an error you have only to replace the two shift-registers in my example with tunnels.

You could maybe get more errors like this. That's why I would use shift-registers everytime.

Greetings Markus

Download File:post-15552-1242892896.vi

lv8.2

Link to comment

QUOTE (for(imstuck) @ May 21 2009, 07:42 AM)

Hi,

It seems from you question you are not sure what shift registers are really doing for you so I though the example below my help to show you.

Within the for loop below, I am injecting an error into the error line. In the top case without the shift register, on each run of the loop the same initial input value of the error line is used so the case runs the "No Error" case.

In the lower case where the shift register is used the output for each run of the loop is then used as the input for the next run of the loop so first time round the loop the "No Error" case is run then on the second time through the "Error" case is run.

Once you understand this principle, the choice of where to use shift register's becomes a lot easier. You have to decide if the data on the wire is going to change during any iteration of the loop, if it is next ask yourself ..do you care about that change and does it or rather should it change what happens in the next iteration of the loop

For example, in a loop repeated talking to an instrument you may pass in an error line and a VISA resource name and in the loop you may be a VISA read.

Normally your VISA resource name will not change in the loop you are reading from the same instrument, so there is no need to use a shift registers here. However the condition of the error line may well change, maybe a read time-out will occur on the first try, you could well want to pass that error back in on the next iteration, so that the VISTA read see there error and does not wait for the timeout condition again.

http://lavag.org/old_files/monthly_05_2009/post-7256-1242893865.png' target="_blank">post-7256-1242893865.png?width=400

Hope this helps

Dannyt

Link to comment

QUOTE (for(imstuck) @ May 21 2009, 02:42 AM)

In the past few months I have built Labview programs at my university and haven't used shift registers with my VISA wires when taking data in a while loop...the data was collected fine. I was wondering when its necessary to use them for VISA sessions, when/if its OK to sometimes not use them and why.

My understanding is that VISA references are by-references and are, as such, not bound to the normal dataflow model per se. I'll wait for someone smarter than me to reply to confirm whether that's true or not before I explain the consequences...

Link to comment

QUOTE (crelf @ May 21 2009, 05:32 PM)

My understanding is that VISA references are by-references and are, as such, not bound to the normal dataflow model per se. I'll wait for someone smarter than me to reply to confirm whether that's true or not before I explain the consequences...

As far as I know, the VISA programming in LV is really error proof since LV6 or LV7. You don't even need the Open or Close reference, that's handled automatically. So you could actually place as many read/write operations and wire an individual constant for each VISA session.

On windows the VISA aliases are stored in the registry, which is updating with a delay of up to 2 min, so there wont be any changes on the handle/reference.

So 'best practices' are a matter of personal taste. The only issue you might run into is when passing the wire through a for loop that migh iterate 0 times.

Felix

Link to comment

QUOTE (Black Pearl @ May 21 2009, 11:59 AM)

As far as I know, the VISA programming in LV is really error proof since LV6 or LV7. You don't even need the Open or Close reference, that's handled automatically. So you could actually place as many read/write operations and wire an individual constant for each VISA session. On windows the VISA aliases are stored in the registry, which is updating with a delay of up to 2 min, so there wont be any changes on the handle/reference.

That's not what I'm talking about - I'm talking about the consequences of branching/debranching a VISA wire (which it, essentially, what you're doing when you use tunnels instead of shift registers). My gut tells me that a VISA wire is by-reference, so I would say either is fine, but I can't be 100% sure.

Link to comment

QUOTE (crelf @ May 21 2009, 07:09 PM)

That's not what I'm talking about - I'm talking about the consequences of branching/debranching a VISA wire (which it, essentially, what you're doing when you use tunnels instead of shift registers). My gut tells me that a VISA wire is by-reference, so I would say either is fine, but I can't be 100% sure.

No, that's exactly the point. You could wire a "COM1" string to each read/write and as long as execution order (by the error wire) stays intact, it's the same. ARSL::COM0 is by default mapping to COM0 (assignment in the registry).

Serial ports are much older than most stuff we deal with including 'Events`, registry and so on... GPIB is older than LV itself...

It is a simple string that will be passed to the OS, and modern windows decodes it via registry keys. And modern LV is smart enough to compile it for max performance.

Just look at the BASIC (disgusting) calls they provide you in so many Instrument manuals.

Felix

Link to comment

QUOTE (Black Pearl @ May 21 2009, 01:25 PM)

No, that's exactly the point. You could wire a "COM1" string to each read/write and as long as execution order (by the error wire) stays intact, it's the same. ARSL::COM0 is by default mapping to COM0 (assignment in the registry).

No, it's not the point at all :) The VISA resrouce is far more than just a wrapped COM assignment string - there are a *lot* of things you can set using property nodes on the VISA wire. What I want to know is if you have a VISA wire, branch it, then set a VISA property on one of the banches, does it affect the other branch? If the answer is yes then it's by-reference, if the answer is no then it's by-value.

Link to comment

QUOTE (Black Pearl @ May 21 2009, 11:59 AM)

So 'best practices' are a matter of personal taste. The only issue you might run into is when passing the wire through a for loop that migh iterate 0 times.

An aside, but this is only true if you were to use tunnels. If you initialize the shift register with the reference, you'll get that same reference out of the loop even if it iterates zero times.

Link to comment

I give up...

The device I connect via RS232 is not changing it's baude rate if I branch any wire. So I expect that splitting a wire and setting the baud rate on one branch would effect the other branch as well. It isn't a OOP clone, because that time, we didn't know what oop is alike.

Felix

Link to comment

QUOTE (Black Pearl @ May 21 2009, 02:50 PM)

The device I connect via RS232 is not changing it's baude rate if I branch any wire. So I expect that splitting a wire and setting the baud rate on one branch would effect the other branch as well. It isn't a OOP clone, because that time, we didn't know what oop is alike.

I found likewise:

Link to comment

QUOTE (Black Pearl @ May 21 2009, 02:50 PM)

QUOTE (asbo @ May 21 2009, 02:59 PM)

I found likewise:

Good stuff - thanks gents. Looks like it's by-reference, so the answer is it doesn't matter whether you use tunnels or shift registers.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.