New Software Release: Schneider Unity Pro 9 -- I mean 10 -- I mean 11!

January 14, 2016 - Reading time: 3 minutes

I'm Jason Firth.

You will recall that last year I posted about the release of Unity Pro v8.1.

Well, I got an email from a vendor this week about the opportunity to learn about the new version of Unity Pro -- Version 10!

(Wait, did I miss something? What happened to 9?)

I have absolutely no idea what happened to 9. They skipped it. Maybe to keep on track with Windows?

 

Unity Pro V10 supports

M580 features

*CCOTF(Configuration change on the fly) on M580 Local IOs

*Cybersecurity: Events log, Data Integrity, Enable/Disable Services

*System Time Stamping of Application Variables

*Device Integration: Network Manager

Quantum Platform Features

*HART on X80 remote drops

*New Quantum firmware v3.3

Full Excel Import/export tool

Audit Trail

*Log in Syslog

ANY_BOOL Data Type

Supports:

Win 7 32 and 64 bit;

Win 8.1 32 and 64 bit;

Win 10 32 and 64bit and;

Windows Server 2012.

How exciting, right? Well, I went onto the schneider-electric website to download the latest version, and was shocked to discover that version 10 isn't the latest version!

 

Yes, there's a vesion 11, out right before Christmas.

Unity Pro V11 support new Modicon M580 Controllers :

Support new Modicon M580 High End

Support new Modicon M580 HSBY CPUs

Support LL984 language on Modicon M580

Quantum Ethernet IO drops is now supported on Modicon M580

Supports:

Win 7 32 and 64 bit;

Win 8.1 32 and 64 bit;

Win 10 32 and 64bit and;

Windows Server 2012.

 

To be honest, these seem like awfully incremental improvements to be justifying major sofware number increments.

Alongside Unity Pro v10, there are new firmware images for the Modicon Quantum CPUs, and a major revision of the M580 firmware images for all the new features.

Alongside Unity Pro v11, there are new firmware images for the M580 platform.

Thanks for reading!


Modbus Plus communication to your PC without a $2000 USB Dongle

February 20, 2015 - Reading time: 9 minutes

I'm Jason Firth.

A few months back, I had a discussion with someone about how to communicate with a PC over Modbus Plus without breaking the bank. I decided to take the highlights of that conversation and bring them together in a blog post so others might be able to use the information.

Modbus Plus is still a widely used protocol in industry where Schneider Modicon PLCs are in use. However; it's not a cheap protocol to work with. A USB Modbus Plus dongle for your PC will run you over $2000!

That's a lot of money if you just want to look at some bits in the PLC. Today, I want to look at some other options.

Modbus Plus is a completely different protocol than Modbus.

Modbus Plus uses a proprietary signalling standard, where Modbus generally uses RS-232 or RS-485. Modbus Plus supports routing, where Modbus has no networking features. Modbus Plus requires a DSP to handle the communications, where Modbus can use a standard UART. Modbus Plus is peer-to-peer, where Modbus is master/slave. Modbus Plus uses a token passing system to ensure everyone gets a turn on the line, where Modbus doesn't have any mechanisms (hence requiring the master/slave architecture where the master dictates who will speak). You just set your addresses, and all the devices will start talking. The Bridge Multiplexer acts as a gateway between the two protocols.

Modbus Plus allows for routing between devices called Bridge Pluses. The way you do this is by defining the modbus plus address of each bridge plus you pass through. For example, if you have node 1 on a modbus plus network with a bridge plus node 64, and there's a node 32 on the other side you want to communicate with, you'd be communicating with 64.32.0.0.0

So to make sure your modbus devices can talk over a modbus plus network, you need to map the single values to modbus plus addresses.

Modbus plus requires a DSP. This means that no matter what, you're going to need a dedicated piece of hardware to communicate on the network. You can't just slap an RS-232 pigtail together and hope it will work.

Here are two potential options: first, if you get a PC with an ISA slot, the cards are quite inexpensive. I found some on eBay for 100-200 USD. A PICMG backplane can use an ISA slot, and there are industrial main boards still available. The downside to this is that you may be stuck using a very slow PC just to communicate with your one PLC.

Another option is a bridge multiplexer, which converts modbus plus to modbus. It takes a bit to put together, but it should work. I found a bridge MUX on eBay for 100usd when I first investigated this option. Today, I've found them for under $250 on eBay.

