Source: http://www.google.com/patents/US7861019?dq=6175559
Timestamp: 2014-07-25 03:45:41
Document Index: 279051514

Matched Legal Cases: ['art 108', 'art 108', 'art 130', 'art 108', 'art 182', 'art 108', 'art 220']

Patent US7861019 - System and method for implementing and/or operating network interface ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsA computer system, and related components including network interface devices, as well as methods for implementing and/or operating network interface devices to achieve network-based communications, are disclosed. In at least one embodiment, the computer system includes a network interface device, and...http://www.google.com/patents/US7861019?utm_source=gb-gplus-sharePatent US7861019 - System and method for implementing and/or operating network interface devices to achieve network-based communicationsAdvanced Patent SearchPublication numberUS7861019 B2Publication typeGrantApplication numberUS 11/744,370Publication dateDec 28, 2010Filing dateMay 4, 2007Priority dateMay 4, 2007Also published asUS20080276010Publication number11744370, 744370, US 7861019 B2, US 7861019B2, US-B2-7861019, US7861019 B2, US7861019B2InventorsMichael A. Fuchs, David A. SnyderOriginal AssigneeRockwell Automation Technologies, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (16), Non-Patent Citations (9), Classifications (20), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetSystem and method for implementing and/or operating network interface devices to achieve network-based communicationsUS 7861019 B2Abstract A computer system, and related components including network interface devices, as well as methods for implementing and/or operating network interface devices to achieve network-based communications, are disclosed. In at least one embodiment, the computer system includes a network interface device, and a bus driver in communication with the network interface device. The bus driver has access to a plurality of driver programs, and the bus driver is capable of causing an installation of one such driver program on the network interface device. Also, in at least some embodiments, the bus driver facilitates communications between multiple network interface devices and an operating system of the computer system, and/or between the network interface devices and user mode applications implementing graphical user interfaces. Further, in at least some embodiments, the bus driver governs operation of the network interface devices, for example, in relation to power management and/or interrupt handling.
CROSS-REFERENCE TO RELATED APPLICATIONS The present application claims the benefit of, and hereby incorporates by reference, the other patent application having the same title as the present application and filed on even date herewith.
FIELD OF THE INVENTION The present invention relates to computer systems that are in communication with one or more other devices by way of one or more networks, and more particularly relates to components of such computer systems such as network interface devices (and related software components) and correspondent methods of operation by which such computer systems are configured for, and govern, such network-based communications between the computer systems and other devices.
BACKGROUND OF THE INVENTION Most modern computer systems communicate with hardware devices such as peripherals and processing units such as programmable logic controllers (PLCs), which typically are external to the computer systems and possibly in remote locations. The computer systems in particular include network interface devices, by which the computer systems are coupled to computer networks or buses that in turn are coupled to the hardware devices. A variety of networks are possible including, for example, Peripheral Component Interconnect (PCI) buses or Universal Serial Buses (USBs), and the network interface devices can take the form of PCI cards or other forms.
In implementing such network interface devices, many modern computer systems use software routines, called �device drivers�, which are loaded onto the operating systems of the computer systems to achieve and facilitate communications over the networks. Typically, for each respective network coupled to a computer system, a respective monolithic device driver is loaded onto the appropriate network interface device at boot time, often with information about the hardware devices that are connected to (or intended to be connected to) that network. The loading of the device drivers by the operating system at boot time includes the loading of protocol information specifying functions that each of those device drivers can perform.
Further, as operating systems evolve in particular, device drivers designed for implementation on network interface devices in relation to particular operating systems may no longer be compatible with newer operating systems or versions of operating systems. For example, while earlier versions of Microsoft Windows operating systems available from the Microsoft Corporation of Redmond, Wash. (e.g., Microsoft Windows XP) are capable of operating with device drivers that do not support �Plug and Play� (PnP) operation, the newly-released Microsoft Windows Vista operating system only is capable of operation with device drivers that support PnP operation.
BRIEF SUMMARY OF THE INVENTION The present inventors have recognized that an improved computer system and/or method of operating a computer system for achieving network-based communications can be achieved, in at least some embodiments, by employing an overall or managerial bus driver that governs or manages the implementation and operation of multiple particular device driver routines in relation to multiple network interface devices of the computer system that in turn are coupled to other hardware devices by way of multiple networks. In such embodiments, the bus driver serves as an interface between the underlying operating system of the overall computer system and the network interface devices and their particular device driver routines, such that the operating system is in contact with the bus driver rather than the particular device driver routines directly. The bus driver also serves as an interface with outside users attempting to access the network interface devices (and the networks and hardware devices to which they are coupled).
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram showing in schematic form exemplary components of a computer system with a bus driver, along with hardware devices in communication with that computer system, in accordance with one embodiment of the present invention;
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring to FIG. 1, components of an exemplary computer system 4, which includes a bus driver architecture 2 and is in communication with multiple hardware devices 6, are shown in schematic form. More particularly, in the present embodiment, the computer system 4 includes a network interface 14, multiple industrial (or possibly other types of) networks 16 and additional hardware including one or more processing devices and/or one or more memory devices (not shown) that support two operating modes, a kernel mode 10 and a user mode 12.
Further as shown, each of the PKTX(D) cards 18 and 20 has one or more sections or �channels�, each of which respectively forms a distinct operating platform of the card. The number of channels in each of the PKTX(D) cards 18 and 20 can vary depending upon the embodiment and also can vary depending upon the specific type of card being utilized. For example, in the present embodiment, the PKTXD card 18 is divided into two channels, a first channel 22 and a second channel 24, while the PKTX card 20 merely has a single channel 34. In other embodiments, the number of channels in any given card can be other than one or two channels.
Each of the channels 22, 24 and 34 of the PKTX(D) cards 18, 20 in the present embodiment includes a respective block of memory and a respective microprocessor (e.g., a 8-bit Z80 processor) to carry out various operations (e.g., operations requested by the user mode 12 as discussed in more detail below). The channels 22, 24 and 34 in particular become capable of conducting communications with respect to the networks 16 when software routines referred to as �drivers� are loaded onto the memory of the respective channel from the kernel mode 10 of the computer system 4 (particularly by a bus driver portion of the kernel mode, as discussed further below). Although channels can vary widely depending upon the embodiment in terms of their configurations and functionality, in the present example, the first and second channels 22 and 24 respectively of the PKTXD card 18 are of different types (e.g., type �A� versus type �B�, respectively) and consequently are configured to perform different functions, while the first channel 22 of the PKTXD card 18 and the channel 34 of the PKTX card 20 are of the same type (e.g., type �A�) and are configured to perform the same or similar functions.
Each of the channels 22, 24 and 34 is capable of connecting to one or more of the multiple industrial networks 14 via contacts or �communication ports�. The number of ports that each channel 22, 24 and 34 can connect to varies with the type of the PKTX(D) card in which the respective channel is implemented. For example, the first channel 22 and the second channel 24 of the PKTX(D) card 18 are capable of connecting to a first port 26 and a second port 28, respectively. In this regard, the PKTXD card 18 is a �dual port� card capable of connecting simultaneously to, and communicating simultaneously via, both of the first and the second ports 26, 28. Further as shown, in the present embodiment, the first port 26 is additionally subdivided into two ports, a port 30 and a port 32, for connecting the first channel 22 to two different types of the industrial networks 16. As another example, the channel 34 of the PKTX card 20 is a �single port� card capable of connecting to either a first port 36 or a second port 38 for communication with either of two different types of the industrial networks, albeit communication via only one port and one industrial network is possible at any given time.
As for the second, third and fourth sections 58, 60, and 62, these respectively are capable of obtaining and storing information about the first and second channels 22 and 24 of the PKTXD card 18 and the channel 34 of the PKTX card 20, respectively (the sections can be considered to be data objects used by the first section 56). The stored information concerning the cards 18, 20 and channels 22, 24, 34 typically is obtained from the cards/channels during booting of the computer system 4 or whenever a new card is installed onto the system (as discussed further below). As mentioned above, the stored information includes a PDO identifier that uniquely identifies a given channel of a given card, and a JID identifier that identifies the particular card (from this information, a given channel can be labeled �A� or �B� as shown). In the present example, information (e.g., PDO and JID information) regarding the respective channels 22, 24, 34 of the PKTX(D) cards 18, 20 is stored in the second, third and fourth sections 58, 60 and 62, respectively. With respect to the fifth section 64 of the bus driver 52, this section is intended to indicate that the bus driver 52 is capable of including one or more additional sections in which are stored information about any arbitrary number of additional channels/cards (or other devices) that can be included as part of the network interface 14.
The user mode applications 86 can take a variety of forms depending upon the embodiment. In the present embodiment, the applications 86 include a RSLinx� Classic application 90 (e.g., the RSLinx� Classic 2.51), and a RSLinx� Enterprise application 92, as are available from Rockwell Automation, Inc., as well as one or more test application(s) 94. Both of the RSLinx� Classic application 90 and the RSLinx� Enterprise application 92 are software programs that provide user-friendly graphical interfaces to allow navigation of the multiple industrial networks 16 and to allow accessing of those networks (the application 92 being somewhat more modular than the application 90). The test application(s) 94 include routines that allow for the detection and fixing of faults in the computer system 4 or devices connected to it (e.g. the hardware devices 6), for example, faults on the bus driver 52, the devices of the network interface 14, the processor operation, etc.
Further as shown, the user mode applications 86 communicate with the bus driver 52 by way of interfaces 88, which also from part of the user mode 12. For example, the RSLinx� Classic application 90 connects to a PKTX.DLL application interface service 96 to convert the signals (e.g., requests) from the application into a format appropriate for the bus driver 52 to understand, where the converted signals are then forwarded to the bus driver 52 by way of the interface 84 as indicated by a first arrow 102. Also for example, the other applications in the user mode 12, namely, the RSLinx� Enterprise application 92 and the test application(s) 94, each connect to a PKTXNG. DLL application interface service 98 via links 106 and an interface 100, such that the signals (e.g., requests) from those applications are converted into the format appropriate for the bus driver 52 to understand. These converted signals also are then sent to the bus driver 52 by way of the interface 84 as indicated by a second arrow 104. The interface 100 is a COM (component object model) interface, which allows certain of the applications 86 (e.g., the applications 92 and 94) a documented way of accessing the bus driver 52 from the user mode 12.
Although FIG. 1 in particular illustrates the provision of signals from the applications 90, 92 and 94 to the bus driver 52, it will be understood that signals can also be provided in the reverse direction from the bus driver to one or more of those applications. When such signals are provided by the bus driver 52, they are directed to the appropriate interface service 96, 98 by way of the interface 84. Thus, a signal intended for the RSLinx� Classic application 90 is directed by the interface 84 from the bus driver 52 to the PKTX.DLL application interface service 96. In the case of signals intended for either the RSLinx� Enterprise application 92 or the test application(s) 94, upon being provided to the PKTXNG.DLL application interface service 98 and converted to the format appropriate for receipt by the appropriate application 92, 94, those signals are then further directed to the appropriate application 92, 94 by way of the interface 100.
Turning to FIG. 2, a flow chart 108 shows exemplary steps of operation of the computer system 4 related to loading of the bus driver 52 and the detection and implementation (or �enumeration�) of devices of the network interface 14 such as the PKTX(D) cards 18, 20 of FIG. 1, in accordance with at least one embodiment of the present invention. As shown, the flow chart 108 includes several process steps that are performed to load the bus driver 52 of FIG. 1 and assign resources of the PKTX(D) cards 18 and 20 to the bus driver 52. Information regarding the resources of each PKTX(D) card 18, 20 and its respective channel(s) 22, 24, 34 is located on the channels of each respective card. More particularly, this information typically includes both identification information that uniquely identifies the card and channel, as well as operational information indicative of the function(s) that each given card and channel is capable of performing and/or potentially the manner of performing those functions or rules/protocols that need to be followed in interacting with the card and channel to perform such functions.
After a user is successfully logged into a desired one of the user mode applications 86 (e.g., the RSLinx� Classic application 90), the process proceeds to a step 136. In many operational circumstances, a user is aware of a particular one of the hardware devices 6 and/or a particular one of the networks 16 with which communication is possibly desired, and yet the user is uncertain of whether a network interface device appropriate for allowing such communications is presently implemented on the computer system 4 and/or available for communications. To obtain such information, at the step 136 the user causes the application 90 to send a request for information concerning a desired one of the devices of the network interface 14 that the user believes to be appropriate for handling desired communications over a desired network and/or with a desired one of the hardware devices 6. For example, supposing that the user wishes to conduct communications over the DH+ network 40, the user can send a request for information as to whether an appropriate channel (e.g., the channel 24) of an appropriate PKTXD card (e.g., the card 18) is present and available for communications.
As discussed with respect to FIG. 1, requests from the user mode applications 86 are not provided directly to the bus driver 52. Rather, as indicated at a step 138 of the flow chart 130, such requests from the user mode applications 86 instead are first converted into a format appropriate for receipt by the bus driver 52 by way of one or more of the application interface services 96, 98 and one or more of the interfaces 84, 100. Assuming again, for example, that the request is provided from the RSLinx� Classic application 90, the PKTX.DLL application interface service 96 performs a conversion operation by which the request is transformed into an Input/Output Request packet (IRP), and the output of that process in turn is provided to the bus driver 52 by way of the interface 84 within the kernel mode 10, which can be understood as being provided by way of the operating system of the computer system 4 (but not the bus driver 52 itself). Alternatively, assuming that the request is provided from either the RSLinx� Enterprise application 92 or one of the test application(s) 84, such requests are first handled by the interface 100, then converted by the PXTXNG.DLL application interface service 98 into IRPs, and the further processed by the interface 84 before being provided to the bus driver 52. Given this process, the bus driver 52 need not be (and is not) cognizant of the particular user applications 86 from which the requests are originating.
Next, the process advances to a step 140, at which control transfers to the bus driver 52. As a result of the step 132 (e.g., the process represented by the flow chart 108 of FIG. 2), the bus driver 52 acts effectively as a central database maintaining information including the current status of the PKTX(D) cards 18 and 20 and their respective channels 22, 24, 34 (and/or possibly other network interface devices) installed in the computer system 4. More particularly, not only does the bus driver 52 contain JID and PDO information identifying each available card and channel but also the bus driver includes a respective status flag regarding each of the channels 22, 24, 34 of each of the PKTX(D) cards 18, 20 indicating the availability or unavailability of each respective channel. Therefore, in the step 140, the bus driver 52 responds to the request received from the RSLinx� Classic application 90 by searching its database to determine the current status of the requested channel 22, 24 or 34 of the requested PKTX(D) card 18 or 20. The section of the bus driver 52 where the channel status flag information is stored can be accessed by way of the JID and the PDO of the PKTX(D) card, with the JID uniquely identifying the PKTX(D) card and the PDO uniquely identifying the channel number, e.g., channel A or B. For example, the bus driver 52 can search the status of the first channel 22 of the PKTXD card 18 by looking at the PDO with a JID=1 and the corresponding channel number, and then accessing the status flag in the second section 78 of the bus driver 52 in FIG. 1.
Next, at a step 142, the bus driver 52 makes a determination about the availability of the requested PKTX(D) card and channel (e.g., the card 18 and the channel 22) based upon the channel status flag information that is obtained during the step 140. If at the step 142, the status flag indicates availability of the requested card/channel, then the process advances to a step 144 that is explained in more detail below. However, if at the step 142 it is found that the requested card/channel is unavailable, then the process moves to a step 146, at which a message in the form of an IOCTL function call is sent by the bus driver 52 back toward the originating user mode application indicating unavailability of the requested card/channel. For example, if the original request provided in the step 136 concerned the first channel 22 of the PKTXD card 18 and was provided by the RSLinx� Classic application 90, and if the status flag information in the bus driver 52 indicates that the first channel 22 is unavailable, then the bus driver will send a message back toward the application 90 indicating this to be the case.
Further at a step 174, the message sent at the step 146 is converted appropriately for receipt by the intended recipient application. For example, if the intended recipient application again is the RSLinx� Classic application 90, then the step 174 involves conversion/processing of the bus driver signal by way of each of the interface 84 and the PKTX.DLL application interface service 96. The step 174 thus is effectively the inverse of the step 138. Upon completion of the step 174, at a step 176, the converted signal resulting from the step 174 is provided to the originating user mode application so as to provide an indication to that application of the unavailability of the requested card/channel (or other network interface device), again for example, the unavailability of the channel 22 of the card 18. The process then advances to a step 178 where the user can request availability information about another channel of one the PKTX(D) cards 18, 20 (or other network interface device(s)). If the user desires to obtain such other availability information, the process then returns to the step 136 and proceeds from there as discussed above. It; however, the user does not desire any further information, the process is ended at a step 180.
If instead, at the step 142, the requested PKTX(D) card and channel are found to be available, then the process advances to a step 144 at which the bus driver 52 sends a message by way of an IOCTL call back to the interface service indicating availability of the requested PKTX(D) card. For example, again assuming that the original request in the step 136 concerned the channel 22 of the PKTXD card 18, at the step 144 the bus driver 52 invokes an IOCTL call that is to be provided to the PKTX.DLL application interface service 96 associated with the RSLinx� Classic application 90 that generated the original request. Next, at a step 148, the IOCTL call generated in the step 144 is processed/converted by the appropriate one of the application interface services 96, 98 as well as one or more of the interface(s) 84, 100 so that the call can be received by the one of the user mode applications 86 that generated the original request in the step 136. Assuming that the original request was provided by the RSLinx� Classic application 90, for example, the IOCTL call generated in the step 144 is provided by way of the interface 84 and directed to the PKTX.DLL application interface service 96, such that the message is converted back into the format that the application 90 understands.
Subsequently, it is at a step 150 that the application interface service receiving the IOCTL call in the step 148 informs the user via the user application of the availability of the requested channel and PKTX(D) card. Thus, continuing the above example in which the RSLinx� Classic application 90 originally generated a request in the step 136 concerning the channel 22 of the PKTXD card 18, at the step 150 that application (and thus any user employing that application) receives a message from the PKTX.DLL application interface service 96 indicating the availability of that card/channel. Having determined the availability of the requested card/channel (or other network interface device), the user can now request one of the drivers 54 to be installed in relation to that requested card/channel. Thus, at a step 152, if the user desires establishing communication with the PKTX(D) card whose availability was determine in the step 142, the process goes to a step 154 explained in more detail below.
However, if no communication is desired at the step 152, the process instead returns to the step 178. As discussed above, the step 178 can also be reached from the step 176 if a requested card/channel is found to be unavailable. Thus, the step 178 can be attained either if a requested card/channel is found to be unavailable or if a user does not wish to establish communications with a card/channel after finding that the card/channel is available. In either case, as discussed above, at the step 178 it is determined whether the user desires information about other PKTX(D) cards or channels (or other network interface devices) in the computer system 4. If no information about any other card/channel, then the process ends by going to the step 180. However if information about another card/channel is desired, then the process returns to the step 136. For example, even though the first channel 22 of the PKTXD card 18 is unavailable, the second channel 24 of the same card or the channel 34 of the PKTX card 20 may be available for communication. In proceeding again at the step 136, the user can utilize the same user mode application as was employed earlier (e.g., the RSLinx� Classic application 90) or switch to another application (e.g., the RSLinx� Enterprise application 92).
With respect to the step 154, it is attained if the user desires installation of one of the drivers 54 as determined at the step 152. If such is the case, the user enters desired driver information into the user mode application onto which the user logged at the step 134, and that application in turn issues an IOCTL call to the associated application interface service, where the IOCTL call is configured to request addition of one of the drivers 54 and specifying the resources to be used. For example, assuming that a user is interacting with the computer system 4 via the RSLinx� Classic application 90, assuming that the user is interested in utilizing the first channel 22 of the PKTXD card 18, and assuming that the user wishes for the DH-485 protocol driver 66 to be installed in relation to that card/channel, in response to an appropriate user input the application 90 can issue a driver installation request to the PKTX.DLL application interface service 96 that is intended to precipitate the desired protocol driver installation. Upon the issuance of such a request, at a step 156 the interface service (e.g., the interface service 96) converts the request to the format appropriate for the bus driver 52 to understand similar to the step 138 and the request as reformatted is then directed to the bus driver 52 by way of the interface 84.
Either following the installation of a driver onto a card/channel at the step 160, or following a determination at the step 158 that a requested driver already is installed onto that card/channel, the step 162 is reached. At that step, the bus driver 52 sends a message indicating whether the driver installation was successful back to the user mode application from which the original driver installation request originated (and thus back to the user) at the step 154. Consistent with the above descriptions of other communications between the bus driver 52 and the user mode applications 86, the sending of this message at the step 162 involves first providing the message to the interface/interface service from which the bus driver earlier received the driver installation request in the step 156, so that the message is reformatted for receipt by the user mode application from which the driver installation request was originally received. Following that reformatting operation, the reformatted message is then sent to and received by the appropriate user mode application 86. For example, assuming that the driver installation request was originally received from the RSLinx� Classic application 90 via the PKTX.DLL application interface service 96 as a result of the steps 154 and 156, the confirmation message provided in the step 162 would be provided back to the application interface service 96 via the interface 84, reformatted, and then received by the application 90 and thus by the user. Typically, the message sent by the bus driver 52 in the step 162 can be sent as a function call.
Next at a step 164, a determination is made by the user (or potentially automatically, for example, by way of one of the user mode applications 86) regarding whether an action on the part of one or more of the cards/channels (or other network interface device(s)) is desired. Such a determination can be made when the user inputs an appropriate instruction or other information into one of the user mode applications 86. For example, a user can input an instruction to one of the user mode applications (e.g., the RSLinx� Classic application 90) that is intended to cause data to be transferred to one of the hardware devices 6 (e.g., the SLC 48) by way of the channel 22 of the PKTXD card 18 with respect to which the driver installation steps 154-162 were just performed. Although for purposes of the present example the determination made in the step 164 relates to whether the user desires an action to be taken by the card/channel that was the subject of the driver installation steps 154-162 that were previously performed, it should be understood that in other circumstances determinations can also be made with respect to other cards/channels/network interface devices and/or can be made at times other than immediately following the performance of such driver installation steps.
As further illustrated, if upon the performing of the step 164 it is determined that no communication is desired, then the process remains at the step 164 (or alternatively the process ends). However, if communication is desired, then the process advances to a step 166, in which the user mode application (e.g., the RSLinx� Classic application 90) provides an appropriate command and possibly related information to the associated application interface service (e.g., the PKTX.DLL application interface service 96). Typically, the command will include not only information regarding an action that is to be taken, but also identify the card/channel (or other network interface device) that should take the action. Next, at a step 168, the command and related information received from the user mode application are processed by that application interface service to be of a format appropriate for receipt by the bus driver 52, and the reformatted command and related information are then directed by way of one of more interfaces (e.g., the interface 84) to the bus driver 52.
Turning to FIG. 4, a flow chart 182 is provided showing exemplary steps of a process by which the bus driver 52 manages the power usage of one of the PKTX(D) cards 18, 20 (or possibly other network interface devices), typically in order to minimize or reduce overall power consumption. As shown, this process starts at a step 184, which involves the loading of the bus driver 52 in the computer system 4 and the enumerating and powering on of all of the PKTX(D) cards (or other network interface devices) that are present in the computer system, and which corresponds to the steps of the flow chart 108 discussed earlier with respect to FIG. 2. Next, at a step 186, it is determined whether there has been a request pertaining to the powering off of a particular one of the PKTX(D) cards, for example, the PKTXD card 18. Such requests can come from either a user or alternatively the operating system/kernel mode, upon determining that a powering off condition has been met or for some other reason (e.g., to conserve power or avoid a circumstance in which excessive power depletion has occurred). The user can request the powering off of a PKTX(D) card in various manners including, for example, by entering a request to one of the user mode applications 86 that the protocol driver loaded on that card be unloaded. As discussed above with respect to FIG. 3, user requests entered into the user mode applications 86 (e.g., RSLinx� Classic application 90) are in turn provided by those applications to their respective application interface services (e.g., the PKTX.DLL application interface service 96), which convert the requests to IRPs in formats appropriate for the bus driver 52. The IRPs are then directed by way of IOCTL calls to the bus driver 52 for handling.
Given these assumptions, the process represented by the flow chart 220 begins at a step 264, during which an interrupt is fired by one of the channels, for example, by the channel 22 on which is implemented the DH-485 protocol driver 66, which in this example can be referred to as the �first channel�. Next, at a step 266, the operating system of the computer system 4 calls the ISR 212 of the bus driver instance 206. Upon completion of the step 266, the process advances to a step 268 in which the first channel's ISR 216 is called via a function pointer (if present). This operation can be understood as being performed by the ISR 212 of the bus driver instance 206, as indicated by a box 222. Upon completion of the step 268, the first channel's ISR 216 takes control of the process. At a step 270, the ISR 216 in particular determines whether an interrupt flag has been set. If it is determined that an interrupt flag has been set, then at a step 272 the interrupt flag is cleared by the ISR 216, the interrupt is handled by that ISR, and a �true� value is returned/output by the ISR. Otherwise, a step 274 is performed by the ISR 216 subsequent to the step 270, and a �false� value is returned/output.
Turning to FIG. 7, an exemplary screenshot 232 of one of the user mode applications 86 in accordance with one embodiment of the invention is shown. The screenshot 232 in particular is one of the first screens that comes up after a user logs into either the aforementioned RSLinx� Classic application 90 or the RSLinx� Enterprise application 92, and is intended to provide a user-friendly interface allowing a user to easily and conveniently obtain information regarding, and to configure for communication, the PKTX(D) cards 18 and 20 (or other network interface devices). As shown, the screenshot 232 includes a first dialog box 234 that lists the PKTX(D) cards 18, 20 that are installed in the computer system 4, that provides information regarding the status of those cards, and that allows a user to select the available PKTX(D) cards for configuration (one at a time). Additionally, the screenshot 232 also includes a second dialog box 236 that appears when a user selects one of the PKTX(D) cards 18, 20 listed in the dialog box 234 and further selects one of the channels of the selected card. As described further below, the dialog box 236 permits the user to configure that selected card/channel for communication.
As already mentioned, the drop-down box 238 lists all of the PKTX(D) cards 18 and 20 that are currently installed in the computer system 4, and thus allows a user to appreciate the full assortment of network interface devices that are present in the computer system. The listed card information identifies the cards by way of their type and JID value. For example, given the computer system 4 of FIG. 1 including the two PKTX(D) cards 18 and 20, the drop-down box 238 lists the PKTXD card 18 as having a JID of 1 and the PKTX card 20 as having a JID of 2. One of the two PKTX(D) cards 18 and 20 can be selected from the drop down box 238 at a given time, for example, by highlighting and clicking on the entry by way of a mouse. Once one of the PKTX(D) cards 18, 20 has been selected, the schematic diagram of that card is shown in the box 240 and also the additional information concerning the channels of that card is displayed below that box. In the present example, the PKTX(D) card 18 has been selected from the drop-down dialog box 234, and so the schematic of that card including the boxes 242, 244 representing the two channels 22, 24 of that card is shown in the box 240. In addition to showing the channels 22, 24, the boxes 242, 244 also indicate an availability status of the respective channels. In the present example, thus, the box 242 indicates that the first channel 22 is currently off-line or �free� while the box 244 indicates that the second channel 24 is �on-line� or occupied.
As shown in the exemplary boxes 246, 248 of FIG. 7, the detailed information regarding the channel(s) of a selected card or other network interface device can encompass several types of information. The second and third boxes 246 and 248 respectively are populated with the same fields including for example, �Network� specifying the industrial network for which the channel has been configured for communication (and/or with respect to which the channel is currently connected or communicating), �Station Name� representing the name of the channel as it would appear on the network 16, �Station Number� indicating the number of the channel as it would appear on the network, �DH+ Speed� indicating the speed of the network, �Controlling Application� specifying the user mode application through which all requests are made and the �Status��whether online or free. In the present example, as already discussed above, the channel 22 is free/off-line and so the �Status� indicated within the box 246 is �offline�, while the channel 24 is �on-line� as indicated within the box 248.
Also in the present example, the �Network� associated with the first channel 22 is currently unspecified or �N/A� as indicated by the box 246, while the �Network� associated with the channels 24 is the DH+ network 40 as indicated by the box 248. Further for example, the box 248 representing the second channel 24 is populated with the name and speed of the network (DH+, 230.4K), the name and number of the station (Ucontrol, 5), and the controlling user mode application (the RSLinx� Classic application 90). In contrast, the fields within the box 246 representing the first channel 22 remains largely unpopulated (e.g., indicate �N/A�) since as described in further detail below that channel is only in the process of being configured (or is unused).
As shown in FIG. 7, the second dialog box 236 in particular allows the user to select one of the industrial networks 16 for connection to the first channel 22 of the PKTXD card 18. The user can select one of the DH+, DH-485 or RIO industrial networks from a drop-down box 258 and set the properties of the selected network in a box 256. Only one network can be selected at any point of time. In the present example, a �Network� field of the box 256 shows the name of the network that has been selected from the second drop-down box 258, namely, the DH+ network 66. In addition to the �Network� field, the box 256 includes �Station Name�, �Station Number� and �Speed� fields, which respectively show the name of the hardware device 6, the number of that hardware device, and the speed of the network. Each of the fields in the box 256 is initially populated with default values that can be changed by the user. By setting properties in the second dialog box 236, the user will automatically cause an appropriate one of the drivers 54 to be loaded onto the subject channel. For example, in the present embodiment, the user by virtue of selecting the DH+ network will cause the DH+ protocol driver 68 to be loaded onto the channel 22 of the card 18.
After specifying information in the boxes 256, 258, the user can confirm/implement the newly-specified configuration by clicking on an ok button 260 within the dialog box 236. If the user does not wish to confirm the new configuration, a cancel button 262 can alternatively be pressed. Upon the pressing of either the ok button 260 or the cancel button 262, the second dialog box 236 disappears and control is returned to the first dialog box 234. On returning back to the first dialog box 234, the fields of the box 246 corresponding to the configured channel 22 are populated by the properties set by the user in the second dialog box 236 assuming that the user pressed the ok button 260 (the values will be unchanged if the cancel button 262 was pressed). For example, the box 246 will now be changed to show the �Status� of the channel 22 as being �online�. Also, other fields of the box 246 will also now be changed to reflect the new configuration information entered by the user. Assuming that the configuration of all of the channels of all of the cards (or other network interface devices) of interest is satisfactory to the user, the user can then click on the ok button 254 to exit from the dialog box 234 saving the confirmed configuration of the card/channel.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4648029Aug 27, 1984Mar 3, 1987International Business Machines CorporationMultiplexed interrupt/DMA request arbitration apparatus and methodUS5787246May 27, 1994Jul 28, 1998Microsoft CorporationSystem for configuring devices for a computer systemUS6229538Sep 11, 1998May 8, 2001Compaq Computer CorporationPort-centric graphic representations of network controllersUS6658489 *Mar 29, 2000Dec 2, 2003International Business Machines CorporationMethod for replacing a device driver during system operationUS6675226 *Nov 17, 1998Jan 6, 2004Rockwell Automation Technologies, Inc.Network interface for industrial controller providing application programmer interfaceUS6757750 *Sep 20, 2001Jun 29, 2004Via Technologies, Inc.Method of dynamically selecting a physical layerUS7203774 *May 29, 2003Apr 10, 2007Sun Microsystems, Inc.Bus specific device enumeration system and methodUS20020069245 *Oct 9, 2001Jun 6, 2002Han-Gyoo KimDisk system adapted to be directly attached to networkUS20030225931 *May 30, 2002Dec 4, 2003David CheonSupporting multiple protocols with a single device driverUS20040044798 *Aug 29, 2003Mar 4, 2004Uri ElzurSystem and method for network interfacing in a multiple network environmentUS20050066072 *Sep 15, 2004Mar 24, 2005Canon Kabushiki KaishaPeripheral control device and method for controlling peripheral deviceUS20050149948 *Dec 30, 2003Jul 7, 2005Intel CorporationSystem and method for monitoring and managing connection manager activityUS20050240942 *Apr 23, 2004Oct 27, 2005Hampton Kathryn AMethod and apparatus for managing related drivers associated with a virtual bus driverUS20060059287 *Sep 10, 2004Mar 16, 2006Pleora Technologies Inc.Methods and apparatus for enabling bus connectivity over a data networkUS20060122848 *Oct 22, 2003Jun 8, 2006Canon Kabushiki KaishaInformation processing method and information processing apparatusUS20080276257May 4, 2007Nov 6, 2008Fuchs Michael ASystem and Method for Implementing and/or Operating Network Interface Devices to Achieve Network-Based Communications* Cited by examinerNon-Patent CitationsReference1 *�PKTx Communication Card User Manual� by Allen-Bradley, Sep. 1997.2 *�Run-time Updating of Network Device Drivers� by Tanaka et al., 2009 International Conference on Network-Based Information Systems.3 *'PKTx Communication Card User Manual' by Allen-Bradley, Sep. 1997.4Rockwell Automation, "Allen-Bradley: 1784-PKTx Network Interface Card, 1784-PKTX-PKTXD," user manual, Publication No. 1784-UM527B-EN-P, Oct. 2003, 37 pages, Published in the USA.5Rockwell Automation, "Allen-Bradley: PKTx Communication Card, Cat. No. 1784-PKTX,-PKTXD, -PKTS," user manual, Publication No. 1784-6.527, Sep. 1997, 63 pages, Publisher: Rockwell.6Rockwell Software, "RSLinx Technical Data", user manual, Doc ID LINX-TD001C-EN-P, 2002, 8 pages, published in the USA.7 *'Run-time Updating of Network Device Drivers' by Tanaka et al., 2009 International Conference on Network-Based Information Systems.8Windows Hardware Developer Central; Requirements for the Generic Bus Driver Model; www.microsoft.com/whdc/archivebusreqs.mspx; Dec. 4, 2001; 3 pages.9Windows Hardware Developer Central; WDM: Introduction to Windows Driver Model; www.microsoft.com/whdc/archive/wdm.mspx; May 22, 2005; 5 pages.* Cited by examinerClassifications U.S. Classification710/62, 710/104, 719/321, 709/220, 719/327, 710/14, 710/72, 710/10, 710/300, 709/221, 710/73, 710/301, 710/8, 710/11International ClassificationG06F13/12, G06F15/177Cooperative ClassificationG06F13/102, G06F9/4411European ClassificationG06F13/10D, G06F9/44A4Legal EventsDateCodeEventDescriptionMay 4, 2007ASAssignmentOwner name: ROCKWELL AUTOMATION TECHNOLOGIES, INC., OHIOFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FUCHS, MICHAEL A.;SNYDER, DAVID A.;REEL/FRAME:019250/0210Effective date: 20070503RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google