Accessing A1 Network from an A2 Network?

Let me setup the scenario for you.

My computer is at 10.90.2.242/16. This gives me access to a network, which has a bunch of different PLCs on it, plugged into all their A2 ports. Let us say there is a PLC that is at 10.90.2.4/16.

I have opened my RSLinx, added an Ethernet driver, added this PLC to the driver, right-clicked on the A1 Ethernet port and added the devices that are on the A1 side of the PLC. This includes such things as a PanelView at 192.168.1.30/24 and a Fanuc Robot at 192.168.1.150/24. Please see attached picture for reference.

So, I noticed that I am able to browse for something like the Panelview, and download a new runtime to it from my computer. Somehow the magical wires know to carry it down to the PLC A2 port on my network, switch the network over to the A1 port, and continue down the route to the Panelview. It's able to route across different networks to deliver the information.

I'm sure a long time ago in some Cisco training I learned about packets and how they route, but nowadays, all I know is it's magic. (Dark and evil IT magic, as opposed to my white and holy OT magic.)

My problem comes with something other than say a Panelview which utilizes RSLinx to know the navigation. Say I wanted to access that robot's web browser, or maybe even access it's FTP stuff to pull files. What I currently do now is walk down to the machine, plug into the local network, set my IP to something in the 192.168.1.xxx range and do it that way...but, what if I didn't have to?

Is there a way to sit in my comfy and warm office, and still drill down to the machine level stuff? Is it just building the path up in the web browser a certain way? Something to the affect of "10.90.2.4:A1:192.168.1.150"?

If anyone knows if this is possible, please let me know...it's a long walk.

This is an example of CIP backplane routing (not the same thing as IP routing). Like the CompactLogix, the same principle applies to the ControlLogix backplane when you're using combinations of 1756-ENxT and/or 1756-558x processors.

The general idea is:

• CIP identity requests from your PC's copy of RSLinx are embedded into IP packets and sent to an EtherNet/IP host.
• The host adapter unpacks the CIP request.
• The "pure" CIP request is transmitted along the backplane to member nodes.
• Responses from CIP nodes make their way back to the host adapter, are re-packaged into IP, transmitted, possibly routed, then arrive at your machine.
• RSLinx builds and displays the trees with member node identities.

Firmware updates, program downloads, and so on performed this way are other CIP services carried out through TCP/IP.