Author Topic: Com Component best practices  (Read 819 times)

shawn_75

  • Newbie
  • *
  • Posts: 8
    • View Profile
Com Component best practices
« on: October 04, 2019, 07:58:47 AM »
I have a number of identical PLCs that I'm controlling that I've made a user control for.  I currently have my com component on the main form and pass the PLC IP address that corresponds to the user control shown.  When I change to another instance of the user control for a different PLC, I'm passing the new IP address to the com component.  Is this an acceptable way to do this, or should I have a different com component with each instance of the user control?

Thank you!

Godra

  • Hero Member
  • *****
  • Posts: 1438
    • View Profile
Re: Com Component best practices
« Reply #1 on: October 10, 2019, 04:01:17 AM »
If you try both then you might realize on your own if one is better than the other.

shawn_75

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: Com Component best practices
« Reply #2 on: October 16, 2019, 10:34:04 AM »
I guess I should rephrase.

I have multiple panels as user controls, all needing to communicate with a Micrologix.  From panel to panel, the Micrologix is different.

The EthernetIPMicro comms driver sits on the main form.  There is only one driver in the whole project.  When I change from panel to panel, I pass the desired IP address to the comms driver based on which panel is shown.  This works just fine.  There is a slight delay when changing panels.

I hope this makes more sense.

Is this an acceptable way to use the driver?  Does this create any probles with system resources or socket connections that I may not yet be seeing?

Godra

  • Hero Member
  • *****
  • Posts: 1438
    • View Profile
Re: Com Component best practices
« Reply #3 on: October 16, 2019, 02:27:08 PM »
I will elaborate on that simple suggestion I made:

- Make a copy of your current project and just rename the solution file (the one with .sln extension, which will make it easier for you to distinguish between the two projects).
- Add a separate driver for each of your panels and point to correct IP address.
- If your panels are visible only one at the time then you can try using their Visible property to enable/disable the corresponding driver's subscriptions.
- Test it and try to compare it to your current project.

Since you don't have any issues with your current project then all this testing might be a brain exercise for you and eventually you might end up with a spare functional project which you can use if need be.

Archie has designed his drivers well and it should be only one's setup and the way they design projects that might affect the communication.

shawn_75

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: Com Component best practices
« Reply #4 on: October 17, 2019, 09:35:41 PM »
I appreciate the advice Godra, but I don't see how that will provide me with any information I don't already know.  It works when I give every PLC its own dedicated driver and it works when I pass new IP addresses to a single instance of the driver.  In my test setup, that has been a total of 3 different PLCs.

I looked for documentation, but the page for EthernetIPSLCMicro is blank.  I'm not going to try and decompile Archie's work to see how the driver works under the hood to see if this is a bad practice.  I know that it's pretty much a wash as far as programming time goes either way I choose to do it.

Again, I appreciate this community as it has helped me overcome many obstacles when developing with AdvancedHMI and am very thankful for everyone's help, especially Archie's work.

Godra

  • Hero Member
  • *****
  • Posts: 1438
    • View Profile
Re: Com Component best practices
« Reply #5 on: October 20, 2019, 12:42:40 PM »
See if this topic might provide any valuable info in your research of how Archie's drivers work:

https://www.advancedhmi.com/forum/index.php?topic=1549.msg15197#msg15197

There probably are some other topics in this forum that contain additional information.