How can I create a data switch with a PC and 3 ni cards

[PatrickLye]

I am trying to figure out how to create a single pole double throw bi-directional switch for all LAN traffic using a PC, Labview, and 3 NIC cards.It is simple enough to communicate on the network, but this is more like a programmable switch or router than a data consumer creater.

[altenbach]

---

@PatrickLye wrote:

I am trying to figure out how to create a single pole double throw bi-directional switch for all LAN traffic using a PC, Labview, and 3 NIC cards.It is simple enough to communicate on the network, but this is more like a programmable switch or router than a data consumer creater.

---

Your question makes no sense at all, so please clarify.

NI (National instruments) cards are not NIC (network interface) cards.  It typically helps to spell things out and avoid ambiguous acronyms. 

A network switch has nothing to do with characteristics such as single pole, double trow. At what layer should your gadget operate? While it might be possible to create networking hardware using NI FPGA, this is not something that would make a lot of sense ecause there is plenty of off-the-shelf hardware available at a fraction of the cost.

Please explain: What is the purpose of your design? Where should it be used and why? Since you posted in the LabVIEW board, I am assuming you are trying to program this in LabVIEW. Is that correct?

[PatrickLye]

No, single pole double throw is precisely what I'm looking for. What I will have is two master servers, with LabView OPC server, and they can each control industrial I/O. They are "mostly" mirrored systems. The common of the switch goes out to the industrial LAN to control I/O. I am currently using field I/O from Automation Direct. It runs very well, and I've had it in the factory for years. But, I would like to have this hot swapping from one server to the other when conditions warrant the change. My guys now have to manually swap out network cables to switch from one system to the other. I wrote the server interface programs to talk to the field I/O with both servers at the same time. Each server had it's own set of shared variables that could be called in order to read/write identical data. Sadly this worked well on the LabView side, but the OPC server software kept causing intermittent errors in the Field I/O rack, even though I had it set up so that there was a master and a slave server. Only the master server ever wrote data out to the rack, but the OPC link between the field I/O was still too intertwined and I could never get it to keep running for over five or six hours before it errored the field I/O.

Several years ago I did find an OPC server software that would handle what I needed, from what they described, but I had already gone too far down the path with the NI OPC server software.

Now what I'm looking at is to bring one server, the N.O. contact of the LAN switch, or the other server, the N.C. contact of the switch onto the common point of the switch. So in effect I will have one server or the other server talking to the field I/O on the local area network.

Of course it is entirely possible that there is a dependable off the shelf solution to solve this, but I'm not aware of it at this time, which is why I'm trying to solve it with Labview, a PC, and 3 NIC cards. I was looking at using my Cisco SG300-28P switch to do what is needed, but I saw no obvious way to remotely control this on the fly, so like normal I went back home to LabView to see what I could do to solve this issue. A lot of the time I can whip something out with LabView and a bit of hardware faster than I can find something designed for precsisely what I want. Honestly I was amazed at the complexity of the Cisco switch. This is the first that I've used. It has telnet and SSH available. It is nothing like the dumb switches I've been using since the early 90s.

[PatrickLye]

Ok, now I see the problem. I have a typo. It should have been "3 NIC" cards, not "3 ni" cards. That'll teach me to come in on a Saturday...

[altenbach]

Well, if you just want to simulate swapping a cable, a simple relay operated via a digital IO would come to mind.

However, the communication will not magically and instantaneoulsy switch over until things have settled to the new system on all levels (e.g. speed autonegotiation, ARP tables on each device, routing tables, IP adresses, etc.) . You also need to be very careful not to mess with the RF characteristics such that everything remains at cat5 (or higher) standards.

Poorly designed, you'll get crosstalk and reflections or worse. Just look at the crimping guidelines for ethernet cable connectors: You are not allowed to untwist the pairs more than 0.5 inches. Thus you need hardware that remains in spec across the switch.

