PROFIBUS Cables

PROFIBUS DP generally has one master and up to 31(or more with expanders) slaves. These are connected by two twisted wires in a shielded cable and signals are sent by alternating the differential voltage, nominally 24V, across the two wires. The cable is terminated at each end with a series of resistors that help maintain, particularly in very long cables, the signal’s quality.

Most PROFIBUS connectors have a built-in switch to terminate the cable. Ideally, a PROFIBUS system will have one length of PROFIBUS cable that is terminated on both ends with devices connected along the cable. If one end is left unterminated, the capacitance and inductance of the wire acts as a pulse forming network where the alternating voltage propagates through the wire and creates ripples.

Early radar systems used long twisted pairs of wires to form high voltage pulses. However, this phenomenon, referred to as signal reflection, is often more destructive than useful or intentional.

The above two photos show two different PROFIBUS signals at work on a cable about three meters long. The left photo shows the signal in a properly terminated PROFIBUS cable where the signal is very clean and has sharp rise and fall edges. In contrast, the right shows the signal on the same cable but without termination. The noise introduced by unterminated lines is proportional to the length of the cable, so the longer the cable the worse the noise. Even at 12Mbps, the fastest most PROFIBUS systems use, both PROFIBUS signals still work.

Branching

Branching PROFIBUS cables is possible, although it’s generally not advisable. The longer a branch of PROFIBUS cable, the more noise it will introduce with a higher chance of it interfering with the signal.

In this case, a one meter branch out from an already terminated PROFIBUS cable is not as bad as an unterminated cable end. The signal is still workable, but it does introduce a very noticeable amount of noise.

For short cable lengths, and electromagnetically quiet environments, this noise is minimal and acceptable. For larger systems, however, it can interfere with devices ability to communicate. If a PROFIBUS cable must be branched the terminations should be placed as far away from each other as possible with the unterminated branches as short as possible.

When setting up critical PROFIBUS systems were noise is a concern, keep in mind that electromagnetically noise is rarely constant. Daily and yearly cycles, as well as acute events like power outages, can greatly alter the magnitude and frequency of electromagnetic noise. Also, always make sure the PROFIBUS cable’s shielding is grounded to help minimize noise in the signal.

Adding Terminating Resistors

If unterminated lengths of cable introduced more noise and reflection, would adding terminations to each branch reduce the problem? Kind of. The more terminating resistors and the lower their resistance, the less reflection we’ll see between the two wires in the PROFIBUS cable. Lowing this residence means that the devices on the network will output more current, take longer to rise and fall, and not see as high of voltage between the wires.

Most systems and devices will likely tolerate a third termination in the system. Although it’s still not advisable since the extra current and lower voltages may stress devices or cause signals to be unreliable in extremely long cables.

In addition to this, long cables with low resistance will have increased rise and fall times. Longer rise and fall times mean that the devices will have to communicate at a slower speed.

The left photo shows the rise time on the same PROFIBUS network as above, and the right shows the rise time with the addition of a third terminating resistor. With only two terminations, the system can rise and fall (10%-90%) in about 5ns. In contrast, the third terminating resistor brings this time up to over 40ns. Three terminations may work for a low transmission rate networks, but faster networks may become unreliable.

Conclusion

Properly structuring and understanding PROFIBUS can save significant time and money while increasing reliability. If you need help architecting or implementing PROFIBUS, or any industrial automation system, contact DMC. Hopefully this helps you understand how PROFIBUS works a little more.

The post Can You Branch PROFIBUS? appeared first on DMC, Inc..

States

First, we should contrast the two most common types of state machines, Moore and Mealy. Moore state machines set outputs based on only the current state. By contrast, Mealy state machines set outputs according to the current state and current inputs into the system. The most significant difference is where decision logic is located within the state machine. Moore state machines place the decision logic in the transitions while Mealy state machines place the logic in the states.

Functionally both Moore and Mealy state machines can both accomplish the same tasks, the only difference is how readable the state machine will be. We’ll focus on Moore state machines here, because I find them to generally be more readable in most situations. 

For machine control, the controller dictates a system’s state. It’s often essential to have the controller verify that the state it’s in matches the physical system, particularly when recovering from power cycles or manual operation. Some systems do this exclusively with sensors, while others rely on the assistance of human inspection. For example, robotic arms typically have sensors that ensure the area is locked off for safety and then ask the operator to confirm that the area is clear before moving. 

Another special case worth mentioning is when states have internal properties. These setpoints allow a single step to count or output a user-defined value. These properties are very useful for a system that needs to count the number of times something has happened or want to use a user-defined set point.

Transitions

Transitions connect states. Each transition has a direction and set of conditions that have the be met to transition into the next state. Once a transition’s conditions are met, the state machine transitions states and begins setting outputs for the new state. Individual states can also have multiple leaving transitions, each with different conditions.

Sequencers

