I/O for chiller application

mihairosu

We use these iMods, and iStats too. It was recommended to us originally by Joel (from infinite automation).

They're easy to configure, and we can even remotely program them through the Mango server via a gateway. For the iStats (they have 1 serial port), we need to shut off the modbus connection momentarily while the program is uploaded, but the iMods come with two serial ports, according to them, independent of each other. Theoretically you can program via one port and continue to be on the modbus network with the other. However, I haven't gotten around to testing them, so I can't guarantee it 100%.

As far as integration into Mango go, apart from setting up the modbus network the way it works is, every point is in the Holding Register (40000) range.

Enter a register number in the "Reg No." field, then the Modbus address to request that point is actually -1. So a Reg No. 27 = Modbus register value 26.

0_1482865908373_upload-1686d383-7e1c-4d35-988a-8bead5a1d38c

So far we've been very pleased with them.

Programming is done graphically, though you can of course enter formulas manually into the function blocks.

0_1482866303952_upload-1034d7f7-b34d-4fc6-8712-e9a39bfc0b83

Benoit

Glad to see you have already become familiar with iSquared's products. The issue you've already discovered about not being able to monitor and update or communicate is one we've wrestled with and solved several different ways. The solution you found for using COM2 for monitoring and COM1 for programming will also allow you to use some of iSquared's more advanced or PRO version peer to peer communications over COM1 while still being able to monitor the iMod6 over COM2 with Mango. The only limitation is that you need to map out any points on the COM1 subnet to the iMod6 so that you can see them from Mango on COM2.

We came up with a clever solution which allows us to switch a TCP gateway adapter from COM1 to COM2 by using a DPDT relay which is controlled by a DO on the iMOD6 and which toggles the RS-485 connection to the gateway through the two poles of the relay. The default NC connection uses COM2 for the gateway and is called monitoring mode and the NO connection is used to enter into Update mode by switching to COM1 and disabling the SCAN block on the iMod6 so that Peer to Peer communications ceases while program updates are being made.

In our commercial projects where we have more $ to play with we have started introducing iSquared's INet embedded server appliance which acts as a Modbus router which enables both peer to peer communications and gateway operation to Mango simultaneously. One nice feature is that it offers a virtually unlimited program page on the embedded device which can be used for running supervisory programs and writing to various Modbus devices.

jeremyh

Hey Desmond,

(I think Benoit is neglecting to fully disclose something there..)

This should be pretty straightforward. You're looking for a "4-20mA (or 0-20mA) modbus I/O unit" - sometimes also referred to as a RTU. As you'd expect, they come in all shapes, sizes, and prices.

You'll connect your 4-20mA signal to the device, then you'll poll it with the MangoES over Modbus, and get your measurement. If you know your way around Mango it shouldn't take more than a few minutes to set up.

Units with RS-485 only will be cheaper, but can sometimes require a bit of messing about to get working the first time.

Units with Modbus TCP will have an ethernet interface and sometimes run a bit more, but they often have built-in web configuration and can offer more installation options (like different buildings).

Expect to pay $50-100 for a cheap basic unit, and 10x that for an ultra-reliable expensive unit with more I/O channels.