The manual really overcomplicates things.

There are models on page 10 of the manual -- nw-bm85-000; NW-bm85C000; and NW-BM85D008 which don't need a special progran. You don't need to make a C++ program. You connect to one of the serial ports (I think the second one) and put the bridge into programming mode by flipping a DIP switch on the back, then it gives you a fairly nice and easy menu based interface to configure what it does.

You'll need to figure out master/slave stuff, because modbus is client/host but modbus plus is peer to peer, but it should be very doable.

The master in a modbus interaction is the device that actually sends the commands. For example, I programmed a modbus TCP library, and in that case, the device that initiates the connection is the master: you connect, then either tell the device you want to read or write a coil or register, then the slave device that you connected to will respond with either a success/fail message for a write, or the data you wanted or an error message.

The Peer-to-peer feature is relevant because it means nothing on the Modbus Plus network is a master or a slave. They'll just take care of communications on their own. In my tests, the only problem I could cause to the modbus plus network is if you set your bridge mux to the same address modbus plus address as something else on the modbus plus network. If you set a wrong modbus setting in the text interface, all you're going to do is not communicate with the Modbus Plus network over the Modbus port.

Here's how I managed to talk to a PLC using my PLC software and a BM85 connected to my serial port.

I set my modbus plus address of the BM85 to 2 by turning the first switch on and the rest off.

I entered config mode using the dip switch on the back

Once the screen loaded, I entered the following commands:

V1

P1

Tm

B9600

S1

Re

Mr

Y1

V2

E1 01 20 00 00 00 00

V4

W

Press y to confirm

Turn off bm85 and return config mode to run mode.

One key thing seems to be the rs-232 cable from the PC to the BM85. I used a 990NAA26320 but the wiring diagram should work ok to make a cable similar.

So what you'll have is:

Your PLC, and bm85 daisy chained together on the modbus plus network.

Your PC plugged into the BM85 on modbus port 1.

Your BM85 set to a free Modbus Plus port

Your PLC set to whatever it is (no change)

Your bm85 configured using the keystrokes above, in run mode.

I use Fasttrak softworks, so I open it up and set it up to look at the COM port. Next, I did a PLC connect and did a port scan. I saw the BM85 and the PLC. Next, I chose the PLC from the list and hit connect. I was talking to the PLC!

So what's going on: In this situation, you have two types of communication going on: The Modbus Plus communication, and the Modbus communication. So the PC acts as the master in a modbus communication. It sends commands to the bridge mux. The bridge mux, while configured with the master option, is actually acting as a slave on the modbus port: It is only responding to commands the PC master provides. The BM85 receives the message, and saves it so it can send a corresponding message on the modbus plus network to the PLC.

Now, you have another network, the Modbus Plus network. What's going on there is, each device gets a token which is its turn to speak, and it says what it has to say on the modbus plus network and passes the token to the next device.

If the PLC and the BM85 are all configured, all this is transparent behind the scenes.

So let's talk troubleshooting.

If you seem to have all the right pieces connected in the right way, I'd start from the outside and work my way in.

Can you connect to a PLC using your directly using the serial cable? If so, then you've proven the converter and the cable. I know that those serial converters can be flaky -- If you plug them into different USB ports, they'll use different COM addresses. You can check device manager to make sure you're configured for the COM port you think you're using.

What is your BM85 Modbus Plus LED doing? The following are the flash codes for Modbus Plus:

Six flashes/second Normal operating state. All nodes on a healthy network flash this pattern.

One flash/second The node is off-line. After being in this state for 5 seconds, the node attempts to go to its normal operating state.

Two flashes, then OFF for 2 seconds The node detects the network token being passed among other nodes, but it never receives the token.

Three flashes, then OFF for 1.7 seconds The node does not detect any token passing on the network.

Four flashes, then OFF for 1.4 seconds The node has detected another node using the same address.

If the light is flashing 6 flashes per second, then it suggests that your Modbus Plus network is working correctly.

Thanks for reading!


What's inside a Modbus Plus connector?

February 9, 2015 - Reading time: 5 minutes

I'm Jason Firth.

Eventually, I knew I would be writing at length about Modbus Plus.

