PLC programming, CAD drawings, SCADA packages and virtual machines. These are some of the resident software suites on the average automation or control professionals computer today. This post is mainly about the hardware needs to get the job done.

Picking a laptop for automation and control engineers

Based on recent discussions on PLCTalk, the specifications vary based on preference. Some of the common requirements mentioned:

Screen Size:

A 15″ screen laptop is the sweet spot for ease of travel and ease of troubleshooting while onsite. Anything less makes the onsite work, specifically if programming is involved, a little harder. Anything more makes for a bulky laptop to travel with.

Last year, I had two programmers show up in PLC programming classes with Surface Book style tablets. With the i7 processors, the Surface performed well. With the screen size, they struggled in maneuvering through the programming environment. Followed up with one of them this year and they had moved back to a larger screen laptop. PLC Programming with the magnifying tool in Windows is not practical.

Processor

The recommendation is a i7 type processor with 3GHz clock. My current machine has a 2.8GHz spec and has been great. Performance with 2 VM’s , HMI software and PLC software running simultaneously noted on screen cap below.

For the MacBook folks, this article talks a bit more about picking processors.

RAM

The RAM requirements vary. With virtual machines being a common place to house several different control software suites- PLC and SCADA environments, RAM requirements are a minimum of 16GB .

Based on a the Windows performance monitor, having one HMI software, one PLC programming environment and one VM took the memory usage up to about 14GB. Note, this number is based on the allocation on your VM’s. Also, it may vary based on the various software suites.

A PLC programmer laptop option needs to have lots of RAM. I would recommend 32GB.

Hard drive

The SSD seems to be the way to go.  They are generally more shock resistant. Working with PLC’s  often means being onsite at various locations. This may even apply to plant based folks who may have to carry  Also they are quieter.

Requirement would be at least 500GB.

Operating System

Most industrial automation software suites have traditionally been Windows based. Having said that, much feedback I have received regarding MacBook (Pro’s) have been quite positive in terms of performance. That sentiment it shared on this thread.

Mac users may use Boot Camp to get Windows running. Alternatively, many do report using VM’s.

I use Windows 7 Professional. Windows 8 compatibility is common among software suites out there currently.  Some even support Windows 10. Having said that, industrial automation is usually slow to adapt to new OS versions.  Some have reported good results and some report problems. This uncertainty keeps me at Windows 7.

Battery Size:

Hooking up to a power source onsite can sometimes be cumbersome. The tradeoff on some of the more powerful machines has been that the battery drains quickly.  Consensus is that the MacBook Pro runs all day on a single charge. This goes back to the OS discussion above.

My quad core Lenovo W541 holds a charge for about 1.5 hours. I don’t hold the battery requirement to high on my priority list. If you do, check it out while shopping. Be cautious, as the advertised values might not hold true. They are dependent on your performance and usage.

One absolute comparison, is to check the ampere-hours (Ah) ratings among your options.

Connection Ports:

Forget the serial port. Get an adapter.

Get a machine with at least 3 USB ports.

Some other considerations:

Numeric keypad might help for some work functions. If the laptop doesn’t come with one, there are USB connectable options online.

DVD players can be left out as Installers are increasing available in downloadable software packages. If required, a portable DVD player can be used.

Back-lit keyboards may be useful for work in environments that are not well lit. Not a requirement I considered but noted in the thread.

The actual picks:

Lenovo P50

Dell Precision

MacBook Pro

Dell E6440

I’ve used Dell’s, HP’s andLenovo’s in recent years. My pick for stability and performance right now is the Lenovo. It may be biased to the hardware specs on this current unit. The previous units also had good specs for their time.

In all, the package is probably going to be about USD$2000 or higher. Shopped during the Black Friday sale last year and Lenovo had a great deal on the W series. Probably due to that series being phased out. The price was down to $1700-ish for a  32GB RAM, i7, 500GB SSD setup.

The threads discussing the topic on PLCTalk are here and here.

The PLCTalk forum pick of the week this week  is  about Modbus simulator software.

The question