You can also put a PLC to work as an RTU, but generally (since there'll be a small learning curve associated with getting up to speed with the PLC programming environment) I'd say steer clear of this unless you know what you're doing.

Lastly, with current loop signals, you'll need to make sure you're not mis-matching impedances (or your measurements will be wrong), so check with the manufacturer if at all unsure. If you mismatch impedances you'll need to get an expensive signal conditioner device.

Hope this helps!

Benoit

Jeremy

If you look at my initial reply you'll see that I also advocated the use of a slave I/O device. However, in the next post Desmond informed us that he had purchased some of iSquared's PLC's and was already programming them. The thread then went into a discussion regarding the conflicts encountered when using ControlCore and Mango at the same time since only one master device or gateway can exist at any time.

Desmond

It is my duty to clear up the the misunderstanding.

First of all, Benoit has tagged me wrong. I do a quick search for user and found there are 4 user under common name Desmond. I have not purchase any iSquared PLC yet.

I am thankful for the experiences and recommendations from Benoit and Mihairosu. In fact it has broaden my perspective on the selection of third party products. istat and imods are compatible with MangoES but not interoperable. When things break, it is not easy to track the root cause. I really wish that mangoES hardware come with basic build-in I/O.

"Know what you want, Buy what you need"
Thank Jeremyh for sharing your view and the link. It is helpful and I have bookmark it.

In fact I want to deploy mangoES for plug and play product. Beside third party hardware, I am wrestle with the development of custom dashboard for the chiller application. My idea scenario is that upon the field sensors or instrumentation devices are wire together, there are minimum engineering time require to view the real time data via the mobile phone.

Is it feasible or has anyone done this path of thinking before?

Any suggestion or sharing will be appreciated.

mihairosu

First, I will share a quick experience in trying to find a historian solution. We are located in the United States.

We've explored other options before choosing Mango. I can't name names, but I can say the following:

One option would have cost us ~$10,000/year for the historian ALONE. I'm sure this one could have integrated with some hardware at a similar cost / year for their other products. So either way it would cost many tens of thousands of dollars in the software fees alone, not even including hardware purchases (which most likely would have been only the most popular i.e Honeywell, Siemens, etc $$$)

The other option would have cost us ~$23,000/year (plus ~$5,000 service fee with 3% annual increase) for the historian ALONE. This one had no direct integration with sensors, either.

The only one that came with "build-in basic IO" that I found was Ubiquiti's mFi range of products (which are currently discontinued). Their very small selection of sensors were discoverable over TCP/IP and automatically picked up by the free server software. They had some simple IO modules. However, my view was that it was not ready for an industrial setting. They used MongoDB so their databases grew to immense GB sizes relatively fast and their range of sensors was very limited and anything custom was a bit tricky to set up anyway. Their sensors would have been too expensive and clunky to really do anything serious with. You just can't beat industrial hardware for price and performance with anything "consumer" oriented.

If I understand your last question correctly, I would have to answer that, yes, every one has done this path of thinking before. We ALL want easy to deploy, easy to configure, easy to manage, easy to display information, easy to diagnose, etc. The only "easy" way out is to pay someone else who will do it for you. That's what all the big vendors do. Then it's technically easy.

Then when you pay someone to do almost everything challenging for you, you will have learned nothing of value, and every job you go to you will have to say "I don't really know how to do anything, but I can take a lot of your money and give it to someone else who will do it for me." Then why should you even be hired?

JoelHaggar

@Desmond The MangoES was designed in mind to add in IO. You can see in the second picture here: http://help.infiniteautomation.com/support/solutions/articles/14000023029-mangoes-connections

Inside the case is an expansion slot to add in IO cards. We still are intent to develop some IO cards to go inside and then also work in an external case. There are a total of 16 screw terminal so that could be 8 digital inputs each with their own ground or 15 with a common.

Ideally we can come up with a 8 universal inputs that can be used for 0-10, 4-20ma, Thermistor, Digital or pulse counting.

It would be useful to get some feedback of useful IO combinations.

Balistar

By far the easiest way to have Mango interact through Modbus with sensors and relays are Arduino or ESP2866 microcontrolers with sensors, relays, ethernet and Modbus IP.

I know that a $10 IO device wouldn't exactly leae you warm and fuzzy with confidence, but I have some of these things run uninterrupted for years, while some of my industrial Siemens IO gear has frequent hiccups...

jeremyh

@Balistar I set up an arduino clone (http://www.freetronics.com.au/products/etherten#.WGhkmbYrIWo) with a temperature sensor and was able to poll it using modbus TCP, but after some time (I'm unsure as it wasn't being polled the whole time) it became unresponsive. Any tips?

This is the Modbus TCP library I used: https://github.com/andresarmento/modbus-arduino

Balistar

I had more stability with https://github.com/luizcantoni/mudbus/tree/master/Mudbus