Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - patrick.n

Pages: [1]
1
USAGE TIP:  When Using Different Drivers

EthernetSLCMicro... driver will only read the PLCAddress eg N7:0 so only use PLCElementBitWidth = Integer_16bit. 

EthernetCLX driver:  works best if you create an array of INT (16bit) eg MyIntArray[3] then set PLCAddress = eg: MyIntArray[0]

   

2
Application Showcase / Re: Sample App - Alarming with Status & History
« on: April 21, 2021, 10:28:53 PM »
Bettery ways?  Maybe, maybe not.  I created this app to mimic FactoryTalk ME.  AHMI can do alarming (kind of), but there is no history, which is a huge oversight in my opinion.  My apps needed to have history... retentive on power cycle.  I used a combo of SQL and flat files to do active and historical alarms. 

Honestly, I would ask Archie why he hasn't done this on his basic app.  He's been quiet the last year or so.  Busy I guess, but haven't we all?

So, just to be clear:    MajorFault = SamePersonAs( ByRef Phrog30)?

Like very much what you (or Phrog30) have done - a lot of functionality apart from Alarming with history.

Are you happy to field a few questions on what you have done ? 


3
Application Showcase / Re: Sample App - Alarming with Status & History
« on: April 19, 2021, 06:59:21 PM »
Phrog30 is no more.  This is an old version, maybe a year old or so,
https://drive.google.com/file/d/1cFJOS-DsbskwFAag11eDf-qQkprhWdwV/view?usp=sharing

Multi monitor is broken and I think PLC descriptions are broken as well.  But, you can use the INI file for description.  If you want to test without changing anything, use L8x 192.168.1.11 and array HMI_Alarm_Array length of 20.  The buttons will toggle some alarms for you.

You will have to build.

Thanks for response MajorFault,   Has the world moved on from this template?  Are there better ways of doing Active Alarm Lists with Alarm History mimicking the way it's done in FactoryView / PanelviewPlus and this template?

4
Application Showcase / Re: Sample App - Alarming with Status & History
« on: April 19, 2021, 10:02:58 AM »
Phrog30,  Just found your template for Alarming with History.  Look very interesting. 
Trying to test it with CLX using Alarms[0] (DINT) as an array if bit triggers to display messages from .ini file.
But, as a Noob got lost in your code.

Rather than troubleshooting, just wondering if you have a version of your template setup for CLX?

And/Or/Else, a setup/changes checklist for this template.

Cheers

5
Open Discussion / Re: Make Global object
« on: April 15, 2021, 10:19:34 AM »
NOTES ON USAGE:  Seems you can't put AHMI Controls within a container such as a TableLayoutPanel as part of your GroupObject design. 

Doing this breaks the code which concatenates the PLCAddressUDT and the PLCAddressxxx within AHMI Controls placed in the GroupObject.

I other words, seems AHMI Controls need to be "contained" by the Form or GroupObject (class) directly. They cannot be buried deeper into a hierarchy of other containers such as TableLayoutPanel.......I think this is the right terminology to use.

OTHERWISE: to use layout containers in GroupObjects, the AHMI Controls must directly reference the PLCAddress and you forget about using the PLCAddressUDT mechanism.

This renders the GroupObject less usedful - better than Cut&Pasting (at least you can still do global modification by altering just one object) - but not as flexible as RA GlobalObjects with their tag placeholders.


6
Tips & Tricks / Re: Main Menu Driven Project Structure in V3.99s
« on: October 03, 2019, 09:46:29 PM »
All driver instance using one common transport all use the same connection - Brilliant!

Things very clear now.  Excellent job you've done with this.

7
Tips & Tricks / Re: Main Menu Driven Project Structure in V3.99s
« on: October 03, 2019, 08:39:51 PM »
Thanks for the explanations Archie.

It's been really helpful.

To just to summarise: - a sample app has 5 forms:

-therefore there are 5 driver instances - one on each form
-each driver would consume one CIP connection of the device we're talking to.  (????)
-through code snippets you put on each form, you can control whether a hidden form stops or continues polling device
-through the code snippets you can thus manage the traffic burden your HMI places on the device

8
Tips & Tricks / Re: Main Menu Driven Project Structure in V3.99s
« on: October 03, 2019, 10:23:11 AM »
Ok. That's clear.

So a further question if I may...

Is it a .NET scope thing or similar technical issue that restricts developing an application with one comm driver object on Main Page and  subsequent Forms utilizing that same Comms driver obj?

Perhaps its a problem with propagating events between forms?! 

9
Tips & Tricks / Re: Main Menu Driven Project Structure in V3.99s
« on: October 03, 2019, 07:30:51 AM »
Thanks for prompt reply, Archie.

Not sure I understand what you mean...What happens to the comms driver on a hidden screen?  And how does a comms driver on the main screen help?

Sorry for the newbie question. Keen to understand what's happening under the hood. Hope its quick and easy to explain.

Cheers
Patrick

10
Tips & Tricks / Re: Main Menu Driven Project Structure in V3.99s
« on: October 01, 2019, 10:10:11 PM »
Does this approach mean you only require one Comms Driver on the Main Form (which will also serves additional Forms)? 
Or does each form require its own instance of a Comms Drv?

(Is this approach still "best practice" as of Oct-2019?)


Pages: [1]