Announcement

Collapse
No announcement yet.

Idea for CMore

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts


  • Idea for CMore

    I have spent most of this week editing tags for a big project.
    I have 6 duplicate (nodes) PACs (P3Ks) which are supervised by a P1K. I have mentioned this in previous posts.

    Each node has several hundred tags which we find very useful to be able to observe on a CMore.
    Some of the data is real-time, some is occasional.
    I have used the 'abstract' method that I have used for some time.
    But, as mentioned in the linked post, this can be untenable. I have spent many hours simply changing a group of tags from something like this [ R1{CV}_CALC_V_001 ] to something like this [ R5{CV}_CALC_V_001 ]
    This works fine for objects that can expose their tags to the Property List dialog. Some objects do not expose all tags to this dialog - MultiState Text Object, for example. I must drill down into the embedded tag list and edit each tag individually.
    On several screens, I have between 40 and 100 MultiState Text Objects. On the 40 count screen, each object has 4 embedded tags. 240 tags to manually edit per screen.
    On the 100 count screen, the object has no embedded tag, just one tag for multiple Foreground/Background coloration styles.

    A couple posts have made requests for parameterized tags, replaceable tags or similar (1 2 3.)
    I had a thought on a similar concept that already exists in cmore. --> similar to %[device name]_DISABLE%
    I am not a cmore dev so take this for what it is worth...
    I was thinking that in the Screen Option dialog for each screen we could have '_SOME_' replaceable parameters (think DEVICENAME from the Panel Manager)
    In the Tag Database,
    ---add another option to the 'Device Name' dropdown. Call it '<ABSTRACT>' then we would have to select a protocol - like Productivity family
    ---add support for %1 to %9 (however many the '_SOME_" means a couple lines above ^ ) (%1 to %9 think DOSBOX batchfile replaceable parameters)
    In the tagname, the %1 .. would eventually be replaced by a devicename that is equated to a replaceable parameter in the Screen Option dialog.

    Without twenty seven eight-by-ten color glossy photographs with circles and arrows, I don't think that I can give this idea justice in this post.

    -more to come


  • #2
    The Replaceable Parameter could work something like :
    If the DeviceName is PAC_01 and the tagname is %1AlarmReset_BTN at Device PAC_01--->C_0000001 then
    while the HMI is on a screen with the Replaceable Parameter setting %1=PAC_01
    With parameter replacement, then the tag would evaluate to PAC_01AlarmReset_BTN in PAC_01 at C_000001
    If on another screen, this Replaceable Parameter setting could be a different and the tag would evaluate to something different - or not at all.

    One thing, this would put some pressure on the CMore software USER to ensure that these (replaceable parameter) tags make sense.
    I don't know how the software would enforce that the tags and the Replaceable Parameters work together.

    If my understanding is correct, this parameter replacing could happen solely in the compiler on the PC.
    If my understanding is correct, this idea would NOT require any hardware/firmware change and could be applied to *most* any EA9 HMI.

    Comment



    • #3
      Variable array indexing is one form of "abstraction". However, this does require that the PLC variables are defined properly so that they are accessible via an array, and not a simple tag. Whether I use "text" or a "number" as the "indirect" mechanism is an implementation detail from the PLC programmer's perspective. That is a very powerful construct, as you validly point out.

      If you've ever used interpreted programming languages (e.g. BASIC), they are much slower than compiled languages (say C). And some forms of BASIC had the ability to do what you are looking for, where I dynamically create a text string whose text contains a BASIC program variable name, and then I can indirectly access that variable via this text string. That is even SLOWER since it must resolve a string to a variable location in memory (along with its dynamic type). Since BASIC is interpreted, it has all that information available (although it's much slower).

      A C-more HMI has no direct access to these variables (like BASIC on a PC) - it must use a communications protocol to access the memory in a completely different computer (i.e. the PLC, which can be A/B or PxK or Do-more or . . .). The C-more configuration software generates the low level communication information based on the "tag" information, and that low level comm information is what is written as part of the tag database in the C-more panel itself. It makes for VERY FAST communications (i.e. the C-more panel just sends requests and gets back data in a known form based on the original static tag, like size/data format).

      If it must become a generic text parser/data handler, either at the panel level or the PLC level, that complicates the communication mechanism greatly.

      But with variable array indexing, you get the best of both. An array is a homogenous set of strongly typed (pre-defined size/format), with just a variable "memory offset". Computers are excellent at doing that. Whether it's the C-more reading the array index and doing the simple calculation for the actual data address, or the comm protocol itself supports variable array indexing natively, that one level of indirection at the C-more panel is extremely powerful.
      There are 10 kinds of people in this world, those who know binary, and those who do not.

      Comment



      • #4
        Originally posted by franji1 View Post
        ...
        Thank you for the detailed response. I welcome the discussion.
        Yes, I have used several variants of the BASIC language. PC (text and graphical) and a couple embedded variants (stamp, picaxe.)

        I agree that CMore HMI does NOT have direct access to the intended comms partner's address space, however, the editor does have access to the tag database as defined by import/export, user data entry...

        I have not put into any post all of the things that I think would be required for this idea to be feasible. I am sure that there are things that I do not know which could render this idea moot.

        The C-more configuration software generates the low level communication information based on the "tag" information, and that low level comm information is what is written as part of the tag database in the C-more panel itself.
        If the compiled project has any 'generic/local' address space available for each screen to use as 'local storage', the compiler could build these low level comms [addresses, pointers, indexes ... whatever they are called] and make these 'items' available to the screen which would have a replaceable parameter requirement.
        The screen that I am developing seems to have about 36MB total (my project memory dialog shows 28.6% at 11.43MB)
        I would guess that the Modbus frames (if that is the selected protocol) are most likely built by the compiler and the HMI simply does a send/receive with a little bit of data validation.
        In my idea, the compiler would still do this - even for the replaced parameters - then the HMI would still be working within a compiler-defined comms framework.
        Last edited by kewakl; 08-23-2019, 08:36 AM.

        Comment



        • #5
          almost seems like doing a "find/replace all" based on a query of the tag database would do it, though the changes would still require uploading to the panel.

          Comment



          • #6
            Originally posted by quaizywabbit View Post
            almost seems like doing a "find/replace all" based on a query of the tag database would do it, though the changes would still require uploading to the panel.
            Maybe a 'Ranged' find/replace similar to the find/replace in PAC - on a per-screen or per-object basis - including all the (embedded) tags that are not directly accessible from the Properties List.

            The uploading to the panel is a given - and does not bother me. The 'highly manual' process that I have just finished (I hope) took most of the week - did bother me.
            See attachments for reference. There are 6 screens of each attached image.
            The 'Runtime' screen has 100 sets of screen objects - 1 per D. U. T. each set includes one button, one circle, one multistate text, one animated bitmap. - the bitmap acts as a mask to make the square MSText object appear to be round. The button acts as a selector for an individual unit. the circle is the indicator for the selection. The MSText uses one S32 tag to select a message which indicates the status of the unit - by color.
            So 100 units, 2 bit tags, one numeric is 300 tags. - just for the 100 units.
            Then there are extras above and to the side.
            The Dynami namic Text is really two dynamic texts one overlays the other for different font size of the SAME tag.
            The Dynam OLOLOL displays the voltage and current (or OVERLOAD) for the selected DUT

            --------- and that was the easier of the two screens.
            The 'CV' screen is for calibration/verification of the 100 DUTs.
            Mechanically, the internals of the oven rack is 3 plates of qty 30, q/ty 40 and qty 30 for a total of 100 DUTs.
            There is so much desired data to display, it was broken into a structure like the mechanical internals. On the screen there are 40 sets of objects. Each set includes on rounded rectangle, one MSText, one numeric display and one static text. For a row of DUTs one numeric display.
            The left column has a visibility tag the is TRUE if the 40 qty plate is selected.
            The MSText has one numeric tag (internal to the HMI) that selects message 0. This message has 6 embedded S32 array tags. The numeric display has one S32 tag that causes it to display a DUT position number depending on which plate is selected. Same with the static text - it shows which CalVerification block is relates to which DUT positions.
            The round rectangle indicates a fail of the unit position of the calverify routine.
            --------- The MStexts do not expose the embedded tags to the Property List, so it is open object, edit edit edit .... close object editor.


            TL/DR: hundreds of tags per screen. some editable from propertylist, some not.
            Oh, this is 2.78, so the embedded tag edit is different depending on whether you are editing the first tag or a subsequent tag.
            Attached Files
            Last edited by kewakl; 08-26-2019, 10:35 AM.

            Comment

            Working...
            X