Where do we draw the line?

[seth350]

Hey there,
So I have been developing a bar code/bom lookup using advanced hmi and some cognex bar code scanners. This project started out using a PLC, with aHMI being just just an HMI. Database transactions were being made through Factorytalk Transaction Manager.
That was a month or two ago...
Today, the PLC is no longer in the picture and neither is Transaction Manager. Everything is done in aHMI. Which made me wonder...where is the line drawn between controling a machine/process/whatever with aHMI or with a PLC?

Both can do much of the same, if not more than the other or easier than the other.

Where do you draw the line?

[billerl]

I hear what you're saying. AHMI is the most innovative useful thing I've seen in a while. I'm guessing when the scan time becomes an issue for protecting the machine from damage. I may be mistaken, but I don't think the processing speed of the PC compares to a PLC.

[Noe]

Also PC apps are not real time. If you do not require realtime processing, and your operation is not critical, and you have some I/O you can control from AHMI... then I would choose to do it that way. PLCs are dedicated to do one task, while a PC has to several while running YOUR task (your app). Crashes, viruses, hardware failures, operators doing bad use of PC equipment, are some other reasons to think about.

[seth350]

Your right, scan time or shall we say the ability to update an I/O in the least amount of time. We could draw a line there.

What about the all popular statement, "the pc is too hard to troubleshoot" or "the maintenance guys can't troubleshoot it/fix it", "KISS"

Could we draw a line at ease of repair? Or simplicity?

So maybe at the end of the day, you wouldn't draw one line, but many. In some cases, you could say that each line drawn would actually section off responsibility to who should worry about repairing it.

Sprungmonkey, that is also some valid points.

BTW, this is just an open discussion.

[Noe]

Yes, just sharing my two cents.

We have an application developed to run a process that closes some tubes at the same they are filled with gas and pre load is measured at the same time... All without a PLC. Problems show when there is a failure, as the app does not have any I/O monitos, lacks a lot of alarms or hardware information, and the process cycle is a mistery, is just a black box for us. Adding some of this is really expensive and the company said no. Just mentioning all this, beacuse you have to put a lot more effort on custom software, than with already developed tools for the industry (and with standards).

[seth350]

Good point about already developed tools.
What is interesting is that at first, in my project, the plc was the central control. As I slowly went down the rabbit hole in transferring control entirely to aHMI. While it does work, I am finding out that there is a cost or rather trade offs/cons in doing so.
For instance, due to the nature of tcp protocol, if a scanner is disconnected and then reconnected, the app no longer recognizes that the scanner has scanned something. I must disconnect and then reconnect. From my understanding, this is because a port was left open and the client does not realize that there is no longer a server to listen to. Typically if this were connected to a PLC, you would get an "I/O Not Responding" and once the server reconnects all is well again.

Needless to say, version 2 of my app will include the plc once again so that I will gain back the "already developed" features. Some might say, "just disconnect programattically and reconnect". Not that simple if your app has methods running in separate threads.

I suppose my real reason for creating this post was so that new comers would be informed and not go down the same rabbit hole as I have.