1. What software out there scans Modbus registers from a PC and provides confirmation of a good connection?
2. Do any of the software options scan registers on a slave/node? ( automatic scanning inferred)

In a typical setup, the PLC would be connected to a computer with a USB -RS232 adapter or a USB-RS485 adapter.

4 Modbus Simulation Software options

1. http://www.win-tech.com/html/demos.htm

This site seems to offer Modbus simulator and OPC tools. With the Modbus tool, there is an indication of a succesful connection. There is an evaluation version of the software downloadable. The full version is not free.

2. modbustools.com

There seem to be several Modbus simulators and polling tools  offered here. This software is also not free. There seems to be a trial version that works for 10 minutes at a time for the first 30 days. This software includes options to log data to Excel and  text files. It is unclear if there is confirmation of ‘good connection’ provided per the original question.

There is also an option create a custom frame which might be useful for testing and debugging purposes.

3. https://sourceforge.net/projects/qmodmaster/

This is a free, open -source project built on a framework called qt. New to me, interesting concept.  There is a bus monitor to see live frames. The latest update was in February 2016.  Seems promising mostly 4 and 5 star ratings from its 9 reviews.

4.  http://www.schneider-electric.com/en/faqs/FA180037/

Finally, the software I have used for Modbus TCP testing.  Schneider Electric has a free serial and Modbus TCP tester software. Unlike ModScan and some of the other options out there, this tool doesn’t include a live frame by frame view of communications.

In all cases, the option to automatically scan ‘live/open’ registers on a network didn’t seem to be something common on the market ( keyword:automatic). For Modbus networks with communications already up and running, the best bet would be to use a a communication viewer screen. This would show the frames on the network with addresses, commands and responses.

Link to the actual thread on PLCTalk.

Sorting functions have increasing use in PLC programs thanks to more powerful processors and more memory. One example is sorting an array of motor runtimes from lowest runtime to highest runtime so that the next run cycle will utilize the motor with the lowest runtime first. This example is useful for pump applications and is referred to in the post about pointers in CODESYS.

To implement a pump runtime based sort, other elements in CODESYS such as DUT’s( user defined data types)  and structures could probably be useful. The reason is that the result of the sorting function is to know which pump to run next. This can be done by having two dimensions in the array, a Pump ID/Number along with the Pump Runtime. For the purpose of simplicity, only a simply bubble sort with two FOR loops is shown below, the DUT approach is not shown here.

A simple bubble sort can be implemented in CODESYS with the following code. Instead of sorting the actual array, this example sorts an array of pointers ( dereferenced to get the actual values from the pointers). This way the original array data locations do not need to be altered. Not altering the original array locations is a good thing because in some cases, these array locations may be hardcoded to physical inputs.

(*Prior to implementing the sort, an array if pointers is loaded *)

FOR l:=0 TO n BY 1 DO

pointToArrayElement[l]:=ADR(TestArray[l]);

END_FOR

(*Bubble sort- The value of n should be equivalent to the last array element*)

FOR i:=0 TO n BY 1 DO 

                                                (* The second FOR loop compares two elements of the array at a time and sorts*)

FOR j:=0 TO n-1 BY 1 DO

IF(pointToArrayElement[j]^>pointToArrayElement[j+1]^) THEN

temp := pointToArrayElement[j+1];

pointToArrayElement[j+1] := pointToArrayElement[j];

pointToArrayElement[j] := temp;

END_IF

END_FOR

END_FOR

The variables used in this example:

VAR

TestArray: ARRAY [0..4] OF Pump;
TestArrayPointers: ARRAY [0..4] OF POINTER TO INT;

i: INT;
n: INT;
j: INT;

l: INT;
temp: pointer to INT;
pointToArrayElement: ARRAY OF POINTER TO INT;
END_VAR

Other notables: If this is implemented in a function or even in a program , the integers used in the FOR loop iteration need to be reset after the sorting is complete and it would be required to sequence through the loading of the array of pointers, sorting  and resetting of the iterative integers possibly using a CASE structure  or some IF statements.