Topics

1

Support Questions / Odd issue - Button colors changing after build

« on: September 02, 2015, 01:02:45 AM »

So I've had this issue with two different versions of VS (2013 and 2015 community) and two different versions of AHMI - starting to think I'm doing something wrong.

When using the Basic Button item and changing the colors it works as expected as seen here - http://i.imgur.com/E9YsLwg.png

However after building the solution they all change to the same color as seen here - http://i.imgur.com/TAoqgFa.png

In the actual built program, even after I do another build when the colors have changed, the colors are correct in the actual built program, it seems to only change them in Visual Studio's UI.

Is this a bug in VS or am I doing something wrong?

2

Support Questions / Upgrading existing project?

« on: October 20, 2014, 07:33:11 PM »

When a new release of AdvancedHMI comes out, is there an easy way to "upgrade" an existing project? In the past I've only had really small projects so when a new version was released I just deleted it and started over in the new project of AdvancedHMI.

However now I have a pretty big project going, when 3.80 comes out is there a way to upgrade it without starting all over?

3

Support Questions / ModbusRTU Major bug? Please help :(

« on: August 08, 2014, 07:19:20 PM »

So I'm starting a project using AdvancedHMI for the interface with a Click PLC, and for being the only truly free HMI software I could find, it's awesome.

Using the RTU driver to talk to the click, the connection works fine. I have AdvancedHMI successfully displaying an integer register (modbus address 400001) on a digital panel meter with no problems.

However the problems arise the second I try to read/write any other type of register, namely single bits (coils). I have several simple coils I'd like to read the status of and display as a light, but AdvancedHMI refuses to do it. The light is stuck on no matter what coil address I put in there (until I put it in a bogus address then it does nothing). For instance output 1 on the Click is modbus address 8194, and the read function code is a 01. I saw the post where you showed the code that chooses what function codes to use, and to make it use a read code of 01, I need to begin the modbus address with 0. So I've also tried 08194. But absolutely nothing works. Even putting in input address such as 100001 still results in it not properly reading them. The same happens when I try to write to coils that support being written to.

I found a couple sparse posts on this forum with people having the same problem, namely this post ( http://advancedhmi.com/forum/index.php?topic=320.msg1393#msg1393 ) where a user has discovered that for coils and such, advanced hmi is sending out 10 byte commands, when it should be 8? No matter what I do, it WILL NOT read or write to single bits. Please help! If there's anything I can do to help please let me know, this hobby project is dead in the water until I can do this or somehow find another HMI software that's actually free. Thanks so much! I promise to buy all the button/meter packs : )

Also a question I have, instead of using static code to use the first digit in the modbus address to decide what function code to use, wouldn't it be easier to allow us to enter the function code directly ourselves in front of the modbus address? I'd imagine the way it's doing it now severely limits compatibility. For instance the click plc coils that support function code 01, 05, and 15 mostly begin with 8 (eg 8195), however to get that function code out of advancedhmi, it wants to see a zero in front of it correct? Holding registers on the Click begin with 1 (eg 16390), but they are simple coils so they want a read function code of 1. However if advancedhmi sees it begins with 1, it'll try to use the read code 02. Just a thought! It seems to be that while evaluating the first digit in the modbus address to determine function code, it doesn't strip it away, so it still uses that entire number string as a modbus address