Overall, it feels clumsy. I still tink that should be solved on the software side. Hotswapping is very common in data centers

[PatrickLye]

I don't disagree on a software solution, but I have no access to modify the NI OPC server, and buying different OPC server licenses wouldn't be a pleasant meeting with the factory owner. I already had a bad enough meeting when I had to tell him that NI informed me the upgrades on this software was not going to be included with my support contract even though the original NI salesman told me that it would be in the presales email correspondence. That was not a good day for me.

I definitely don't want to build a custom hardware switch due to all of the complexity that you mentioned, I'm not that good of a hardware designer, and my company is deadset against anything along those lines. We are trying to replace some old designs that people snuck into the factory over the years. I'm free to design electrical panels, very simple compared to designing a switch like this, but the panels have to use CE (Conformité Européenne)approved or UL (Underwriter Laborotories) listed components. This is what led me back home to LabView and letting the hardware engineers that really know LAN do the hardware for me.

Perhaps I'll run across some ready made hardware that will do the trick next. I've looked, but sometimes fresh eyes gets me there when tired eyes didn't.

[Sam_Sharp]

I read through the posts here a couple of times and I still don't understand why you need to physically switch the ethernet connection. The whole purpose of digital switches was to replace the old fashioned telephone switchboards where an operator would have to physically connect your call! Imagine what it would be like if that was still the case for networking/the Internet!

Is it that you have 3 OPC devices you need to talk to (each one connected to it's own NIC card on the PC...so 3 separate networks), but only one NI OPC server license on a specific IP address?

I'm pretty certain that what you're asking for can be done with a decent configurable switch and it probably wouldn't even require the switch to be controlled from LabVIEW - I'm pretty sure you can route the data from any one of the OPC devices to any of the NIC cards etc. Unfortunately, you'll probably need the expertise of an IT professional for this.

[PatrickLye]

When one server crashes, or there is another problem with the systems involved, the other server has to take control of the Field I/O on the network. The servers can't be hooked up to the network at the same time because of the problem of faulting out the Field I/O with two OPC servers communicating with the Field I/O at the same time. With both servers hooked up the Field I/O will get a fault after running for 5 to 6 hours and stop running.

The LabView to OPC server code runs just fine with both servers hooked up to the network.

The system has to run 24/7 so 5 or 6 hours is not good enough.

I have one IT guy, and he is buried. I may have to bite the bullet and study up on the managed switch that I have available.

I'm amazed that it isn't a simple thing to use LabView to redirect all traffic on some LAN ports. The reasons I was leaning toward this solution is that:

a. It is usually pretty simple to get things done with LabView

b. I am gradually setting up a Master controller bridging my networks that monitors the health of all network systems with heart beat feedback and custom alarm handling. This system  alarms when needed, writes to a a log database when needed, emails when needed, and starts or restarts systems when needed. It would be easy enough to also use it to control the switching of the local area network cables when needed.

The goal is to have a smart system that keeps glass rolling out of the factory unless a mechanical failure occurs.

Sadly, we only have "kind of technical people" on dayshift. Then the swing shift electricians get confused with swapping out cables, and say they can't remember what to do when there are big yellow tags on the cables that tell them what to do. Then on graveyard they don't have electricians. Those guys don't even like getting near computers.

I have written step by step procedures with pictures for the guys to follow if there is ever an issue, and swapping the server cables over is in the procedure. We've had only one issue this year, but people were not happy that they guys had trouble getting everything going again.

Sadly they don't even to have look at the procedures that I've written if they don't want to. That is beyond my control so I'm trying to simplify everything for them so that they don't even have to do this part of the procedure. I'm considering remotely rebooting the operator touch screen PC and powering down/up the Field I/O to get rid of the rest of the procedure.

I would have preferred not using OPC servers to begin with, but this was vetoed in the original Cost Expenditure meetings by the maintenance manager who was running the department back then.