Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

One ethernet address for all?

Solved!
Go to solution

We have a big system with several bus, talking to many units and racks.  We still use GPIB on some older units.  We now have newer versions of the units that have ethernet and we were considering switching and dropping gpib.

 

The issue is we have to calibrate our units every year and so they get swapped often.  With gpib we set the address in Visa and it talks to all the (same type) units we have, new or old.  No changing the program just swap and go.   With an ethernet Inst:: once I set coms up in Max it will only talk to that one unit and swapping is another trip through Max, setting it in the program and saving it as default... 

 

Is there a way to have a universal tcip connection to a single type of instrument?  In my case it is a waveform generator model that has been around 40 years with updates like ether port.

 

If the answer is no, how can I get all the instruments to show in the Visa address pull down and or Max, not just the units that are hooked up today?

0 Kudos
Message 1 of 12
(1,147 Views)

As long as the IP of your instrument does not change, I don't think the VISA resource name will change.

 

Could you please post examples of what you observed and what your expectation was?

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 12
(1,128 Views)

It SOUNDS like you're getting new IP addresses each time you connect a new machine, right?

 

If so, you'll need to either configure the equipment to have a static IP (instead of dynamic) and manually enter the IP address, or set your router to recognize a given mac address and to always give it the same IP.

 

Alternatively, you could use MAX Aliases and just give them all the same alias. I believe this is under My System -> Software -> NI-VISA. I'm not sure what settings you're configuring when you set it up in MAX, but you'll have to apply those settings within your software (so you can avoid doing it in MAX).

 

Apologies if that last bit isn't clear, I never use MAX for my serial setups and just do it within LabVIEW so it's not super clear to me how to do it.

0 Kudos
Message 3 of 12
(1,122 Views)

Here is an example of our situation.

We have 3 systems that use two waveform generators in each.  With spares 8 units that are the same exact type.  Every unit has to be swapped every year for calibration.  With GPIB all we had to worry about is setting the address to either 18 or 19 and any unit could be swapped into any one of the three systems.

 

We are pushing to get off GPIB and run everything on LAN.  I could use static IP but it would have to still be different for every unit because all systems are on the same network.

 

0 Kudos
Message 4 of 12
(1,068 Views)

Ah, that makes more sense.

 

I'm pretty sure this is what Aliases are for. Basically, you create an Alias called "GeneratorA" that points to "192.168.1.1" or "INSTR::(whatever)", and another called "GeneratorB" that does the same thing. In your code, you tell VISA to use "GeneratorA", not "INSTR::xyz" and VISA takes care of the mapping.

 

When you need to switch instruments, open up MAX and edit the VISA alias (Tools -> NI VISA -> VISA Options) to point to the new IP address.

 

(Caveat: I haven't messed with this much, so you might have to play around with it to figure it out. There are a couple alternate alias locations as well, including project-based or executable-based, so you have a few options.)

 

Alternate idea: Just use a .ini file to read in the IP address at the start of your program's execution. When you switch instruments, change that file. You can even do it inside your program; just have a "Settings" menu or something. I've done this frequently and it works great.

0 Kudos
Message 5 of 12
(1,064 Views)

Thanks for the help.

I am trying to keep my program the same in all locations and my operators or I from having to use MAX for it all.  It would not be good to hand them that key.

 

If I do some kind of find on the net it will find all 6 units and will be no way to tell which is hooked to which system.

 

I am talking to IT about sub sub net for each system so a find will only find the ones on that system.  

0 Kudos
Message 6 of 12
(1,053 Views)

So wait, then your current system isn't working for you? You said currently you update the GPIB address in MAX. My suggestion was to update an alias in MAX. It would take about the same amount of time and you'd only need to do it when you switched units.

 

I also feel like setting a static IP on the units would be simpler than IT making specific subnets for each test station, but I know IT guys can have some oddball rules sometimes that can make things tricky.

0 Kudos
Message 7 of 12
(1,033 Views)

No, currently you only have to set the units GPIB address once when new and then the program does not care you changed units out.  No Max involved. 

 

The entire point is to not have the operator have to use MAX or have to change the program after a swap.  I am retiring and can't do it for them, 15 times a year.

 

We are looking at putting all the units of a system on a second ethernet card/port.  That way the same static IP can be used and the units easily switched between systems without LAN interferences.

 

Unless someone comes up with a better idea.

0 Kudos
Message 8 of 12
(1,029 Views)

Ahhh, I see. I thought you changed their address via MAX, and that you did it each time you swapped systems. I get it now. Sorry about that.

 

I think I understand your solution now- just add the ethernet stuff to a local network via second LAN card. That seems reasonable but I'm not an IT guy.

 

I suppose that if you can't mod the program, can't interact with MAX, and can't change local config (.ini) files then you'll have to separate the systems in some way like you're suggesting.

 

It would be simple to implement a text file that loads an IP address, but that's something else that someone needs to remember to do and is something else that could get deleted accidentally. Your subnet solution (if your network/IT guys allow it) sounds like a reasonable one to me.

 

There *may* be a way to do this with traceroutes and a dedicated router for each system. If you know all of the possible IP addresses, you could traceroute each of them and see which router shows up in the middle. Then when you switch out a system, you know you have to plug the new one into a specific router. Again, you'll have to work with your IT to do that, and it might be simpler to do the subnet thing with a second card. I believe switches don't show up in traceroutes, so it would need to be a router. Basically forming the subnet with a router instead of a second card in the computer (or a USB3-connected card). One benefit to that would be that (I think) your instruments could still all be accessible from the main network so you can see them from outside of your testing area. If it's going through a PC I don't think you could get to the instruments from, say, your development computer.

 

(And to reiterate... I'm no IT guy, so all that may not make sense 😊)

0 Kudos
Message 9 of 12
(1,024 Views)

I feel @BertMcMahan's suggestion to add an additional ethernet card to the PC and connect instruments to that ethernet port will be practically the easiest option.

 

This way, the IP of each instrument can be hardcoded since it is in a different Subnet and not exposed to the external network.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 10 of 12
(1,017 Views)