Some of the guys at the office just got back from a SoMachine Motion CODESYS session in Germany. One of them noted a CODESYS tip/trick to change the variable name prefixes or suffixes that will save programmers a lot of time and tedious work.
Holding down the Alt key allows for a vertical highlighting feature.
Highlighting multiple variables vertically
From the example above:
Changing the word ‘Read’ to ‘Write’ can be done in one quick update for the entire list:
Type out replacement for highlighted variable
This is useful for common parts of a variable name, like above. Other examples may include:
Change user defined data type names on a set of assignments.
Adding a prefix to a mirror set of variables- e.g. SCA to variables shared with a SCADA system.
Look out for:
‘Copy and paste’ ( Ctrl-C, Ctrl-V) is a large source of PLC program bugs and errors. Severalarticles on programming cover the ‘copy and paste’ issues in depth. A cool feature like this Alt-key highlighting might feed the problem.
As such, practice caution. Saving a few minutes in tedious work is good as long as it doesn’t cause hours of troubleshooting later. Follow through with a visual check to pick up errors. Copy and paste does not negate the need for System 2 thinking which is the conscious and logical thinking instead of the subconscious and automatic thinking.
Having said that, this is one CODESYS trick I wished I had learnt a few years ago. Thank you, Jared.
The industrial automation world is increasingly connected. One of the projects this week involved a remote desktop session with a customer in the Midwest , from my NC location. The two of us were trying to log in to a PLC located in Alabama through a cloud based service. This is when I realized the utility of the multi IP setting on gateway devices.
An increasing number of PLC, drives and HMI’s include Ethernet based protocols as standard. Many also allow program updates via the ethernet connection. This makes it easier to implement remote access solutions for troubleshooting and maintenance purposes. Set up the IP addresses for the control devices, use a gateway device from eWon, InHand Networks or Netbiter and you’re ready to go.
The Reason for Multiple IP Subnets on the Remote Network
Our PLC on this project was a Modicon M251. On this setup, for various reasons, the PLC program download for the M251 had to be through the Ethernet 1 port( M251 has two separate Ethernet networks embedded). The field devices connected to it ( drives, HMI) were on Ethernet 2. The customer wanted to retain access to the webservers of the field devices when they connected remotely. Occasionally they also needed to log in to the PLC and update the program.
So, in short, we had to connect to Ethernet 1 of the PLC but the gateway device had its IP settings set to the Ethernet 2 port.
To illustrate the setup:
Drives, HMI and PLC Ethernet network 2 located on the 192.168.3.xx subnet
PLC program download port on Ethernet network 1 located on 192.168.4.xx subnet
Two ethernet networks and a cellular gateway. PLC program was to be updated remotely via the cellular gateway device.
Multi IP setting on IG601
This is where the InHand IG601 multiple IP LAN could be useful. Typically, the gateway device would need to set to the same IP subnet as the PLC, HMI or remote network. When there are multiple subnets in the remote network then the gateway device would have to be changed to access each of the subnets. The IG601 solves this as it can be set up with multiple IP addresses. Both M251 ethernet networks were set up with the corresponding gateway IP address on the IG601 as the gateway address:
Ethernet 1 at 192.168.4.3 was set up to look at 192.168.4.1 which was set up as one of the IP’s on the IG601.
Ethernet 2 at 192.168.3.3 was set up to look at 192.168.3.1 which was set up as the other IP on the IG601.
In the IG601 configuration, the multi-IP setting is easily setup in the Network>LAN settings.
Multi-IP setting page on the InHand IG601
The multi-IP feature was tested on my test setup and worked well.
Items to look out for during the M251/SoMachine and InHand IG601 setup
1. If the M251 IP address is altered, it may take a power cycle for it to take effect. If possible, set this up and test it before shipping the PLC or while onsite with it.
2. The gateway IP address needs to be set up on the M251 for both ports- Ethernet 2 and Ethernet 2. On this note, try to set and follow rules of setting the gateway IP address on your remote systems. Example : use xxx.xxx.xxx.1 for the gateway IP …etc.
Gateway addresses are set for both networks.
3. The setup of the IG601 was covered in a previous postabout connecting to a Modicon M241. Having done this twice before, I still slipped up with one setting on the IG601. That is to set the cellular Access Number to *99***1# instead of leaving it blank. Not sure what this means but the system registered on the AT&T network after that setting was made.
Remember to enter the access number as shown. It made a difference on my setup.
Hope this helps save a controls engineer some energy and potentially hours/days of travel time just to perform a PLC program update or some troubleshooting. Thank you to the folks at InHand Network for their guidance on this back when I first set it up.
Amazingly, I went through this post without saying IoT or IIoT once. 🙂
Drop a line in the comments section below with questions or comments on this setup.
There are many ways to implement variable declaration in CODESYS. It can be easy to forget the syntax or specifics on some of them. This post covers them for reference. Also, a couple of programmer cautionary comics from XKCD at the bottom… 😀
Variable Declarations:
VarName : INT ;
Variable with located memory address
VarName AT % MW123: INT;
Variables with Initial Value:
VarName : INT := 23;
Variable initial values can be tied to another variable of the same data type:
VarName: INT:= VarName2;
where:
VarName2:= INT;
Declaring STRING with defined length:
VarName2 :STRING(40);
With the above, a string of 40 characters is created. Each character is one byte.
Declaring STRING with initial assignment:
VarName :STRING:= ‘HELLO WORLD’;
Declaring Arrays with Initial Value:
Array1: ARRAY[1..5] OF INT := [1,2,3,4,5];
Without initial value it would just be:
Array1: ARRAY[1..5] OF INT;
Some other notes about arrays:
The first element can be element zero, i.e.
Array1: ARRAY[0..5] OF INT;
Multi-dimensional Arrays:
Array1: ARRAY[0..5,0..2] OF INT;
Array1: ARRAY[0..5,0..2,0..4] OF INT;
Declaring Pointers:
PointerToStrArray : POINTER TO STRING ( 9 );
Declaring Pointers to Arrays:
PointerToStrArray : POINTER TO ARRAY[1..10] OF STRING ( 9 );
In both the pointer examples above, the pointer values can be loaded with the ADR function. More on that here.
Declaring Function Blocks with Inputs:
Declaring an OFF delay timer from the Standard library with an initialized preset time
OffDelayTimer: TOF:= (PT:=T#2S);
The above declaration method can also be used with the preset time tied to another variable of type time:
OffDelayTimer: TOF:= (PT: = PresetTime);
where the PresetTime is declared as follows:
PresetTime: TIME := T#2s;
One of the positive points of a textual variable declaration area is the option to copy and paste. In some programming environments, the alternate to a textual declaration is a tabular or table based variable declaration area. Some table based ( or tabular) variable areas might include a pull-down menu of options for each declaration. This may help someone who is beginning to learn in an environment.
Nevertheless, in the long term, textual declarations are more flexible. Another benefit is opens up the option to generate the variable declaration externally- in Excel for example. The external declaration is useful for larger projects with multiple programmers. In Excel, a name can be created and multiple versions of a variable generated with prefixes or suffixes to that name. One example may be:
For a variable called SysRun:
The local variable could be SysRun_Local
The status to be fed to a SCADA system could be SysRun_SCADA
Instead of typing out: SysRun_Local: BOOL; and SysRun_SCADA: BOOL; , the entire declaration process can be automated in Excel and then copied and pasted into CODESYS.
To wrap up for now..
Comments in variable declaration field are important. It helps the next person who reads the code/program. It might even help you make sense of your work, in the future. Also, for function blocks, the comments on the same line as a variable become the description of input pins when the cursor hovers over a pin.
Include comments with variable declarations.Comments help refresh your memory or serve as a guide for the next user.
There are probably other useful points and methods of variable declarations in CODESYS that are not included here. If one comes mind, please comment below.
This is part 3 of the PLC programming quickstart. The checklist continues with items 5 and 6. This part will cover PLC programming tools in the development environments . To recap the items covered in the previous two parts.
I/O Declaration: Find the methods and location of I/O declaration for the PLC program.
PLC Logic: Check on the location of program organization units (POU’s) . Check on applicability of programs, functions and function blocks.
Task Configuration:Are the POU’s to be executed organized by task. If so, check on the location functionality of the task manager.
This part will cover 2 more items. Step 5 is to explore the general environment and program language editors. Step 6 is the function in the environment.
5. Environment, Editors, Toolbars
There is often more than one way to do things in the programming environment. Get to know the locations and options of the tools and editor specific functions.
A good starting point is usually the toolbox and toolbars. In SoMachine and CCW, selecting View in the menu bar at the top yields a selection of toolbars and functions available in the environment.
The toolbox
In SoMachine and CCW, the toolbox shows up on the right side of the screen.
The toolbox objects and functions in SoMachine for ladder
The other option for adding objects into a program is using the object icons in the toolbar at the top, below the menus.
Objects at the top
Another place to check is the contextual options available when using the right click button. For example, in the ladder environment, right clicking in a rung ( or network as it is referred to in IEC terminology) brings up the objects that can be added.
Right click in the ladder editor brings up objects that can be added
This also applies to other parts of the environment. For example, right clicking in the device directory brings up items that can be added in a specific context.
Right click in the Ethernet network setting brings up the option to add a device
This shows us there are often multiple ways to accomplish the same outcome. An coil can be added by dragging and dropping it from the toolbox. A coil can be added by right clicking on the rung/network. A coil can be added from the menu bar at the top.
The right click also pulls up some contextual options in the CCW environment.
Adding functions and objects in CCW by using a right click and the selector.
Adding a new program with a right click
Find the way that you feel most comfortable using. There is no right and wrong to it.
6. Functions and libraries
Any task becomes harder without the right tools. For a long time, I was re-creating a periodic ON-OFF function using two timers until I discovered a function called BLINK in CODESYS. The same applied to a simple scaling function block. I later found one already built into SoMachine. The moral of the story is to figure out what is available in the environment early. It will save time and effort. It will reduce the amount of code that gets written.
There are a set of functions that are used in most PLC programs. These include timers, triggers and PID function blocks. Knowing where these functions are and how they are used is next on this checklist.
To find the basic functions:
check toolbox from previous step.
if there is a library manager, check the libraries
review the help files
For instance, in SoMachine, the Util and Toolbox libraries are worth a review. They contain functions to simplify programming..scaling, limit checking, PID,…
They are located in the Library Manager.
Library Manager – Util library functions
Final point about familiarizing with a PLC environment, browse through the help files. There may be details about implementing different functions. The structure of the help files in SoMachine and CCW includes a content list and a search function. Browse through the content list. If anything, this may show you the functions and terminology in the environment.
In summary, the tools and functions in a PLC programming environment will make or break the programming experience. Some key steps on getting up to speed:
Familiarize yourself and explore the environment prior to starting a project.
Exploration will include clicking (including right clicks : 0) through all the functions, object and menus on-screen.
Browse through the functions libraries and toolboxes.
Browse through the help files.
If a question comes up while doing the above, note it down. Check with the vendor or refer to any example projects that may be available.
The PLC programming quickstart checklist is intended for a user to learn a new PLC programming environment. This applies to users who have programmed PLC’s before and also for someone new to PLC’s. Continuing from part 1 with checklist item 3:
3. Program logic
This is where the code is going to be.
IEC 61131-3 is the reference standard for PLC programming languages. In 2016, all major PLC platforms have some level of compliance to this standard. The standard does allow for partial compliance and requires manufacturers to declare specfics of their compliance with a statement. A quick introduction to the standard is available at the PLCopen site.
Per the standard, logic can be written as one of the following 3 types of program organization units (POU’s):
Programs
Functions
Function Blocks
PLCopen covers an overview of these types in a presentation here.
Adding these POU’s to the program usually occurs on the left side of the screen. There are some differences on how this is done in various environments.
In SoMachine which uses CODESYS V3, a POU is added by right clicking the Application directory and selecting Add Object>> POU. Subsequently, the option to add a Program, Function or Function Block pops up.
Adding a POU in SoMachinePOU options in SoMachine
The POU types and options do vary in terminology and operation from platform to platform. In CCW, the Programs are added under the Program directory header. Function blocks are added under a separate header called User Defined Function Blocks.
Adding a Function Block in CCW.
When adding a program, the user is usually prompted to define the language chosen for that POU. When playing with a new environment, here is where you will find out the languages supported ( other than in the literature).
It would be advisable to select the different languages and test drive them. At the very least, select the language you will use and play around with the development environment. A later part will cover the specific items to look for in the language chosen.
Some questions to ask, that does vary from platform to platform is:
Can a program call another program?
When a function block is updated, does it automatically update every instance?
Can program execution order be arranged?
The final question takes us to checklist item 4…
4. Task Configuration
The importance of a ‘task’ is that it gives the PLC programmer control over what parts of the code to run and when. Task configuration covers the order , timing and triggers of execution. For example,
A cyclic task may be configured to execute every 20ms.
An acyclic, freewheeling task may be set to occur per the processor execution cycle for the POU as defined.
An event triggered task may run only when an input is triggered.
If a part of the code needs to have a higher priority over other parts, it may be defined in a task of its own. It could also be set to execute with a shorter cycle time, if required.
SoMachine tasks are configured under the Task Configuration header. Multiple tasks can be defined with the number varying based on the specific PLC used. CCW does not have a specific task configuration section. Programs noted in programs section are executed in order. The order can be changed, as required. CCW does have an interrupt option that can be used to trigger specific logic as required.
Key takeaway here is to note the differences in the number of tasks and sequencing options for programs/POU’s in various environments.
Most control engineers and PLC users are going to encounter several PLC platforms over a career span. Whether through jobs at different companies or through migration of control platforms, the need to adapt and learn new programming environment is an essential part of the job. As I go through this process with a new platform, the following checklist was developed as a ‘quickstart guide’ when programming in a new PLC platform.
The good news is that most PLC programming platforms use a very similar set of features. The features are called using different names by different vendors. In many cases, even the layout of the program is similar. There is usually a directory on the left side of the screen, a message window at the bottom…etc.
So, this post will be Part 1 of a multi-part series about the key things to look out for in a new PLC programming environment. The way this will be set up is as follows:
Several programming platforms will be referenced in examples; SoMachine (CODESYS), SoMachine HVAC and Rockwell CCW. I’m very familiar with SoMachine and CODESYS, new to SoMachine HVAC and never used Rockwell Automation’s CCW before.
The intent would be to get proficient enough in a new environment to write simple to intermediate programs. We will save more advanced features for another discussion.
I/O Declaration
The basic function of a PLC is to be able to accept inputs and control outputs. In most current PLC programming environments, the inputs and outputs are referred to in the logic using variable/tag names or pre-assigned terminal designations.
If a PLC program is to be looked upon as a story, the main characters would be the variables and the I/O. They are the subject.
So, the key questions when encountered with a new environment is:
Where are input and output variables or tag names assigned?
How are they called in the program- pre-assigned name or user-defined names?
Common approaches:
The I/O tags or their user assigned tag/symbol names are declared in one place and then available to be called throughout the program. They are essentially similar to global variables.
Some of the terms used for these names include symbols (CODESYS), tags (often used in SCADA environments and aliases (alternate references to a I/O point in Rockwell controllers)
In SoMachine the input and output mapping can be addressed using either the address assigned to the terminal input( this is referred to as direct addressing) or a user-defined symbol name.
I/O declaration in SoMachine
In CCW, I/O is addressable in code using either the pre-assigned name or an alias.
I/O Declaration in CCW
Between the pre-assigned name and the user-defined name, both are usable in this case. With the usage of the pre-assigned name in SoMachine, a pop-up usually occurs to advise the user to use symbolic addressing for ease of maintenance and modification.
Variable declaration
Once the I/O is declared and accessible in the program, the next point of interest would be to figure out where and how variables are declared. Some variables can be pre-planned if we know the functions they will be plugged into. Others may be added on the fly.
The two main types of variables are the local and global variables. Local variables can be called from the POU that it is declared in. Global variables are accessible anywhere in the project.
Some environments allow for variables to be declared textually. Others require a tabular declaration with a pull down for the data type. The textual declaration may involve a little more typing, however, the benefit is that it is more flexible and supports copy and pasting variable names. For larger projects, variables can be created in a spreadsheet separately and then pasted into the PLC program project. The benefit of a separate variable creation is that variations of the variable name for SCADA purposes and also the generation of memory locations can be performed easily and quickly in a spreadsheet.
For textual declarations, observe the syntax used for various data types. Some key questions here are:
How are variables given an initial value?
How are persistent or retain variables created ( to keep values through power cycles)?
How are arrays declared?
Regarding the point about retain and persistent variables. In CODESYS, the retain variables holds a value through power cycles. Persistent variables hold a value through program downloads.
In SoMachine, retain variables are declared using the VAR_RETAIN header in the variable declaration section.
Declaring Retain Variables in SoMachine
Variables to be kept through program downloads are declared in a separate object.
Persistent Variables to hold a value through program downloads
Next part will cover the program types or POU’s as referenced by the IEC 61131-3 standard…
So, you’re programing in a PLC platform that is new to you. The functions, tools and syntax may be different from what you are used to. As you get acquainted with them, there are probably going to be errors showing up in the message list when a build or compile is performed. The following are 5 things to do to debug or correct these errors when developing a PLC program.
Checklist item 1: Compile as you go (don’t wait until the end) and check the messages
a. About compiling often: Nobel Prize winner Daniel Kahneman in his book ‘Thinking, Fast and Slow’ states a correlation between the ability to build expertise on a topic and the speed and quality of feedback during the process of learning. The inference of this in building PLC programs, specifically in an environment you are new to, is:
Compile or build the program often
Decipher the compile errors and messages accurately.
Some programs or programming environments are going to take longer to compile so this habit is dependent on the environment too.
b. The second part about deciphering the error message accurately is highly reliant on the environment itself. For instance, I am working in an IEC 61131-3 environment called SoMachine HVAC. The error message said ‘Token not found’ and pointed to an inexistent line number in the POU. After using Step 2 below, it turned out that one of the variables had a period/dot (.) in front of it which is acceptable in the CODESYS environment but not in the new environment. Removed the period/dot and the error message went away.
About checking the messages, observe if there are root cause messages that are effecting other error conditions. In CODESYS for instance, addressing the errors at the top of the error message list often results in the solving of multiple other errors that are lower in the list.
Checklist item 2: Check the help files and any example programs available
Some environments may have a manual. Some may have a good Help section. On either one of those, browse through the contents of the manual and Help files. When a problem arises, it may come in handy.
Another good reference is an example program. Trying to figure out how a read operation is performed over a comms network? Or maybe just the usage of a simple CASE structure sequence? Having one good written up program helps and can serve as a ‘go to’ program. When starting in a new environment, ask the vendor for some example code and programs.
Checklist item 3: Test only the suspect function, in a separate POU.
The idea here is to test the function and its utilization method. If you are using the function wrongly then this step will pick that up. Break the function down to the arguments that are fed to it. Check if any one of the arguments are of incorrect type of using wrong syntax. The ideal case is if the compiler picks up the error and tells you what is wrong but that is not always the case.
Checklist item 4: Comment out sections of the program and check if the errors persists.
As is common in tackling any engineering feat, ‘divide and conquer’. Comment out sections of the code and perform compiles systematically. Start with the section you suspect to be the root cause and then expand from there.
A note about the psychology of debugging; sometimes it is easy to blame the problem on the programming environment or a vendor. You might be telling yourself ‘This programming environment is buggy’ or ‘It’s not user friendly’. Try to quash this, have some faith and be bullish about solving the problem. This has helped me tackle problems much quicker rather than going back and forth with tech support or giving up only to find a simple solution I had overlooked.
Checklist item 5: Build your go to resource list … and Google away
Document your findings somewhere. Preferably somewhere searchable. This step takes time but will save you time later. Also, when someone comes to you for help, you will have something to give them – which helps me since I work for a vendor.
As stated above, collect examples from the vendor. I collect examples from colleagues, previous projects, development team…
Vendors may also have an online FAQ list, forum or wiki page. Get to know those resources.
Another resource maybe online forums like PLCTalk. For CODESYS, check out the CODESYS forum.
Hope this helps as a debug checklist. If there are any other methods out there, please add them to the comments section below. Given the thousands of hours controls engineers and PLC programmers spend debugging, there is probably a part 2 that needs to happen on this topic.
A couple of previous posts covered sorting CODESYS arrays and using them with pointers. There was never a preface to the topic of arrays. So, this is a stab at clarifying the definition and application of CODESYS arrays.
Visual of an Array
What and why of arrays?
An array is an set of data. It could be a collection of numbers or a collection of custom data types. One analogy of arrays is a bucket with numbered containers in it., arranged from container 0 or 1 to container x. X being the length of the array. Each container can store some data.
The purpose:
Collect and organize data of a certain type.
Data in an array can be called with a common namespace.
Makes it easier to sort data
Easier to do math on a set of data points
In the memory layout of a PLC, array elements are usually stored in contiguous ( back-to-back) memory locations. This has some benefits for retrieval when reading from another PLC, HMI or SCADA system.
How are they used?
The basic declaration of an array:
TestArray : ARRAY[1..5] of INT;
It also offers the option of initializing the element values in the declaration:
TestArray : ARRAY[1..5] of INT:= [5,3,2,5,2];
Array lengths can be defined using a variable in the declaration. That is to tie the array size to a variable name instead of a fixed number in the declaration. NOTE: The variable has to be declared as a VAR CONSTANT and can not be altered in runtime. The value of the VAR CONSTANT variable needs to be declared and initialized with a constant value in the programming environment. The IEC 61131-3 standard also makes reference to this point. So, the feature of using a constant in the declaration of array length only serves to centralize the location of initial setup of parameters, if required by the control program.
TestArray : ARRAY[1..UserDefinedVarLength] of INT:= [5,3,2,5,2];
VAR_CONSTANT
UserDefinedVarLength : INT:= 5;
END_VAR
The above as noted in the CODESYS environment:
CODESYS Array declaration in the actual declaration window
CODESYS Arrays can be multi-dimensional. That is, they can have more than one attribute and form a matrix. Multi-dimensional arrays are declared as follows:
An example application with a visual representation of the multi-dimensional array above could be as follows:
An visual representation of the array example above
CODESYS Functions that can be used with Arrays:
There are a number of functions that can be used with arrays. Often times, for organizing and sorting data in arrays, pointers are used. Other than that, the following are some functions and their applications to arrays:
SizeOf
This function returns the number of bytes reserved for an area. If an array is made up of INT datatypes, each element would take up 2 bytes. The total number of bytes would be number of elements times 2. For REAL datatypes it would be a multiplier of 4.
Checking the size of an array in bytes.
CheckBounds
This is added as an implicit check. It shows up as ‘ POU for Implicit Checks’ when Add Object is selected and check arrays during runtime to determine if any code is attempting to access array elements that are outside the declared range.
Implicit Check included in the CODESYS environment for array bounds checking
NOTE: Sum and arithmetic functions ( ADD, MUL, SUB…etc) usually accept INT, REAL’s and ANY_NUM type inputs. As such, feeding an array to the input of a math function will usually result in an error. Arrays have to be broken out to individual elements to be manipulated and used for number crunching.
To wrap up, a video on arrays in CODESYS from Kurt Braun’s YouTube channel
There are probably a number of functions related to arrays that folks out there use. If you know of one, please share in the comments section below.
Resources: Staying on the topics of arrays, the following articles are on the same topic:
The ability to connect to a PLC remotely (or HMI) and to pull data, access webservers and download programs is increasingly a requirement on industrial automation projects. Remote data access and program maintenance saves travel time to sites and simplifies daily operations. Some of the PLC features that enable this are:
Webserver on PLC and HMI: Allows data monitoring and some updates to PLC configurations
WebVisualization: These are customizable user interface pages that are embedded in the PLC. WebVisu is the CODESYS term for these HTML5 pages. Some examples of their usage from YouTube are noted here.
PLC Programming software remote gateway support: This is the ability for a PLC programming software to connect to remote Ethernet based devices. This could be for program downloads or regular program viewing.
This article will cover the steps for remotely connecting from the SoMachine PLC programming software to a remote M241 PLC. The InHand Networks IG601 cellular gateway device is used as the intermediary. Other examples of intermediary gateway devices may include Netbiter by HMS and eWon ( also by HMS now I believe).
Over the last few years, the criteria I have laid out for these devices have included the means to use them without the manufacturer’s cloud- based connection service. Simultaneously, keeping the option to route more secure connections through the cloud service, only when required, is a plus.
The criteria for the gateway device:
Ability to setup port forwarding at the gateway device
Ability to use a VPN connection for secure PLC program downloads
Ability to support a static IP at the gateway device and allow for the above mentioned VPN connection at the same time.
The InHand Networks IG601 meets these criteria. Getting this set up can be accomplished with two sets of steps. The InHand steps and the SoMachine steps.
Install Device Touch on the connecting PC. The installer is available in the Device Cloud portal. The next steps will assume proper setup of the Device Cloud and connection using Device Touch on the local PC. Instructions on Device Touch are available at the following link.
NOTE: While in the Device Cloud, be sure to set up a site, a device and the PLC. I forgot to add the ‘Controller’ once. It took some time and a call to InHand’s support team to figure it out.
InHand Device Cloud
Open Device Touch on your computer and connect with your Device Cloud account. Once connected to the cloud. Connect to the specific site/gateway but selecting it and clicking on the ON/OFF slider bar.
Device Touch connection
SoMachine Steps
In SoMachine, configure connectivity in the SoMachine gateway. The gateway is accessible by double clicking on the root of the controller directory in the device tree.
SoMachine Gateway
5. The connection method is set to IP address. In the example, the remote controller IP address was set to 10.0.0.100 with a subnet mask of 255.255.255.0
IP Address connection mode
6. Per step 3 above, if Device Touch is active and the Maintenance Channel is on/ready (screen cap below), go to the Online menu and select Login.
IP Address Connection Mode
NOTE: The update key on the gateway will not result in the detection of the controller in the Gateway list. Entering the IP address and selecting ‘Login’ actually triggers the process if searching for the device and placing it in the available controllers list in the Gateway. The Update button in the Gateway may not find remote devices. As such, the remote PLC may not show up even if by clicking on the Update button.
The gateway will scan the remote network via the Device Touch adapter. Once the controller has been found, it will show up on the controller list in the gateway with a REM icon next to it.
Remote PLC detected
Note: The standard warning message indicating the pending connection to a controller will pop up prior to an actual login. Entering Alt-F will proceed with the connection and potential remote download of a program. Clicking the Cancel button will abort the connection.
Troubleshooting tip:
Should the remote controller not be detected using the IP address connection method above, restart the SoMachine gateway as shown in the screen cap below. Subsequently repeat step 4 above.
Restart SoMachine Gateway
Should questions or comments arise, put it in the comments section below.
The VFD input rectifier is the first of the three main stages on a VFD. The other two being the DC bus and the inverter. The rectifier stage converts AC line voltage supplied to the drive to DC.
The rectifier is usually a silicon controller rectifier ( SCR) or a diode. The difference between the two being that the SCR types can increase switching gradually thus increasing the voltage applied to charge the DC bus (second stage of the three stages of an AC drive). The diode types rely on a pre-charge circuit to perform the gradual voltage ramp up of the DC bus capacitors.
For drive rectifier stages, most commonly, there is a 6 diode or 6 SCR arrangement that makes up what is called a 6-pulse rectifier. A good illustration of this process from a TranspowerNZ video on YouTube
There are 12 pulse and 18 pulse diode arrangements that can be used to make up the rectifier stage of a drive. The main purpose of the 12 diode and 18 diode arrangements are to achieve lower harmonic distortion on the line side. The 12 pulse would be made up of 2 sets of 6 pulse rectifiers supplying the DC bus in parallel and the 18 pulse with 3 sets of 6 pulse rectifiers. Understandably, the higher order arrangements take up more space and cost more.
Considering that the main purpose of these arrangements is to reduce harmonic distortion, there are other options besides 12 or 18 –pulse rectifiers that can be considered for the same or better results. These options are to include a filter on the line side of the drive or by adding an active front end (AFE). MTE (maker of filter and power quality equipment) has a good paper comparing 18-pulse VFD’s with a 6-pulse VFD and their Matrix filter. The essence of it is that it costs less, takes up less space and consumes less energy (specifically for the 100hp test case).