Modbus Plus is the protocol that Modicon created to supersede the Modbus protocol. It has some superficial similarities, but it quite different under the hood.

Modbus is a Master/Slave protocol. One device is the master, and tells which Modbus slave to talk. By contrast, Modbus Plus is a peer-to-peer protocol. Each Modbus Plus device can request data from any other device.

Modbus doesn't have any real way to manage congestion, because there should never be congestion. The master requests data, and will not request more data until the first is sent. By contrast, Modbus Plus uses a token passing mechanism, where each node in the network gets a chance to talk, then once it has finished talking it will pass the token to the next node.

Modbus generally relies on RS-232, RS-422, or RS-485 signalling to communicate. By contrast, Modbus Plus uses a proprietary signalling protocol over a single twisted pair of wires. Modbus can be implemented using a standard UART, where Modbus Plus requires a special DSP.

Physically, Modbus Plus is a bus protocol. All devices are electrically connected to every other device on the Modbus Plus network through an electrically continuous shielded twisted pair cable.

Modbus basically doesn't have network capability by itself. However, Modbus Plus has basic networking capability. Using a device called a "Bridge Plus", you can connect different Modbus Plus networks together. The address you use to connect to a device is actually the path of devices you follow to get to the other device. If you were connecting to device 1 on the local Modbus Plus network, then you'd connect to 1.0.0.0.0. If you were connecting through a bridge multiplexer at address 2, then you'd connect to 2.1.0.0.0. If you went a step further and connected to 1 through yet another bridge multiplexer across the network at address 3, then you'd use address 2.3.1.0.0.

The data transferred using Modbus and Modbus Plus is roughly equivalent. You can send and receive inputs and coils, inputs and registers. There are also other operation codes in the protocol for diagnostics, or programming PLCs, or a number of other functions.

There are 3 types of connector routinely used for Modbus Plus. The AS-MBKT-085 inline connector takes a Modbus Plus cable and stabs the wires, to establish continuity. The 990NAD23000 Tap takes that cable and stabs the wire into a "tap", which connects to a moulded cable which connects to the device. The 990NAD23020 or 990NAD23021 Supertap doesn't stab the wire, instead using screw terminals to connect the Modbus Plus cable and the moulded drop cable.

Today I want to look at the AS-MBKT-085 inline Modbus Plus connector. We're going to look inside one.

The first thing you need to realize about these connectors is, they're not cheap. This store is selling one for 35 USD, and that's about what you can expect to pay. I've seen some online stores asking for twice that.

So, what are you getting for your money? Well, first, let's look at what this thing does.

Here, you can see a Modbus Plus connector with wires already crimped into it.

![](image1.jpg)

Normally, the shield grounds to the middle pad, and the wires are held in place by the plastic back, which is itself held to the connector with a screw.

The stabs which hold the wires are fastened to the connector with screws, so we'll pull them out.

![](image2.jpg)

I expected the connector to be welded shut, but it's actually held in place with 3 pegs which push into 3 holes. Once I had a point I could leverage, I could pry the connector apart.

So here's what we have: 3 metal block with a threaded hole, connected to a regular D9 connector.

![](image3.jpg)

Taking apart the connector further, I found that the ground is coupled to the chassis ground using a capacitor. That's all there is to it!

![](image4.jpg)

And how about those light grey plugs? The difference is that there's a 120 Ohm resistor across the data pairs. That's the difference.

![](image5.jpg)

Thanks for reading!


Unity Pro 8.1 Released

December 14, 2014 - Reading time: ~1 minute

I'm Jason Firth.

Because of an ongoing support issue we've been having, the folks at Schneider made sure to e-mail me about a point release of Schneider's Unity Pro software that was recently released.

 

Additions include:

-support for new M580 devices

-Device Integration improvements

-references

-implicit conversions (no more real_to_int and int_to_real everywhere)

-security improvements

 

Interestingly, Unity Pro 8.1 supports Windows 8.1 but not Windows 8.0. Windows XP is no longer supported either.

It's not mentioned anywhere, but there have been other bug fixes as well. I had a problem with animation tables when I built changes to the program, and installing Unity Pro 8.1 solved those problems.

We also had a problem where the program would slow to a crawl if the variable properties window (accessed by pressing ctrl-enter while a variable is selected) is open. This version solves that problem.

Thanks for reading!