Announcement

Collapse
No announcement yet.

C-More EA9 Multistate Bitmap not behaving as expected

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


  • C-More EA9 Multistate Bitmap not behaving as expected

    I am trying to setup a graphical piping layout on a EA9-T15CL-R and I am having trouble with the Mutlistate Bitmap objects.
    I have selected "Displayed Images are based on: Bit Number" for all my multistate bitmaps.

    Click image for larger version

Name:	Capture0.PNG
Views:	1
Size:	86.0 KB
ID:	118921

    Now I will show two different segments of pipe, setup two different ways, and explain how I am expecting it to work.

    Left Pipe Segment:


    Click image for larger version

Name:	Capture1.PNG
Views:	1
Size:	86.9 KB
ID:	118922

    Right Pipe Segment:

    Click image for larger version

Name:	Capture2.PNG
Views:	1
Size:	76.7 KB
ID:	118923

    These two bitmaps are looking at the same tag ("PL01_PIPEPATH_MODULATING") and I'm expecting that if I write the following values to that tag, I will get the expected results, but instead these are the results:

    Click image for larger version

Name:	Capture6.PNG
Views:	1
Size:	20.5 KB
ID:	118925



    The errors read "Bitmap _X_ not programmed," Where "X" is the decimal number that I have written.

    Here's some examples of what I'm seeing:

    Click image for larger version

Name:	Capture5.PNG
Views:	1
Size:	62.5 KB
ID:	118924





    Am I doing something stupid or is this a glitch?
    The Multistate bitmap object gives you the option to display images based on Bit Number or Image Number. I'm choosing Bit Number, yet the errors I'm getting seem to indicate that behind the scenes it's still going off of Image Number. It seems that the only thing that changes when you select Bit Number, is that you limit yourself to 32 images and now instead of easy-to-remember image numbers like 1, 2, 3, 4, 5, 6, ... you have to use the less intuitive 1, 2, 4, 8, 16, 32, ... scheme. Is it unreasonable to expect this to work? Why use bit numbers if you can only ever have 1 bit of a word high at a time? Doesn't that defeat the purpose? Or am I just doing this wrong?




  • #2
    It looks like only one bit can be active in the word at a time.

    From Help File
    Bit Number would be selected for an image to be displayed when a specific Input is activated.
    For example, a set of access/occupancy switches that are assigned bits of a word in PLC memory (the Tag Name address), will display a unique image based on where someone enters the facility.
    The bit that is active in the Tag Name will select the corresponding image.

    ***Note*** that the Tag Name must only have one active bit.
    If the Tag Name value has more than one active bit then the Non-Programmed Bitmap Action will display.

    Comment



    • #3
      Looking at the a control using bits 1, 2, 3... if the 32 bit word had both 1 and 2 on, then the control would not be able to tell which to activate.
      It would be a program dependency to keep the 32 bit word in a state that would not allow any two bits on a single control to be active.

      Comment



      • #4
        Originally posted by RogerR View Post
        It looks like only one bit can be active in the word at a time.

        From Help File
        Bit Number would be selected for an image to be displayed when a specific Input is activated.
        For example, a set of access/occupancy switches that are assigned bits of a word in PLC memory (the Tag Name address), will display a unique image based on where someone enters the facility.
        The bit that is active in the Tag Name will select the corresponding image.

        ***Note*** that the Tag Name must only have one active bit.
        If the Tag Name value has more than one active bit then the Non-Programmed Bitmap Action will display.
        I could have saved myself some time in posting this if I RTFM . At least I would have known that it's intentional.
        But I still would feel justified in complaining about it some.

        Originally posted by RogerR View Post
        Looking at the a control using bits 1, 2, 3... if the 32 bit word had both 1 and 2 on, then the control would not be able to tell which to activate.
        It would be a program dependency to keep the 32 bit word in a state that would not allow any two bits on a single control to be active.
        I could handle that. I want to write known integers to my control word that turn on known bits. No math, no room for an errant invalid integer resulting in two conflicting control bits being on at the same time. And if I did screw up, then we can display an error. I don't understand why this 1-bit-only restriction would exist. Is this an idiot-proofing measure? Just let me be an idiot, I'm good at it.

        I now have to figure out a different direction to go with this after spending nearly 8hrs laying out this piping diagram. I am more than a little frustrated.

        Comment



        • #5
          I know the feeling...

          Maybe to keep the plc/screen work that you have done so far, just change the tag for each set of controls that were using 1-3, 4-6, etc.

          Comment



          • #6
            Originally posted by RogerR View Post
            I know the feeling...

            Maybe to keep the plc/screen work that you have done so far, just change the tag for each set of controls that were using 1-3, 4-6, etc.
            Yes that's what I ended up doing. Had to double-click, select, paste tag name, change "Image based on" radio box, open image tab, change several image numbers, etc. on 183 different tiny bitmaps. Would have been a whole lot easier if I could just drag a box and select all the little buggers and then change their tags and image types all at once in the Property List pane, but there are only a few properties it will let you modify in that pane, and TAG, "Image based on," and Image # are not among them.

            Comment

            Working...
            X