Created Date: June 23,2016

Created by: kewakl

I am back to the project that is related to a couple of my recent posts. ( Electrical characteristics of FA-ISOCON and CLICK 2.00 crashes after Write Project To PLC -- WinXP SP3 )

I have been informed that this station must have a way to log runtime (QA) data to a database on an associated PC. That would normally include a much more capable PLC.

I am thinking that I can read (via ModbusTCP) the values that I want.

The PC monitor program will have to set a bit to tell the Click that the monitor program is waiting for the Click to start its cycle.

The Click will then start its cycle - recording runtime data to C/DS/DD/DF whatever the required datatype.

At end of cycle, the Click will set a bit (Cycle Complete.) When the PC monitor program sees the End of Cycle bit, it reads the runtime data from C/DS/DD/DF as required.

After a successful read of whatever data must be recorded, the PC will set a bit in the Click that indicates that the data has been successfully read.

This will enable the Click to allow the QA tech to get ready for another cycle. - The Click cannot start another cycle until the data is successfully read - or a bypass code is entered.

I have done this using a PAC, so I think that I can do this with a Click. Since it is a limited set of data that I must collect, I think that a full blown Modbus library is overkill. I can build the Modbus requests and parse the responses in .net.

This should also remove any license issues with Modbus library usage and ensure that bugs in the Modbus controlset(as implemented) can be fixed in-house -- without long-distance phone/email support. EDIT: One other issue with existing 'compliant ' libraries is support for the whole range of Click Modbus addresses. (as forum member Gudmundur Ben mentioned here )

Comments and concerns are welcome.

Thanks

Created Date: June 28,2016

Created by: Mike@Forshock

If you have experience doing this before, it makes sense. If you would be doing a fresh code base from scratch, I would definitely look at "Off-The-Shelf " software such as Point of View (InduSoft) and the commercial HMI softwares that have all of these functions built in (Modbus, ODBC/SQL, etc.). The modbus library on POV is relatively stable. POV would also allow for logging into almost any SQL server (MS SQL, MySQL) for an easy to access historian.

POV is relatively inexpensive compared to the hourly rate to develop custom software just to get the comms working.

Created Date: June 28,2016

Created by: kewakl

Mike,

Thanks for your input.

I have given AdvancedHMI a try.

My IT guy can do the VB.net --> whatever dB suits his requirements.

It is a small project and a full scada/pov is out.

The QA tech station already has a capable PC setup to host AHMI.

It looks like AdvancedHMI will do the job. As is, the only area of the click address space that I know to be an issue is reading/writing DF500.

I/we think the AHMI modbus driver is trying to access past the end of the DF table.

I have not tested any TXT registers, but TXT isn't important to this project.

I haven't tested T, TD, CT, CTD, XD, YD. Again not important to this project.

I did find it interesting that in AHMI, I had to prefix a 0 to the C table registers, but NOT to the SC table. Maybe a six-digit address thing?

I don't recall the Y table having this requirement.