RFTG.development - FMFT (EN)
FMFT - Flexible Manufacturing Field Trial 


FMFT- Flexible Manufacturing Field Trial 

Within the European project R-Fieldbus (http://www.hurray.isep.ipp.pt/activities/rfieldbus/), an industrial manufacturing field was developed. This field trial was conceived as a demonstration testbed for the technologies developed during the project, as well as for future teaching and research purposes. However, due to several reasons, its outdate became inevitable.
This work describes the control application designed and the implementation procedures that took place in order to accomplish the objective of updating the manufacturing field trial, accordingly to the PROFIBUS DP standards and the actual industrial fieldbus technologies.
Several software features, as well as a complete new application structure provided a fully modular base for present and future developments.

This work was part of Nuno Cruz and Ricardo Gomes first projects at the CISTER/IPP-Hurray! R&D group, and represents only a short resume of the documentation written in scope of the FMFT - Flexible Manufacturing Field Trial. 


1. Introduction

Between January of 2000 and July of 2002, with the common effort of several European educational and commercial institutions, the European R-Fieldbus Project (http://www.hurray.isep.ipp.pt/activities/rfieldbus/) was developed.
The main objective of the R-Fieldbus project was to support both the real-time requirements of control and status data as well as a user defined Quality of Service (QoS) for the multimedia communications. Additionally, it supported mobile industrial devices and interoperability with existing devices supported by wired industrial networks. Its architecture was based on the integration of boardband wireless technologies emerging at the time with existing industrial communication protocols such as those specified in the European Standard EN50170 [1].
To demonstrate the technical feasibility of the RFieldbus system in real industrial environments, its reliability, benefits for end-users and the opportunities for technology developers, two different field trials were developed. One was a process automation field trial at an oil refining plant. The other was a manufacturing automation field trial (http://www.hurray.isep.ipp.pt/activities/rfpilot/), built at the School of Engineering from the Polytechnic Institute of Porto (ISEP - Instituto Superior de Engenharia do Porto) by the CISTER/IPP-Hurray! R&D Group.

One of the goals of the development of the manufacturing field trial was the possibility of future employment of the equipment for teaching activities and research in the areas of factory floor networks, automation and mobile robotics [2].
However, after four years since the conclusion of the project, the equipment of the manufacturing field trial suffered from lack of updates and the necessary flexibility to fulfill its new goals. To update the manufacturing field trial and introduce actual flexible industrial field technologies, several modifications had to be introduced to the manufacturing field trial to bring additional advantages both as a teaching platform and as a research test bed.


2. Objectives

The main objectives in this work are:

  • Remove all deployed software and used prototype modules related with the R-Fieldbus project;
  • Update the manufacturing field trial in order to encompass standard industrial fieldbus technologies;
  • Introduce a new control philosophy based on a Programmable Logic Controller (PLC) instead of a PC application, therefore concentrating the main control application in a PLC that may be used for further developments;
  • Implement a user-friendly and simple interface to control the basic operations of the system (start, stop, refill and unload operations);
  • Provide a fully modular hardware and software base for further developments;
  • Implement a fully modular software base and provide compatibility with the OPC standards;
  • Optimize and assure reliability of the process.


3. The Flexible Manufacturing Field Trial

The R-Fieldbus project brought several developments in the industrial fieldbuses, and served as a guideline for other projects involving hybrid wired-wireless industrial networks. However, the nature of the prototypes used in this project as well as the fact that they have never entered the industrial market, made its use problematic either because of lack of drivers for recent Operating Systems, lifetime end, limited number and of course its consequent outdate. For this reason, all R-Fieldbus prototype equipment had to be discarded if the testbed was to be updated.
The Flexible Manufacturing Field Trial (FMFT) approach is completely different from its predecessor. The idea is to provide an easy and modular platform for any other industrial equipment that might find its way into the FMFT. Any new or old equipment, may it be for teaching or research purposes, can and should easily be integrated with the FMFT.

3.1. System overview

Presently the FMFT uses a fairly complex system of actuators, exchange terminals (also called I/O Station), conveyer belts, infrared sensors, swivel arms, pneumatic electrical motors, programmable logical controllers (PLCs) and other industrial equipment as well as a group of lights to report system status.
The general purpose of the FMFT is to have several different objects traveling over the conveyer belts, be able to correctly identify and classify these objects and finally direct the objects to the appropriate container.

As it is visible in Figure 1, the system is composed by three conveyer belts for the objects to travel on, two swivel arms that are responsible for transferring objects between two conveyer belts and there are four different buffers to collect the different objects. The pneumatic actuators (or kickers) in the system are located in the Input Buffer area – this one will feed the objects into the system – and two in front of the output buffers for the white and black objects. The two boxes in the middle of each conveyer belt represent the two Color Detector and Classifier (CDC) Stations that identify and classify the moving objects. There are also three electrical closets that store several electrical devices like the PLCs, the motor drivers and the exchange terminals.

Figure 1. FMFT overview


4. Network Configuration

The next figure, Figure 2, represents an overview of the FMFT data network as well as the equipments address in the network (I/O, ProfiBUS address).
Notice that all the I/O (either physic or logic) are referenced from #1 PLC point of view with the exception of the I/O Module directly controlled by #2 PLC. This one isn’t visible or even accessible by #1 PLC.


Figure 2. Network configuration


5. FMFT chain of events

The current purpose given to the FMFT is to detect and identify objects that are traveling on its conveyer belts. These objects should be classified and sorted correctly throughout the process.
The process starts after the system as been powered up and the START button as been pressed. This will run the initial system check routines. Once these are completed, then another press at the START button is necessary. This time it’ll begin feeding objects from the Input Buffer to conveyer belt 1. As an object is put on the conveyer belt it’ll trigger an infrared (IR) sensor (S2) that automatically sets the conveyer belt to begin moving so that the object and all the following objects can be transported to the first Color Detector and Classifier Station (CDC Station) where each object shall be classified accordingly to its color. After the classification process the object will either be WHITE, BLACK or GREY.
If the object is either WHITE or BLACK (Figure 3) then it will keep traveling on the first conveyer belt until it reaches its end. By then another conveyer belt will automatically start and will now be the one where these objects will travel on. If the object is WHITE then as soon as it stands in front of the white buffer, it’ll be kicked out of the conveyer belt into the respective buffer. If the object is BLACK, the situation described before will be identical except the object will only be kicked out when in front of the black buffer.

 Figure 3. Classification example

On the other hand, if the detected object was GREY then as it approaches the end of the conveyer belt it’s been moving on (conveyer belt 1), it’ll trip an IR sensor (S9) that will trigger a grabber (3rd or 4th grabber) to catch the object before it can pass and reach the end of the conveyer belt. This grabber will then transport the object to a parallel conveyer belt (conveyer belt 3) moving in the opposite direction the object as been traveling. The object will then pass by the 2nd CDC Station to be reclassified. If the object is GREY then it’ll keep on traveling along the conveyer belt until it reaches its end and falls down to the grey buffer.
Now the reason there’s a 2nd CDC Station on a parallel conveyer belt is because in case any of the buffers are full then the system will automatically start a recycling process, meaning that any of the objects that have their respective buffer full will be traveling between the 1st and the 3rd conveyer belts. On the 3rd conveyer belt this is done by reclassifying the objects and as they approach the end of the conveyer belt they’ll pass by an IR sensor (S10) that will trigger a grabber (1st or 2nd grabber) to transfer them back to the 1st conveyer belt.
The system will automatically decide if new objects can be added to the process by checking if an overlap or a too close insertion of objects event may occur when the recycling process is taking place.
Observe Figure 4. Notice how the objects state is ‘unknown’ before each of the CDC Stations and after being transferred between conveyer belts. The reason for this is that the system uses two individual stacks of classification (one for each CDC Station) to keep track of all the objects that are moving on the respective conveyer belt. Since there is no way/need to obtain a “confirmation” classification, something like forcing all objects to pass by both CDC Stations before being sorted, the implemented approach is ideal and performance-wise. Also notice how the “kicking objects” routine happen like it was described previously.
Finally, note that at the end of the 2nd conveyer belt there’s another buffer. This is the recycle buffer. Its purpose in the system is to be a safety buffer in case either the WHITE or the BLACK is accidentally removed while a white or black object is already on conveyer belt 2. If that’s the case, the system will not trigger the respective kicker and the object will be directed to the recycle buffer.
Notice that although the system is capable of feeding a maximum input rate of forty-six objects per minute from the Input Buffer, at the maximum speed available to the conveyer belts the swivel arms will only manipulate objects reliably at a maximum rate of twenty-three objects per minute.


Figure 4. Overview of the chain of events

5.1. Human interaction with the system

In the pursuit for automating as much as possible, human interaction with the system was kept at a minimum level. Although some modifications could be done to the system so that it could operate by itself, at this stage, allowing for some human interaction provides a much more motivating and “controllable” environment for presentations and teaching purposes.
Some of the more important forms of human interaction allowed are:

  • The system requires an operator to provide it with power, that is, to turn the POWER button to ON state;
  • The system requires an operator to signal the start of the chain of events by pressing the START button;
  • The system allows for an operator to lift an output buffer to simulate it being emptied;
  • The system allows for anyone to press the Emergency Buttons if there’s need to stop the system immediately;
  • The system requires an operator to refill the Input Buffer when it becomes empty and to signal that it as been refilled by pressing the Input Buffer Button next to the mentioned buffer;
  • The system allows for an operator to stop the input of new objects into the system by pressing the STOP button;
  • The system allows for an operator to shutdown the CDC PC Station by pressing the STOP button after the system become stopped;
  • The system allows a bypass to the initial fifteen minute delay from the CDC Stations lights warm-up, by pressing the STOP and the START buttons simultaneously (It is advised to check the Troubleshooting Q&A section to understand the implications of this bypass).

5.1.1. FMFT system lights explained. For an easier assessment of the testbed status there are several lights spread all over the testbed that assist in a quicker and more intuitive way. There’s a main beacon composed of three lights: a green, a yellow and a red one – just like a traffic light. There is also one state light near each buffer. Its behavior, and correspond meaning, is describe as follows:

  • When both RED and YELLOW lights of the main beacon are ON, that means the system as successfully booted up and is ready to undergo initial routines once the START button is pressed;
  • When ALL lights in the field trial are flashing, that means the system is running its initial routines like clearing variables, making sure no objects are over the conveyer belts and so on. If this state continues after the conveyer belts have stopped for a long period of time then please check the Troubleshooting Q&A section of this document;
  • When all main beacon lights are flashing alone, this means that the system is waiting for the CDC Station lights to warm up and the CDC Station PC to boot. This only happens during the start up process and after all conveyer belts stop;
  • When the GREEN light of the main beacon is flashing slowly, it means the system as completed successfully all its initial routines and is now ready to start operating as soon as the START button is pressed;
  • When the main GREEN light is ON, it means the system is operational and running;
  • When any of the lights near each output buffer are ON, it means that the respective buffer is full;
  • When any of the lights near every output buffer are flashing slowly, it means that the respective buffer is being manipulated (like being emptied by an operator);
  • When any of the GREEN lights near every output buffer are flashing rapidly, it means that the respective buffer as been lift before it was full. If that happens when black or white objects are already in the 2nd conveyer belt, the system correctly assumes that the buffer is unavailable and will redirect all objects from their respective buffer to the recycling buffer, until the unavailable buffer is put back in place. If the mistakenly lifted buffer as no correspondence with the objects traveling in the 2nd conveyer belt then the affected objects will be manipulated as in the recycling process;
  • When the main GREEN light is ON and the main RED light is flashing slowly, that means the system will undergo the STOP routine. It means the STOP button as been pressed and the system will disable the input buffer and stop as soon as it clears all the remaining objects still traveling on the conveyer belts;
  • When the GREEN, YELLOW and RED lights of the main beacon are ON, this means the EMERGENCY BUTTON as been pressed and the system stops immediately;
  • When the GREEN light near the input buffer is ON, it means that the buffer as objects to feed and is enable. Otherwise the buffer is empty or disabled;
  • When the Input Buffer Button Light flashes slowly, it means that its buffer is empty. Objects should then be added to the Input Buffer and once ready, this button should be pressed so that the Input Buffer starts feeding objects again;
  • When the main RED and YELLOW lights are flashing slowly this means that after the system as concluded a STOP routine successfully (the STOP button was pressed again) and now the CDC Station PC is undergoing a shutdown;
  • When the main RED light is ON it means that the system is stopped and the CDC Station PC is turned off, therefore the system can now be turned off safely;
  • When the main YELLOW light is flashing rapidly it means that an error as occurred in the process. Please check the Troubleshooting Q&A section for possible causes and solution.


6. FMFT control

In the approach to update the FMFT it was clear that the system should be deeply reconfigured to encompass actual flexible industrial manufacturing field technologies.
Also, the system’s software, due to the original goal of the manufacturing field trial, wasn’t flexible enough. The control was centered on an application built specifically for the equipment involved and, therefore, modularity wasn’t sufficient to embrace different projects developed from different people, especially from junior developers as well as future updates/upgrades of software and hardware.
The lack of modularity of the main control application was definitely overcome by the implementation of a new control philosophy based on a PLC instead of a PC application that, along with a solid documentation source, provides a fully modular software and hardware base for further developments.
The successful addition of new equipment and the optimization of the already existent in the testbed is the best witness of the achieved goal.

6.1. Decentralized monitored areas

The next picture, Figure 5, represents the logically implemented areas that are monitored by the decentralized equipments in the network. The green area is monitored and controlled by the #2 ET200M, meaning that all the field sensors and actuators in the conveyers belts 1 and 3 are connected to the mentioned equipment. The red area is related to the swivel arms operations, therefore it’s monitored and controlled by the #2 PLC as previously mentioned. The last colored area is related to the 2nd conveyer belt, so all field sensors and actuators located in the conveyer belt area are connected to the #1 ET200M. Finally, just as a reminder, all of these areas are supervised by the #1 PLC.


Figure 5. Decentralized monitored areas

6.2. Basic communications explained

Physically the entire network is connected through RS-485 cabling bus in which the ProfiBUS-DP protocol is implemented. This is used to link the main devices of the network (MicroMasters, PLCs, ETs, CDC Station PC) providing fast data transfer rates with native error control mechanisms, assuring reliable real-time control ability.
Even so, there are a few considerations to be mentioned like the fact that there are several field sensors and actuators spread all over the testbed and they DO NOT communicate directly with #1 PLC – where the main control of the process is deployed. Instead the sensors and actuators are linked to one of the exchange terminals (ET) and these stations then communicate with #1 PLC, performing a transparent high level control. #2 PLC has the swivel arms sensors and actuators directly linked to its I/O ports.

ProfiBUS-DP is a fieldbus protocol which implements a logical ring, sharing a token with all the masters in the network that need to communicate. In the current testbed there are two masters, the #1 PLC – S7-315-2dp – and the CDC Station PC. All the mapping and addressing in the field trial is referred to the #1 PLC. This happens because of the previously described new control approach. The CDC Station PC as been setup as a master in the network for convenience reasons and predicting further developments.
The communication between these two masters is made by running an OPC server and establishing a S7 connection (logic type) between the OPC server and #1 PLC .

The OPC server works as an intermediate software layer, connecting the CDC Application and the PLC in a high-level transparent way. This enables any OPC compliant client to write/read values to/from the #1 PLC addresses that are being pooled by the OPC server.

Although the previous approach regarding the communication between the CDC Station PC and #1 PLC was to write directly into the ProfiBUS network, this new approach makes everything more modular and easy to follow.

6.3. #1 PLC (S7-300) control structure

The goal of the structure designed for programming the main PLC (#1 PLC) of the network was meant to make it readable after the developers stopped working with it, modular so that old contents could be easily removed and new contents could just as easy be implemented and still present a good performance solution.
The code as been written using LADDER logic to improve overall readability (sacrificing the efficiency of writing it in STL), and most importantly it was divided into different functions (FCs) as to resemble object-oriented programming. Also, the number and label of each FC has a correspondence with the “State” number in the program it relates to.
In order to allow data communication, in a transparent way, between the referred PLC and the #2 PLC, the MicroMasters and the CDC Station was created a special memory are that was “shared” between all this devices.

6.4. #2 PLC control structure  

For the #2 PLC the control approach was slightly different than the one described for the #1 PLC. #2 PLC is only responsible for operating the swivel arms, therefore its code isn’t nearly as extensive and complex as the code in the #1 PLC. Also, since this PLC will only be addressing the swivel arms there isn’t the need for modularity. Therefore the approach for the #2 PLC was to write all its programming in the main cycle block.

6.4.1. Swivel arms control program explained. In order to maximize the system modularity, the #2 PLC is fully responsible for controlling the system swivel arms. Mechanisms were implemented in order to provide a sort of high level control of both swivel arms, thus from #1 PLC point of view it’s only necessary to order #2 PLC to transfer a object from one conveyer belt to another and wait for #2 PLC “operation concluded” signal. This is done by accessing special flags. For example, when #1 PLC detects a negative edge transition in S9 and the object must be transferred from conveyer belt 1 to 3, the flag “mov_to_3_o” is set (transfer order) and when #2 PLC gets that order an acknowledge flag is also set (from #2 PLC the flag is “mov_to_3_o”; from #1 PLC the flag is “mov_to_3_i”) in order to achieve failsafe. After that #2 PLC will schedule all the necessary activities to fulfill the transfer task (determining the conveyer belts speed, timers loading and managing, actuators control, etc…). When the object as finally been transferred and dropped at its destination the transfer operation is then concluded and will be signaled to #1 PLC.
Due to the fact that the actual speed of conveyer belts 1 and 3 is sent to #2 PLC (every time sMM1 is changed), #2 PLC adapts its actions to those speed changes, allowing that the speeds in the conveyer belts to be dynamic affecting #2 PLC operations. #2 PLC also provides mechanisms for the #1 PLC to decide when conveyer belts speed can change and to avoid objects overlapping next to Input Buffer.


7. CDC station explained

The CDC Station is responsible for the correct detection and classification of the objects traveling over the conveyer belt.
Each object in the FMFT has a color and it can either be Black, Grey or White. Although the objects have clearly distinct base colors, on the field, they’re not so distinct because no object is completely homogeneous. This means that, for example, you’ll find black objects that have scratches or grey marks on them, or that some objects have a light reflective surface or even that some white objects have black spots. There’s also the fact that the conveyer belt has a dark blue-green color that in a particular area gets very dark. Another variable to be accounted is the fact that at the system’s maximum speed, each object will be under the cameras for less than a second.
That being said it’s imperative that the station is able to filter all these variables and output the correct object color.
The thought up solution is based on sampling and on a software that provides a well-defined range for each component (RGB-wise) of the analyzed color.
The CDC Station’s software application purpose is to communicate the correct detection and classification of the objects to the main control unit on the network – #1 PLC. As mentioned before, although the entire network uses ProfiBUS-DP protocol and therefore uses the same physical connection (RS-485), communication between the CDC Station and #1 PLC uses a logic S7 connection. On the #1 PLC side there are two bytes reserved for receiving data from the CDC application (IB6 and IB7 for camera 1 and camera 2 respectively). These two bytes will hold certain decimal values that once converted to binary will represent camera state (on/off) and detected color.


8. System limitations

There are known limitations in the system capabilities. Some of these were deliberately created by the developing team (these are mainly software based limitations and has such can be changed to represent and satisfy the system needs) while the others exist due to the limitations inherent with the use of some of the hardware in the FMFT. The following are the known limitations in the FMFT:

  • White and Black Output Buffers have a software limit in their capacity. They are limited to hold a maximum of four objects each;
  • Grey Output Buffer can hold a maximum number of fifteen objects. Notice that this buffer doesn’t have a “reset mechanism” (lifting the buffer to simulate being emptied) like the above buffers, so it’ll only reset when the system undergoes a stop routine;
  • The maximum speed of the Conveyer Belt 1 is 0.186 m.s-1;
  • The maximum speed of the Conveyer Belt 2 is 0.179 m.s-1;
  • The maximum speed of the Conveyer Belt 3 is 0.191 m.s-1;
  • The Input Buffer can feed the system with forty-six objects per minute but the system Swivel Arms can only operate reliably at a rate of twenty-three objects per minute. Therefore the latter rate is the maximum feeding rate for the system;


9. Troubleshooting Q&A

This section is designed to assist in case of difficulties or problems that might occur when using the FMFT. Although extensive, it won’t predict all possible difficulties and situations that might present to the reader therefore, when in doubt, use common sense, search in the resources that are listed in this document and/or consult an IPP-Hurray! Group resident specialist:

Q: System initiated correctly but the conveyer belt doesn’t start.
A: Check if the air-pressure valve is open.

Q: Turning the POWER button doesn’t make the system boot-up.
A: Check if there’s a power outage or power failure in the building. Also check if every fuses and thermo-magnetic relays are ok.

Q: Everything was working but suddenly everything stopped.
A: Most likely there was either a power outage or a power surge. Turn off the system, re-establish power to the system and turn the POWER button on.

Q: After pressing the START button once, the system boots up but the RED and YELLOW main lights don’t stop flashing.
A: Did it pass fifteen minutes since you pressed the start button? Remember that the CDC lights require a fifteen minutes warm-up after a system shutdown. The system will only be ready to run after this period of time. If the fifteen minutes period is over and the lights are still flashing then it could also be that the system is waiting for the CDC application to establish a connection. Restart the app if it’s already running.

Q: The color detection and classification doesn’t seem to be working at all.
A: If the classification isn’t working AT ALL then it’s probably because the CDC Station lights need more time to heat up or there’s a problem with the OPC connection. In case of the last, check the “OPC_Client.log” for debug and double check if all steps were made correctly during CDC app and FMFT installation. There’s also the chance that the app simply froze or just isn’t running.

Q: Can’t download modifications/updates to #1 PLC.
A: Is the PLC turned on? Is the PG/PC interface set to internal? Is the name of the computer specified correctly everywhere? The Station Name in NCM must be the same as in Station Configurator as well as the name of the PC as indicated in the PC’s Control Panel. No period in the end of the name. Case must be the same (“NAME”, “Name” and “name” are all different).

Q: The system has power but pressing the START button doesn’t do anything.
A: Are the RED and YELLOW main lights on? If so, turn off the system and turn it back on. If not, check if the #1 PLC is physically set on RUN mode. Also, check if neither of the EMERGENCY buttons is pressed.

Q: “Black spots”/“Grainy view” appear sometimes on the camera view.
A: This is usually an indication that either there’s to much light in the CDC Station or that the camera’s CCD is breaking down. No real solution besides a hardware change.

Q: Sometimes the CDC Station doesn’t classify correctly.
A: Are both lights in the CDC Station turned on? Have the lights been on for more than 15 minutes? The used lights in both the CDC Station require some time to be able to produce the right intensity of light for the correct classification. Are you using the system’s original objects? Only GREY, WHITE and BLACK objects will be classified.  It can also mean that there’s a problem with the power supply of the cameras since it might be feeding enough power to enable the cameras to capture an image but not the enough to process it correctly. It could also mean that a new calibration is necessary.

Q: The CDC Application won’t start.
A: Are the camera drivers installed? Are the devices plugged-in? Check the “stderr.txt” file for more information and debug.

Q: The CDC Application starts but no image is displayed.
A: This usually happens if the app can’t make a connection to the OPC server. Is the system powered on? Are the red camera sights displayed? If so then you forgot to turn on the lights or there’s no power going to the lights. Be prepared to restart the app because as soon as the lights are turned on, the flashes will trigger the app classification. In any case, the lights should be on at least for fifteen minutes BEFORE the system is run to ensure correct results.

Q: The conveyer belts don’t stop after the first time the START button was pressed.
A: Check if all the output buffers are placed correctly. Also check if all the field sensors are working properly and finally check if there’s air pressure in the system.

Q: I have the need to perform some debug to be sure that the classification is done properly. What’s the best set up?
A: Such debug can be made in many ways. The one we mostly used was to tap into the OPC server with an OPC Client and check if the values being updated corresponded to those that we expected. Also, if you have a programming station at your disposal you can use STEP7 monitor functions to check the status of each of the color stacks in real-time.

Q: What are the implications in bypassing the CDC Station lights warm-up?
A: If this bypass is used in the very first time the system is run (after a prolonged shutdown time) the lights WON’T be able to produce the necessary light intensity required by the CDC Station to correctly classify the objects. This bypass was created to allow a quick shutdown-boot up by not requiring the initial fifteen minute wait.
Q: The FMFT System Lights Section directed me to the troubleshooting section. What happened?
A: If the main YELLOW light is flashing rapidly then an error in the process as occurred for sure. At this point, only two reasons can create such an error, either one of the output buffers was lifted before its maximum capacity was reached or the CDC Station app was closed or failed while the system was running. To turn the light off, fix whatever reason cause it to start in the first place and then signal for a system stop.


10. References 

[1] IPP-HURRAY, “RFieldbus Website – Project Summary”, 2002, online at: http://www.hurray.isep.ipp.pt/activities/rfieldbus/.

[2] IPP-HURRAY, “RFieldbus Manufacturing Field Trial Website”, 2002, online at: http://www.hurray.isep.ipp.pt/activities/rfpilot/.

11. Consulted/advised bibliography

“Manual – SIMATIC S7-300, CPU 31xC and CPU 31x Technical Data”, SIEMENS, Nürnberg, Germany, 01/2006.

“Getting Started – SIMATIC Automation System S7-300”, SIEMENS, Nürnberg, Germany, 01/2006.

“Operating Instructions – SIMATIC S7-300, CPU 31xC and CPU 31x: Installation”, SIEMENS, Nürnberg, Germany, 01/2006.

“SIMATIC S7-200 Programmable Controller System Manual”, SIEMENS, Nürnberg, Germany, 08/2005.

“SIMATIC S7-200 Programmable Controller System Manual, SIEMENS, Appendix A – EM 277 PROFIBUS-DP Module Specifications”, Nürnberg, Germany, 08/2005

“SIMATIC S7-200 Programmable Controller System Manual”, SIEMENS, pp. 396, Nürnberg, Germany, 08/2005.

“Operating Instructions – SIMATIC Distributed I/O device SIEMENS, ET200M”, Nürnberg, Germany, 02/2006.

 “Manual – SIMATIC Automation System S7-300 Module Data”, SIEMENS, Nürnberg, Germany, 08/2006, pp. 3-17; 3-107; 3-116.

“Operating Instructions – MICROMASTER PROFIBUS Optional Board”, SIEMENS, Erlangen, Germany, 02/2002.

Nuno CRUZ, “CDC PC Station Guide - Tutorial”, IPP-Hurray!, Porto, Portugal.

Nuno CRUZ, Ricardo GOMES, “Technical Report - Flexible Manufacturing Field Trial”, IPP-Hurray!, Porto, Portugal, 10/01/2007.


Photo Gallery


Demonstration video 



it's private)

Powered by ChangeDetection