Sequencers are a subset of state machines that consist of states that each have only one transition. This means that sequencers do not have any logic to pick from multiple states and always execute the same states in the same order. Sequencers are some of the simplest state machines and are often used to help organize larger state machines, compressing multiple steps into a single step.

Finite State Machines

More complex state machines have branching transitions that allow the system to transition to different states depending on situational conditions. State machines are far from the only method of doing this but are one of the most structured and readable methods. This fact is a valuable and often overlooked aspect of programming. Readable code with clearly organized structure is easier and faster to commission and debug, as well as easier to add to latter logic if more functionality is needed.

Near Infinite State Machines

More complex state machines may allow the operator to order individual steps to form more complicated processes. These state machines use an intermediate step that selects the next step based on the operator’s selection and can have near limitless configurations. The ability to define new sequences of steps on the fly and pass differing parameters to steps make these state machines, and the machines they control as versatile as possible.

Each step in the process is treated as a single state, even if functionally, it has many individual steps within it. Each step is treated as a single date because these states have only one or two possible outcomes: successful completion and/or unsuccessful completion. When a step is completed successfully, the systems will execute the next step, and so on until all the defined steps are complete. If a step fails, the system will transition to a fault handling state, pausing the machine and communicating the error to the operator.

The difficulty in designing this type of state machine and still making it easy to use lies in structuring each step so that it can follow any other step. Special care must be taken to disable or prevent potentially dangerous actions from executing when they could cause damage to the machine or operator.

Hopefully, this information helps you understand a little more about how state machines and the systems they control work. Developing a proper state machine early on can save a lot of time and effort, as well as preventing a costly bug in the program. Also if you’re programming in Siemens’ TIA Portal, check out the Sequencer block in the Siemens Open Library, it’s great for designing sequences and state machines.

Learn more about our PLC Programming expertise. Contact us for any project inquiries. 

The post Finite and (Almost-) Infinite State Machines appeared first on DMC, Inc..

Cyclic vs. Interrupt Code

Code on a PLC is called either cyclically or by an interrupt. Cyclic code runs start to finish repeatedly as fast as possible, so long as the CPU is not interrupted by an interrupt call. Interrupts pause the code currently running on CPU, call the interrupt code, and then once the interrupt code is complete, resume what the CPU was doing. Most PLCs can tie interrupts to cyclic timers, startup, value changes, and/or errors. Interrupts can also interrupt other interrupts if they are of a higher priority.

The diagram above shows what a PLC’s CPU spends its time doing. The pink represents cyclic code that would take the CPU 5ms to complete if it weren’t interrupted. The green represents the communication load on the CPU taking up to 0.15ms of every 1ms, and blue is the motion control code called every 5ms by a cyclic interrupt. In this example, the motion control interrupt is the highest priority, meaning it can interrupt communication and cyclic code.

Cyclic code is commonly referred to as the main PLC code. Siemens refers to cyclic code as a program cycle or OB1, and Allen-Bradley calls it a continues task. Interrupts, other organizational blocks in Siemens or event tasks in Allen-Bradley, allow the designer to specify precisely when the interrupt code should run in relation to an event or a timer.

For example, high-speed counters are typically tied to hardware interrupts, allowing a hardware input to increase the count in the PLC immediately. View this blog for examples of high-speed counters. This means that the high-speed counter can count multiple inputs before the PLCs main code has completed a full cycle. Similarly, PID control loops and motion control code are offend tied to cyclic interrupts, with varying cycle times. Physical systems that are slow to respond can be tied to cyclic interrupts with long cycles. This, in turn, reduces the CPU load. Systems that are quick to respond can be tied to much faster cycles allowing for tighter control, at the cost of CPU load.

Cycle Time

PLC cycle time is defined as the time it takes to run the cyclic code start to finish once with interrupts. Because of the number and frequency of interrupts between cycles, cycle times also very. In most cases, we are concerned with the maximum cycle time since this corresponds to how long it will take the PLC to respond. A general rule of thumb is to assume that the PLC could take as long as twice the maximum cycle time to respond. This means if we have a running signal indicator light, it could be up to twice the max cycle time between when the PLC gets the running signal and the light turns on.

Most PLCs monitor the cycle time and will alarm if the cycle time exceeds a maximum threshold. The specific threshold should be configured based on the application and the maximum acceptable response time of the PLC. Cycle times are particularly important in safety applications where the PLC’s response time can add to the response times of other components.

Reducing Cycle Time

There are a few methods to decrease the PLC's response time if cycle times must be reduced. Firstly, consider if the PLC’s CPU can be upgraded. A faster CPU will execute code faster and reduce the overall cycle time. This method is particularly effective for projects that have a lot of motion control and PID control loops, as these functions are generally very CPU intensive.

Siemens 1511 CPU (14.9ms Cycle Time)

Siemens 1517 CPU (6.3ms Cycle Time)

