Announcement

Collapse
No announcement yet.

Progress Bar Help

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

  • #16
    Hi Tim,

    Can you try replacing your MagicCode0 with this.

    var lastRevs := 800;
    var Range := 800;

    func ImageSlide(var Baseimage var Coverimage, var range, var value)

    var xpos;
    var ypos;
    var height;
    var width;
    var step;

    xpos := img_GetWord(hndl, Baseimage, IMAGE_XPOS);
    ypos := img_GetWord(hndl, Baseimage, IMAGE_YPOS);
    height := img_GetWord(hndl, Baseimage, IMAGE_HEIGHT);
    width := img_GetWord(hndl, Baseimage, IMAGE_WIDTH);


    step := width / range;
    if(lastRevs != value)
    if(lastRevs < value)
    gfx_ClipWindow(xpos + (lastRevs * step), ypos, xpos + (value * step), ypos + height);
    gfx_Set(CLIPPING, ON);
    img_Show(hndl,Coverimage);
    gfx_Set(CLIPPING, OFF);

    endif

    if(lastRevs > value)

    gfx_ClipWindow(xpos + (value * step), ypos, xpos + (lastRevs * step), ypos + height);
    gfx_Set(CLIPPING, ON);
    img_Show(hndl,Baseimage);
    gfx_Set(CLIPPING, OFF);
    endif
    lastRevs := value;
    endif
    endfunc

    Best regards

    Paul

    Comment


    • #17
      If the order of your rev-counter images is different to mine it might be necessary to change the start value of lastRevs to 0.

      Paul

      Comment


      • #18
        Thanks again, Paul!

        I'll give this a whirl tonight and feed back.

        Tim

        Comment


        • #19
          Hi,

          I implemented your change, and whilst it seems to have made things better, it didn't solve the problem completely.

          I decided to attack the smart gauge builder again, and came up with something I was happy to use as a compromise, expecting performance to improve.

          Frustratingly performance was similar to that of the magicobject, so now I'm a little stuck. It seems to processing of high levels of data with a smart gauge is the issue, here are two videos, one with values being sent to the smart gauge, one without. The performance impact is most noticeable when I adjust values being sent via CAN.

          For reference the smart gauge is less than 10mb in size, and has a range of 0-100.


          https://www.youtube.com/watch?v=0686lwRZp64


          https://www.youtube.com/watch?v=e1cAUCat56s

          Had I not been able to get better performance out of a similar product, I suspect I would be willing to accept where I'm at. But this is a much superior product, so I'm really hoping I can get this cracked in order to move forward with my project.

          Thanks again for the help, and please make suggestions on how we progress with this.

          Tim

          Comment


          • #20
            Can someone help me understand, why sending values to a smart gauge would cause latency?

            Comment


            • #21
              Hi Tim,

              The process for displaying the smart gauge is to retreive the image data, 2 bytes per pixel, from the SD card and send it to the display. The Rev counter is quite a large image 96000 bytes and it is not so much how fast we can draw the image, which is really fast, it is only governed only by how quickly we can get the data from the SD card. That 1 frame process has to finish and then an ACK sent before you can issue another command.

              There is also a noticeable difference when using simulated data and real data. If you are sending simulated data that increments by one and then display it, it is very different to a real world scenario when the data may have changed by more than 1 between updates.

              There are other ways to reduce the time spent on a large Userimages. Looking at your rev counter it could be split up into 8 userimages and using a function you could just update the section that has changed which would reduce the time spent updating by roughly an 8th. If there was a massive change in the data the function would calculate how many of the 8 Userimages need updataing.

              I hope this helps

              Best regards

              Paul

              Comment


              • #22
                Hi Paul,

                You're right, I am yet to try this in a vehicle. However, the display is reacting to data being sent to it from a bench powered ECU. The ECU is outputting CAN data at 50hz, I have pots attached to a couple of ECU sensor inputs allowing me to adjust their values, and I also have a secondary Arduino which is running engine simulation software, and that too is sending values to the ECU. As test values go, it's pretty close to what you expect when the ECU is wired to a running engine.

                This evening I've done the following:

                - Compressed the green bar (layer?) image to a file size of 129 bytes
                - Increased baud from 200000 to 600000

                Not a great deal has changed, well not that the eye can tell. As you say It appears that the latency is in the drawing of the image rather than anywhere else. That's pretty clear in that everything else flies in comparison, custom digits work flawlessly.


                https://www.youtube.com/watch?v=4s0b8H1UkLU

                That's the very latest build.

                The Smart Gauge comprises of three layers, Base (https://i.imgur.com/ewXKELV.png), Layer 1 (https://i.imgur.com/VZT9rX9.png), Layer 2 (https://i.imgur.com/H70LFPi.png). I gave it 100 frames, it has a size of 9mb.

                I have the destination set to RAM, code size is 2946 bytes, approximate run RAM size is 2192 bytes. I don't feel as if I'm taxing the display, it's non touch, and currently a single form.

                A few questions:

                - Of the 3 layers which make up my Smart Gauge, I assume the only one I need to worry about the file size of is the one that actually moves?
                - As you can see from the video, as the bar is being drawn it does so in an unusual fashion, any suggestions with that?
                - Can I optimise the Smart Gauge any further? A suggestion of 8 different images was made, can I do that in the Smart Gauge, or would that need to be written as Magic Code?
                - I get that we are at the mercy of a I/O from the SD Card, but is there anything that can be done there? Load the very small image into RAM or Flash for example?

                As I keep saying, I feel really close to getting this as good as I expected / wanted.

                For what it's worth, I also dragged on a regular horizontal gauge to see how that reacted, it was choppy and slow, just like the smart gauge.

                Any help is very much appreciated.

                Thanks

                Comment


                • #23
                  Hi Tim,

                  It's not really about how the layers are made up, after the smartgauge has been made, it is 100 images of 800 x 60 pixels and in reality ends up the same physical dimensions and speed as the regular horizontal gauge you tried.

                  The unusual drawing pattern is due to being able to see the image being drawn. If we did split this up into 8 seperate image blocks that effect would most certainly be eliminated.

                  It would be possible to create the 8 image blocks in Smart Gauge, you would have to split your layers into 8 pieces first and create eight different Smart Gauges. We would then have to use the MagicObject and function again as each individual block would have 10 frames and we would have to do a bit of maths to determine which block needs to be updated. also if there was a large change in RPM we would have to determine how many blocks have to be updated.

                  As you said you are pretty close to getting the effect you want. Your Rev counter looks great and it is possible to get it to operate the faster. As it is, it is no slouch, I worked it out at over 25 frames per second.

                  If you are able to create the 8 blocks / Smart gauges I will happily modify the MagicObject / function to do the maths bit.

                  Best regards

                  Paul

                  Comment


                  • #24
                    Hi Tim,

                    When you make the 8 seperate Smart Gauges you are not limited to the amount of frames per block, you can in fact have them 100 frames each if you want, we can sort out a range in maths in the MagicCode function afterwards.

                    Paul

                    Comment


                    • #25
                      Hi Paul,

                      Just to confirm.

                      Can we (you, ha!) make a single magic object instead, or is it necessary to create 8 magic objects or 8 smart gauges?

                      If not, is it possible to export a Smart Gauge, or will I need to create a project containing them and send it over?

                      Thanks

                      Comment


                      • #26
                        Hi Tim,

                        Unfortunately you get to do the hardest work in making the 8 seperate Smart Gauges haha!

                        After you have done that you can the send the project over to me for the Magic code function to be done. If you prefer to send it privately you can use my email paul at 4dsystems dot com dot au

                        Best regards

                        Paul

                        Comment


                        • #27
                          I thought as much! But that's fine, my process is pretty quick.

                          I've attached the project here, happy for others to use this part of the project if they so wish.

                          I've created two sets of 8 Smart Gauges, one set have just a solid green "progress", the other have the progress with the red line at the end. Wasn't sure if we'd get undesirable results with the red line as it disappears at frame 0, so I've done one without to try as well.

                          Thanks again for all of your help, excited to see the results of this!


                          Attached Files

                          Comment


                          • #28
                            Hi Tim,

                            Can you please try this one, we can still tweak it if the maths are not quite right. We are using MagicObject0 again and the range is set for 800

                            Best regards

                            Paul
                            Attached Files

                            Comment


                            • #29
                              Hi Paul,

                              Apologies for the late reply, life got in the way this weekend!

                              I did manage to give it a quick test, and performance seems much improved. I'll do some more testing over the coming days and update this thread when I've done so.

                              Thanks again for all of your help.

                              Tim

                              Comment

                              Working...
                              X