New HMI

[ddubs2248]

Is Host developing a new HMI to replace Lookout Direct?  Something that is compatible with Windows 7 64 bit?  I love what you guys do and would much rather buy from you than NI, Wonderware, etc.

[franji1]

Sorry, no.

Have you looked at ADC's C-more panels?  They have a wide range of sizes/functionality/price.  They also support many other PLC manufacturers, in addition to the ADC PLCs (e.g. AB).

[ddubs2248]

Will there be a driver release to HMI manufacturers for the Do-More PLC?  Wonderware, Indusoft, etc?

[franji1]

No, just ADC's C-more HMI panels.  Most HMI vendors have Modbus/RTU and Modbus/TCP, which are both built-in the H2-DM1E CPU (Modbus/RTU is built-in the H2-DM1 (non-E) CPU).

[Controls Guy]

Seriously?  You're not going to let the native protocol out to all the MMI guys?

[BobO]

C-more is the only one to ask so far. It is very complicated, and for now, there is no protocol document. While I won't say absolutely no, I would prefer not to.

[ATU]

Believe me its probably much better that way. Unless the PLC is a big player in the market, the HMI vendor is not going to put out resources to fix your problem if one arises. Host can't afford to buy everyone's HMI and work out who's at fault when it doesn't work. Unless its all in one house, you get nothing but finger pointing. At least with Modbus being a generally accepted universal protocol, you have a chance to debug it and determine who to point the finger at. The user is caught in the middle.

[deep6ixed]

You could in theory use the do-more anywhere you had a driver for the DL series with the ability to map memory to the DLX/DLY/DLV ranges...

[BobO]

I would use Modbus over DL...but yes, you are correct.

[deep6ixed]

For those out there with some PHP skills, there is a PHP library that can support Modbus/TCP...  I could see custom HMI and even more advanced options such as data logging come from it.

[ATU]

Cool   I'm thinking home automation..  Got the link?

[deep6ixed]

http://code.google.com/p/phpmodbus/

It only supports some of the commands, but it does open it up for some interesting possibilities. 

[Controls Guy]

Believe me its probably much better that way. Unless the PLC is a big player in the market, the HMI vendor is not going to put out resources to fix your problem if one arises. Host can't afford to buy everyone's HMI and work out who's at fault when it doesn't work. Unless its all in one house, you get nothing but finger pointing. At least with Modbus being a generally accepted universal protocol, you have a chance to debug it and determine who to point the finger at. The user is caught in the middle.

Good point.  I would probably tend to use Modbus anyway even if the native protocol were supported, at least on products that might get redone with other PLC's or other HMI's.  That way there's a layer of protocol-agnosticism between the HMI and PLC that avoids linking the design irrevocably to either of them.  For one-time shot type projects it wouldn't matter as much.  Plus with the Modbus, you get the built-in comm sandbox, which is a good thing.

[BobO]

Mark and I were just discussing the possibility of designing an HMI-centric subset of our programming protocol that would be fully documented and exposed via a different IP port number. Maybe go so far as to allow each block and heap item as being visible through it our not, and beef up the security to a high degree. For now, though, I'm loving Modbus...it just works.

[ATU]

What I am personally experiencing is that when a problem arises, they can then connect their HMI to any Modbus supported device and verify for themselves the existence of their bug. It's a nice insurance policy, otherwise, your pretty much SOL.