The next aspect to consider is the communication load. Communication load is defined as how much of the CPU’s time is spent communicating with other devices, and typically ranges from 15% to 50%. Upgrading the CPU can help reduce the communication load some, but for the most part, reducing communication load is a function of the communication method(s) and quantity. Consolidating the number of devices the PLC must communicate with and/or using communication methods with less overhead can both help but are often harder to implement.

Another method for reducing cycle time is optimizing the code itself. Moving pieces of code that do not have to run every cycle into cyclic or other interrupts can help reduce mean cycle times, but may not have much effect on the maximum cycle time. Moving code into interrupts can also make testing the cycle time more difficult as the interrupts may or may not occur in every cycle.

Monitoring Cycle Time

Siemens' S7 TIA Portal PLCS:

TIA Portal has a built-in tool that allows you to monitor the cycle time of a physical PLC or a simulation of the PLC. To monitor the cycle time, first, go online with the PLC, upload the PLCs code, and then open Online & Diagnostics. Under Diagnostics>Cycle time, you’ll see a bar chart with the current PLC cycle time. The light blue box represents the allowable cycle time, and a red bar indicates that cycle time has exceeded the maximum. This is shown in the diagram below. 

To change the allowable cycle time, open the PLC’s Device configuration and under General>Cycle, update the maximum cycle time. You will have to be offline with the PLC to change this value and then redownload to the PLC for the change to take effect. Remember that the max observed cycle time may not be the actual max cycle time. This can happen if the code running on the PLC has many interrupts, or long and looping pieces of code called by interrupts.

Allen-Bradley and Other PLCs:

Finding the cycle time of other PLCs can be done more manually, although it’s no less relevant or useful for developing well-optimized code. The simplest way is to check the system time at the start of each cyclic call and compare the current system time to the previous system time. This method will include the overhead time the PLC takes to communicate and scan I/O. With a little more logic, you can easily find the min, max, and mean cycle times.

Understanding cycle time, cyclic calls, and interrupt calls is key to architecting successful PLC code and just one of the areas DMC excels at. Good architecture early on in a project can save time and allow the uses of more cost-effective hardware, while still meeting project requirements explicit and implicit.

Learn more about DMC's PLC Programming services and contact us to get started on your next PLC Programming project.

The post PLC Cycle Time appeared first on DMC, Inc..

Digital

Perhaps the most straightforward signal is a digital signal. Digital signals have two states, on and off, sometimes called true and false, high and low, closed and open, or one and zero. Digital inputs and outputs have four key voltages.

These voltages are the absolute maximum and minimum voltages. The minimum voltage is considered high, while the maximum voltage is considered low. Outputs also have a max supply current that must be greater than the max sink current for an input. For most digital devices these voltages have been standardized.

In the case of TTL (Transistor-Transistor Logic) the nominal voltage is 5 volts, but anything greater than 2 volts on an input is considered high, and similarly, anything less than 0.8 volts on an input is considered low. This allows for some error/residual voltage from the output as well as some noise in the wires transmitting the signal.

In practice, most signals will be very close to 0.0 or 5.0 volts. However, in extreme cases where signal wires run exceedingly long distances, left unshielded in electromagnetically noisy environments, or draw more current then the output can supply, can push voltages outside of these ranges causing problems.

For a simple example, let’s look at a PLC reading in a button and flashing light when the button is pressed. The button connects a +24V rail to the PLC’s input, and the light connects the PLC’s output to the ground. When the button is open, the PLC will see zero volts plus or minus some noise on the line and the input should read low, or open.

When pressed, the button closes sending 24V, minus some small loss in the wires, to the PLC and the PLC’s input should then read high or closed. When the PLC’s output is low, there will be no difference in voltage across the light, and when the output is high, the light will turn on. This assumes the PLC’s output can supply enough current to the light, without burning out or dropping in voltage. If the PLC’s output cannot provide enough current, we would have to add an amplifier, relay or MOSFET, to drive the light.

Analog Signals

Analog signals come in two main varieties: voltage and current. Analog voltage signals vary the voltage across an input while analog current signals vary the current running through the circuit. Functionally, they both communicate a value between 0 and 100%, plus or minus some error. Many modern PLC input cards can accept either voltage or current signals.

Voltage signals are easy to troubleshoot and probably work with the broadest range of devices, including many low-cost microcontrollers like Arduinos. However, voltage signals are prone to picking up noise and interference from objects such as motors, contractors, and long thin wires. Because of this, it’s essential to consider the environment the sensor and wires will be in and shield or separate the wires accordingly.

By contrast, current signals are more difficult to debug and are not entirely as widely used (yet). Nonetheless, they are less affected by noise and wire length.

Additionally, 4 to 20 milliamp current signals have some built-in fault detection that, unlike voltage signals, can differentiate wire breaks and other problems from the regular operation. Finally, most current sensors only require two wires while many voltage sensors require three, a minimal consideration but worth keeping in mind when designing or updating a system.

I2C, SPI, and UART

I2C, SPI, and UART are all low-level serial communication methods capable of transmitting variable data bidirectionally. Essentially, serial communication uses digital inputs and outputs to send strings of ones and zeros that represent analog and digital values. They are often used in favor of individual analog and/or digital signals that would require many individual wires as well as many input and output points.

I2C communication can have one or more masters and one or more slave devices, connected to that master via a common ground, SCL, and SDA. The SDA wire indicates the value of each bit and the SCL wire determines when to read each bit, rising from zero to one to indicate the next bit is ready. Because of this structure, the master and slave do not have to have a common baud rate or clock speed, and only one device can communicate at a time.

To initiate communication, the master sends out a start condition, followed by the address of the slave device, and a read or write bit. When writing data to the slave device, the master controls the SDA line, and if reading from the slave device, the slave device controls the SDA line. In effect, whichever device is sending data controls the SDA line.

SPI communication always involves exactly one master and one or more slave devices. Slaves are connected to the master by a common ground: SCK, MISO, MOSI, and a SS. Each slave device has its own SS pin, often expressed as SS1, SS2…SSn. Slaves are selected, or enabled when the master pulls their corresponding SS line and begins sending data.

Like I2C, the SCK line indicates when to read the MISO and MOSI lines to get specific bit values. MISO stands for Master In Slave Out and MOSI stands for Master Out Slave In. By having two data lines, MISO and MOSI, SPI can send and receive from a slave simultaneously.

UART stands for Universal Asynchronous Receiver Transmitter. Without specialized hardware or more complex architectures, UART only supports two devices. There is also no clock line connecting devices. Instead, the devices communicate using a predetermined baud rate based on their internal clocks. At any time, either device can initiate communication and send data to the other. This means that only three lines are connecting the two devices common ground, TX, and RX.

Ethernet

Ethernet is an even more general term used to refer to a very broad subset of serial communication protocols including Ethernet/IP, EtherCAT, PROFINET Modbus TCP and many more. In contrast to I2C, SPI, and UART, these communication methods typically support many more devices networked together and provide some built-in fault detection and handling. This makes Ethernet communications the go-to method for most long distance and industrial applications.

Understanding the full range of communication methods and standards is just one of the ways DMC can help design robust and reliable systems. Whether you’re designing a small microcontroller or a massive network of PCs and PLC, understanding the basics of input-output communication will save you time and money.

Learn more about DMC's Manufacturing Automation and Intelligence services and contact us for additional support.

The post A Primer on Signal Types and Serial Communication appeared first on DMC, Inc..

This tutorial will demonstrate how to set the IP address of a PowerFlex VFD drive and how to uses Logix Designer to configure drive and motor parameters needed for commissioning.

Setting the IP Address Using BootP

Perhaps the simplest way to configure the IP address of a new PowerFlex drive is to uses BootP. BootP is a free DHCP tool that allows you to quickly set the IP address of a device using the device’s MAC address. Each PowerFlex drive will have a unique MAC address that can be found somewhere on the physical drive. For PowerFlex 523, 525, and 527s it’s located under the drive’s terminal cover on the left side of the case.

1. Once you have the MAC address for the drive you want to configure, open BootP. If prompted, select the network interface that’s connected to the same network as the drive.
2. Once BootP has found the drive, you should see the drive’s MAC address in BootP. Double click the MAC address and enter the desired IP address. (It may be a good idea first to try and ping the IP address to confirm that no other devices are already using the IP address.)
   
3. Now, right-click on the device and select Disable BootP/DHCP. If this does not work you may have to open RSLinx Classic and choose Disable DHCP on the drive.
   

Setting the IP Address on the Drive’s Faceplate

You can also set the IP address of a drive using the keypad. This process is useful if DHCP mode is disabled, and you don’t know the drive’s IP address, or you are having trouble connecting to the drive over the network due to an IP conflict or similar problem.

Note: these parameter numbers are for PowerFlex 520s (523, 525, 527) drives and may differ for other PowerFlex drives. Check your drive’s manual for parameter numbers.

1. Starting on the main speed display on the drive press enter, and then press up until you see the letter C followed by a three-digit number.
2. Press enter as well as 'up and down' until you arrive at C128, and press enter again. (C stands for communications, and 128 is the start of the IP address configuration we need to set to configure the drive for Ethernet IP communication)
   
3. By default, C128 is set to 2, which enables DHCP and disables Ethernet IP, press down to set C128 to 1 and then enter and escape.
4. Now set C129 to the first octet of the desired IP address and C130-C132 to the second, third and fourth octet. For example, 192.168.1.55
   
5. Set C133-C136 with the desired subnet mask, typically 255.255.255.0.
6. Set C137-C140 with the default gateway, typically whatever the IP address was with the last octet replaced with 1.
7. Now power cycle the drive and check that the IP address is accessible. (The easiest way to open the command line and type “ping xxx.xxx.xxx.xxx”, substituting in the drives IP address.)

Configuring Drive Parameters from Logix Designer

Drive parameters are stored in both the VFD and Logix Designer and can be changed directly on the drive or through Logix Designer. This makes it quick and easy to upload or download parameters between drives. The one exception to this is that there must first be a known ethernet IP address for the drive before Logix Designer can connect to the drive.

1. To add a VFD drive to Logix Designer, under I/O Configuration right click your network interface and select add module, then find the catalog number matching your drive and double click it.
   
2. Now enter the drives name, IP address, rating, and other parameters. Click 'Ok.' The drive should be added to the I/O Configuration.
3. Under I/O Configuration, double click on the drive and select parameters. Here you can enter all the motor and drive parameters including motor speed, current, voltage, fault signaling, and control.
4. Once all the parameters are correct, click on connect in the top right corner and hit download. This will download the project parameters onto the drive. (If prompted select the drive from the list of devices.)
   

PowerFlex VFDs are very capable drives that with a little know-how can quickly be set up and commissioned. I hope this information helps you understand the process of commissioning a PowerFlex drive and some of the options for the setup that PowerFlex drives offer.

Learn more about DMC's Allen Bradley PLC Programming services and contact us to get started on your next project.

The post How to Commission an Allen Bradley PowerFlex VFD appeared first on DMC, Inc..

Organizing HMI objects into faceplates simplifies and organizes the process but doesn’t help reduce the amount of PLC side logic or tag connections needed, for complex animations. This situation led me to use one of TIA Portal’s most powerful features, scripts, to take faceplates one step further and create a faceplate that can dynamically relink tags to HMI objects.

Why Faceplates?

First, allow me to describe the situation that led to the need for a completely dynamic faceplate. A client gave DMC a project that needed an HMI interface that allowed operators to add, remove and edit steps in a user-defined sequence. Each step in the sequence had a type and several Boolean, integer, and floating-point values that the operator alters to change setpoints for that step. Because only some of the settings were used in each step type, and there were a lot of settings, we decided that it would be simplest if the HMI displayed only the parameters relevant to the selected step type.

The solution was to create a faceplate that interpreted a step’s mode dynamically, thus reducing the need for PLC side logic and linking countless individual tags to the ten steps we displayed on the screen.

HMI Structure

At a high level, think of the dynamic faceplate as a junction box that connects the HMI objects to different PLC tags, depending on the step type. The faceplate contains 21 objects, seven switches, seven drop-down menus, and seven IO fields, that are all linked to tags internal to the faceplate. The faceplate also has 15 interface connections, four Boolean, three Integer and eight Real, that can connect to PLC tags.

When the faceplate receives a new mode, it pulls the values from the PLC tags and places those values in the corresponding HMI objects. When the value in an HMI object is changed, the faceplate pushes that value to the PLC’s corresponding tag.

The step type is a 32bit integer (it uses the lower 28 bits) that the faceplate interprets as seven, four bit, nibs. Each nib contains a number from 0-15 that corresponds to either a blank space or one of the 15 interface connections.

So, for each zero the face plate receives it will display a blank space, and each number greater than zero it will display an HMI object corresponding that interface’s data type, IO fields for reals, dropdowns for integers, and switches for Booleans.

The abbreviated code snippet below controls the visibility of the screen objects and passes the data from the screen object to the connection tag.

Sub SortField7()

Dim place 
place = SmartTags("diPlace8")
Dim bVBSwitch, bSwitch, bVBTitle, sTitle
Dim bVBDropDown, iDropDown, bVBIOField, rIOField

Select Case place: ' Switch1, DropDown1, IOField1
	Case 1:	'Bool 1
		bVBSwitch = 1 								'Show Switch 1
		bSwitch = SmartTags("Properties\bBool1")		'Move Switch 1 to Bool 1
		bVBTitle = 1									'Show Title 1
		sTitle = SmartTags("Properties\sBoolTitle1")	'Move Bool Title 1 to Title 1
		
	Case 2: 'Bool 2
		bVBSwitch = 1 
		bSwitch = SmartTags("Properties\bBool2") 		'Move Switch 1 to Bool 2
		bVBTitle = 1									'Show Title 1
		sTitle = SmartTags("Properties\sBoolTitle2")	'Move Bool Title 2 to Title 1
		
	'case3-4 Bool
		
	Case 5: 'Int 1
		bVBDropDown = 1
		iDropDown = SmartTags("Properties\iInt1")			' Move DrowDown 1 to Int 1
		bVBTitle = 1										'Show Title 1
		sTitle = SmartTags("Properties\sDropDownTitle1")	'Move Int Title 1 to Title 1
		
	'case6-7 Int
		
	Case 8: 'Real 1
		bVBIOField = 1
		rIOField =  SmartTags("Properties\rReal1")		' Move IOField 1 to Real 1
		bVBTitle = 1										'Show Title 1
		sTitle = SmartTags("Properties\sIOFieldTitle1")	'Move Real Title 1 to Title 1
		
	'case9-11 Real

End Select

SmartTags("bVBSwitch7") = CBool(bVBSwitch)
SmartTags("bSwitch7") = CBool(bSwitch)
SmartTags("bVBDropDown7") = CBool(bVBDropDown)
SmartTags("iDropDown7") = CInt(iDropDown)
SmartTags("bVBIOField7") = CBool(bVBIOField)
SmartTags("rIOfield7") = CDbl(rIOField)
SmartTags("bVBTitle7") = CBool(bVBTitle)
SmartTags("sTitle7") = CStr(sTitle)

End Sub

Sub SortField7()

Dim place 
place = SmartTags("diPlace8")
Dim bVBSwitch, bSwitch, bVBTitle, sTitle
Dim bVBDropDown, iDropDown, bVBIOField, rIOField

Select Case place: ' Switch1, DropDown1, IOField1
	Case 1:	'Bool 1
		bVBSwitch = 1 								'Show Switch 1
		bSwitch = SmartTags("Properties\bBool1")		'Move Switch 1 to Bool 1
		bVBTitle = 1									'Show Title 1
		sTitle = SmartTags("Properties\sBoolTitle1")	'Move Bool Title 1 to Title 1
		
	Case 2: 'Bool 2
		bVBSwitch = 1 
		bSwitch = SmartTags("Properties\bBool2") 		'Move Switch 1 to Bool 2
		bVBTitle = 1									'Show Title 1
		sTitle = SmartTags("Properties\sBoolTitle2")	'Move Bool Title 2 to Title 1
		
	'case3-4 Bool
		
	Case 5: 'Int 1
		bVBDropDown = 1
		iDropDown = SmartTags("Properties\iInt1")			' Move DrowDown 1 to Int 1
		bVBTitle = 1										'Show Title 1
		sTitle = SmartTags("Properties\sDropDownTitle1")	'Move Int Title 1 to Title 1
		
	'case6-7 Int
		
	Case 8: 'Real 1
		bVBIOField = 1
		rIOField =  SmartTags("Properties\rReal1")		' Move IOField 1 to Real 1
		bVBTitle = 1										'Show Title 1
		sTitle = SmartTags("Properties\sIOFieldTitle1")	'Move Real Title 1 to Title 1
		
	'case9-11 Real

End Select

SmartTags("bVBSwitch7") = CBool(bVBSwitch)
SmartTags("bSwitch7") = CBool(bSwitch)
SmartTags("bVBDropDown7") = CBool(bVBDropDown)
SmartTags("iDropDown7") = CInt(iDropDown)
SmartTags("bVBIOField7") = CBool(bVBIOField)
SmartTags("rIOfield7") = CDbl(rIOField)
SmartTags("bVBTitle7") = CBool(bVBTitle)
SmartTags("sTitle7") = CStr(sTitle)

End Sub

Visual Basic Scripts

The faceplate uses two event-driven Visual Basic scripts. The first script, shown above, runs when the current step type changes and the second script runs when any of the HMI objects values’ change. It’s important to note that the drop-down used to store the step type must be tied to a tag in the faceplate, not the interface tag tied to the PLC’s tag. If it’s tied to an interface tag, and the Visual Basic script uses the interface tag, then when a change event runs the script, the connection tag will have the old value from before the change.

The key is to tie the HMI object’s Process Value to an interface tag for connection to the PLC as well as to a tag in the faceplate for uses in the faceplate.

As mentioned, the first Visual Basic script runs when the step types’ tag changes. It masks and shifts each nib to the left giving seven location modes each ranging from 0 to 15. Each location value is then passed into a switch case structure that hides the unused HMI objects, shows the used object (assuming there is one) and moves the current interface value into the HMI object’s process value.

The second Visual Basic script, run when any of the HMI objects’ tags change, move the HMI objects’ process values into the interface tags, updating the PLC tags.

Uses

Because each of the seven locations on the HMI can be linked to any one of 15 different tags or left blank, there are a lot of possible modes, 268,435,456 in fact. Finding the desired modes and copying those into a project is not a trivial task.

To simplify the process, I generated a spreadsheet, seen below, that can convert layouts into and back from step type numbers. To create a list of step types you have to fill in each row with the tags you want to appear on the HMI, and then copy the list of types and names into an HMI text list.

Conclusion

This dynamic faceplate demonstrates how using Visual Basic scripts within faceplates can further increase faceplates versatility and capability, reducing project-specific complexity and needed PLC logic. With this tutorial, you should have all the ideas and information you need to make your own dynamically linked faceplate for specific or general applications speeding up complex HMI development.

Contact DMC for more information on our Siemens TIA Portal Expertise.

Learn more about our HMI & SCADA Services.

The post How to Make a Dynamically Linking Faceplate in Siemens’ TIA Portal appeared first on DMC, Inc..

In this post, I’ll detail some of the pros and cons, as well as the typical applications of Arduino microcontrollers, PLCs and custom embedded projects.

What’s the Difference?

Arduino is a common brand of microcontroller with built-in digital and analog, inputs and outputs. Their specific performance, memory, and input/output (IO) capabilities vary from model to model, making it easy to switch from one to another as changes are needed.

The tremendous number of tutorials for Arduino platforms also make them a great choice for learning programming and quickly prototyping early design. For this reason, Arduino’s an excellent choice for rapid prototyping and small-scale hobby projects.

PLC stands for Programmable Logic Controller. PLC manufacturers include Siemens, Allen-Bradley, Honeywell, Omron, Beckhoff, and countless others. Like Arduino, the performance memory and IO capabilities all vary from model to model, but, unlike Arduinos, most PLCs have little to no built-in IO.

Instead, most PLCs use IO cards that add digital and analog, inputs and outputs. These features contribute to PLCs for being known as more rugged then Arduinos since individual parts can be replaced as they wear out or are damaged. In general, PLCs are the solution of choice for rugged environments like factories, where reliability is paramount.

Custom hardware solutions, often called embedded solutions, is a generic name given to custom hardware and software designs made for specific applications. As a whole, it’s the most versatile of the three groups presented here, but individually each solution is typically tailored to do only one particular task. Because the processor(s), and hardware are largely designed specifically for the project the performance, memory, and IO can all be adjusted independently to suit the project’s needs.

Why are these Devices Used?

Arduino provides a free IDE (Integrated Develop Environment), that uses a slight variation of the common C programming language, making it a good starting point for new and experienced programmers alike. Most Arduino hardware is based on TTL (Transistor-Transistor Logic), with voltages of 5V or less (relative to ground), and current sourcing and sinking abilities of a few hundred milliamps total. This makes Arduinos well suited for battery or low power applications, although it limits their ability to control relays, motors, and solenoids.

Below is an example of a text based language used by Arduinos and most embedded projects. 

void ShowSplashScreen(){
  display.clearDisplay();   // clears the screen and buffer
  display.setTextSize(2);
  display.setTextWrap(true);
  display.setTextColor(WHITE);
  display.setCursor(15,5);
  DisplayString("DMC inc.", 8);
  display.setCursor(4,23);
  DisplayString("Do-Dad Box", 10);
  display.setTextSize(1);
  display.setCursor(19,43);
  DisplayString("(303) 223-1801", 14);
  display.display();
}

void ShowSplashScreen(){
  display.clearDisplay();   // clears the screen and buffer
  display.setTextSize(2);
  display.setTextWrap(true);
  display.setTextColor(WHITE);
  display.setCursor(15,5);
  DisplayString("DMC inc.", 8);
  display.setCursor(4,23);
  DisplayString("Do-Dad Box", 10);
  display.setTextSize(1);
  display.setCursor(19,43);
  DisplayString("(303) 223-1801", 14);
  display.display();
}

Below is an example of Ladder Logic used by most PLCs. 

Arduinos vs. PLCs

The most striking difference between Arduinos and PLCs is the size. PLCs have been ruggedized to work in industrial environments to work at higher voltages (typically 12V-24V) and use differential voltages to reduce noise and interference on communication lines. The output cards also have the capability of sourcing or sinking multiple amps, specifically for relays.

Most PLC applications are expected to work for years if not decades without interruption, and for the most part, they do. Programming PLCs is mostly done in Ladder Logic, an easy to read and modifiable language based off relay wiring. Combined with the visualization tools most modern IDEs have, it’s relatively easy to identify and fix faulty wires, sensors, and actuators.

While Arduinos and PLCs are prebuilt controllers, with pre-selected processors and IO capabilities, embedded projects have a near limitless variety of processor, IO, and hardware. This variety makes custom embedded projects the solution of choice for large volume or consumer goods, where even small savings on part costs can quickly add up to significant overall savings. The downside to embedded programming is the longer development time. Every aspect that is designed custom takes time and upfront cost.

Whether you’re using an Arduino, a PLC, or designing everything from scratch, it’s important to know your tools and be able to select the best tool for the job.

DMC provides solutions for all three of these controls. Contact us today to learn about how we can help you with your automation and control project. 

Learn more about DMC’s Manufacturing Automation and Intelligence Services.

Learn more about DMC’s Embedded Development and Embedded Programming Services.

The post Automation with an Arduino, PLC, or Custom Embedded Controls? appeared first on DMC, Inc..

For those looking to revert projects from V15 to V14, this post will outline the process of using TIA Portal Openness to automatically revert a project from TIA Portal V15 to V14 SP1 (note that due to large changes in the XML format, this will not work for versions earlier than V14 SP1).

Overview:

Many parts of TIA Portal projects, like PLC/HMI tags and HMI alarms, can already be exported and imported as .xlsx files between TIA Portal versions, but some parts, like ladder logic and HMI screens can’t be easily exported and reimported to older versions. It’s possible to export these as a source, assuming the code can be first converted into structured text language (STL).

This process is time-consuming and incomplete since it misses much if the block’s metadata and some blocks can’t automatically convert into STL. Openness, and specifically this post, are geared towards saving time and effort by exporting and importing:

• Screens
• Screens with faceplates
• Program blocks
• Program blocks with arrays of data blocks

TIA Portal Openness can import and export more than this, but these items cover most of what you would otherwise have to recreate manually, and some of the special cases you are likely to run into.

Exporting:

1. Download TiaPortalOpennessDemo Version 15 and 14 SP1
2. Create a new V14 SP1 project with the same hardware and device configuration as your V15 project, in TIA Portal V14 SP1
3. Start Openness V15 by navigating to the.exe file inside TiaPortalOpennessDemo_V15\TiaPortalOpennessDemo\bin\Release
4. Use Openness to open your V15 Project – this will require a working version of TIA Portal V15
5. Select what device or devices you want to export and click ‘export.’ By default, this will export all the code on that device as .xml files into c:\Temp

These .xml files contain all the information from your TIA Portal blocks and screens as structured XML code. Before we can re-import these into V14 SP1, we have to change a few parameters. I like to use Notepad++ since it can find and replace in any number of files in one shot, but you can use any text editor to make these changes.

• Replace all V15 with V14 SP1
• Replace all FlgNet/V2 with FlgNet/V1
• Replace all SW/Interface/V3 with SW/Interface/V2
• Remove all <SetENOAutomatically>False</SetENOAutomatically>
• Remove all AccessModifier=”Array”

Importing (Program Blocks and Screens):

1. Start Openness V14 SP1 by navigating to the.exe file inside TiaPortalOpennessDemo_V14SP1\TiaPortalOpennessDemo\bin\Release
2. Uses Openness to open your V14 SP1 project – this will require a working version of TIA Portal V14 SP1
3. Select a destination such as; Program blocks, PLC tags, PLC data types, screens, templates, HMI tags, etc.
4. Click import and select your .xml files with the corresponding code

Now you can save the project and close Openness.

Screens with Faceplates and
Program Blocks with Arrays of Data Blocks:

Importing a screen with a faceplate that is not already in the project library will crash Openness and TIA Portal without any error message. However, it’s still possible to import these screens. To import screens with faceplates, first import, or recreate, a matching project library and make sure that the library file structure and versioning exactly match the structure and versioning of the original library. Then import the screens one at a time saving in between each import in case any library differences persist.

Similarly, importing program blocks with arrays of data blocks will throw an error due to differences in formatting and syntax in the interaction of XML and TIA Portal. Working around this error is more difficult and time-consuming. We found the quickest solution was to replace the arrayed data block references in the .xml file with a placeholder string and then manually reenter the arrayed data block’s references in TIA Portal. This method does require a solid understanding of both .xml and regular expression to find and then replace all the arrayed data block references but can be made to work in most situations.

  <Part Name="TON" Version="1.0" UId="44">
      <Instance Scope="GlobalVariable" UId="45">
        <Component Name="AlarmTimers" />
        <Component Name="Timer" >
          <Access Scope="LiteralConstant">
            <Constant>
              <ConstantType>DInt</ConstantType>
              <ConstantValue>252</ConstantValue>
            </Constant>
          </Access>
        </Component>
      </Instance>
      <TemplateValue Name="time_type" Type="Type">Time</TemplateValue>
    </Part>

    <Part Name="TON" Version="1.0" UId="44">
      <Instance Scope="GlobalVariable" UId="45">
        <Component Name="AlarmTimers" />
      </Instance>
      <TemplateValue Name="time_type" Type="Type">Time</TemplateValue>
    </Part> 

  <Part Name="TON" Version="1.0" UId="44">
      <Instance Scope="GlobalVariable" UId="45">
        <Component Name="AlarmTimers" />
        <Component Name="Timer" >
          <Access Scope="LiteralConstant">
            <Constant>
              <ConstantType>DInt</ConstantType>
              <ConstantValue>252</ConstantValue>
            </Constant>
          </Access>
        </Component>
      </Instance>
      <TemplateValue Name="time_type" Type="Type">Time</TemplateValue>
    </Part>

    <Part Name="TON" Version="1.0" UId="44">
      <Instance Scope="GlobalVariable" UId="45">
        <Component Name="AlarmTimers" />
      </Instance>
      <TemplateValue Name="time_type" Type="Type">Time</TemplateValue>
    </Part> 

Conclusion:

TIA Portal Openness is a great tool for reverting projects from TIA Portal V15 to V14 SP1 and has the potential to save a great deal of time for projects that require reverting versions. Openness adds beneficial and timesaving functions to TIA Portal’s already impressive version updating abilities.  It’s not flawless and it can’t automatically import and export every code, but in combination with the import and export functionality native to TIA Portal, it can make reverting versions a breeze.

Learn more about DMC’s Siemens’s expertise.

The post Downgrading Siemens PLC Projects From V15 to V14 SP1 appeared first on DMC, Inc..