SV Camera Lag Issue

Hello.

What is your cycle utilization and cycle time on this application?

You can add a SIC (System information channel) and set it to show the utilization.

Having the utilization high will leave less time for the system to draw anything on the display.

What is drawn on the display is not included in the utilization usage, it is done with the time that is left.

The MD4 will always prioritise to run the application over drawing anything on the display.

It is also hard to give you a number on what constitutes a high utilization.

It depends on several things, the cycle time, the utilization, how big video you have and the bitrate.

They all add up

But lowering the bitrate should have given you a improvement, also lowering the resolution should have.

Hi,

Cycle time is 10ms.

Cycle utilisation is 50%.

In your experience, does this allow enough resources for a proper video feed?

Thanks,

Francois 

That would depend on the size and bitrate.

You said you had 800x600 and bitrate set to 4.

With those setting i get it to work with some tearing of the image, but still relatively smooth.

But i only had the video alone on the screen when i did that test so i can be worse for you, but still think it should be enough.

looking closer at the video you shared, i looks strange.

Not the same kind of lag as i see when there is not enough cycle time to draw the video.

What you see then is increasing severity of the image tearing.

Not the jumping that occurs in your video.

But the easiest way to test would be to increase the cycle time so see if that helps.

Or is there any reason you have it set as low as 10ms?

Looking at the cable you purchased.. Perhaps you are getting interference issues due to the unshielded cable, so you may want to try a shielded cable at that length. 

Thomas,

The cycle time on this unit is 10ms dued to safety CAN messages than needs to be picked up.

I will try setting a page with only the screen and no others graph on the display.

Cole,

As for the cable used, I will try changing the cable, but the same problem happened when I connected it directly to the port behind the MD4.

Thanks for your support,

Francois 

I'd say that a cycle utilization of 50% on an MD4 runing at 10 ms is a lot. 

One should be aware that the cycle utilization is only calculating the fraction of the cycle that is used for executing the real-time application. It is during the remaining 5 milliseconds that the MD4 can perform other tasks, such as rendering the graphics of the display pages.

It is also good to be aware that handling of the CAN traffic is the processes that has the highest priority, lots of incoming traffic will have the effect of increasing both the measurable cycle utilization, as well as the time it takes to perform other tasks at the end of the cycle. 

Would it be an option to use a separate controller for the critical CAN messages? If it is somehow related to safety of the machine control, I'd suggest an MC4xFS.

Gustav,

Thanks for your reply. Is there a tool to see where the process takes a lot of time? This would allow me to understand the best way to decrease the cycle utilization. I am wondering the impact of the following items on cycle utilization:

-CAN Msg transmit speed

-CAN Msg count

-Unused CAN signals

-Function group impact

Thanks

In general, the larger your function groups are in size, the longer they will also take to calculate. To get an overview of the size of the function groups, check the project statistics. This shows you an offline calculation of memory usage split up in function groups. The time to calculate it all will of course depend on the type of channels and calculation, but it could give you a rough idea. It is only if you have large portion of the application disabled that it will take up memory without also taking up processing time.

Incoming CAN messages does have an impact, but it is small, perhaps a few percentage units on the cycle utilization. 

For outgoing CAN messages, the parameter out channels are not calculated in the cycles when they are sent (since 5.00), but the impact of this optimization is even smaller. Before you can have so many CAN channels that this effect would be noticeable, you'd run into problems with CAN utilization. 

For version 6.00, we have been experimenting with adding a feature for measuring cycle utilization / calculation time on individual function groups. This would give more precise information. 

Gustav,

I can't seam to find out what is the size of each function group independently. When I go in the project statistics, I only see a function group count, but no memory usage. I attached a screen shot of the statistics, if you could take a look and see if think that some numbers are off, please feel free to share.

I am looking to resolve this cycle utilization problem and am wondering if the code hierarchy is the problem as we use a few function groups to split the code and simplify the reading, but does create a lot of FGIs.

Is there a prefered CAN bus to use for high traffic? I remembered reading somewhere that CAN-A and B are somehow different of C and D in terms of hardware.

Thanks

Ah, sorry, I did not think of the fact that the whole reason you asked about it was that it was an MD4 running at quite high utilization..  We never implemented the RAM memory estimation on the MD4. 

Some of the reason for this is discussed in another recent topic, here: 

https://forum.iqan.se/communities/1/topics/1611-comparing-hardware-computation-capability 

Yes, on the IQAN-MD4, it is recommended that you use one of the buses CAN-A and CAN-B as the Diagnostics bus. 

Looking at the statistics from your application, one thing that strikes me is that the proportion between function groups and channels compared to functions. In a mature application, I'd expect the later to be around 3-4 times higher. 

This seems to indicate you have a relatively high portion of channels that are not calculation channels. FGI:s is one example of a channel that doesn't have a function.  On one hand, channels without a user defined function are in general  faster to process. 

But on the other hand, everything counts. An FGI will for example make a range check on the signal, if you add or remove several hundreds of them and run a 10 ms cycle, you will be able to measure a difference of several percentage units on cycle utilization.

Another thing that strikes me is that for this size of application, I am used to seeing either a multi-master system, or an application cycle time closer to 40-50 ms for a single master MD4. 

You might be able to shave a few percentage units of the cycle utilization by making structural changes, e.g. by  making use of public scope channels, available in IQANdesign 5.

A direct improvement in IQANdesign 5.00 is that video in combination with other graphics is improved. (case 38012 in release notes)

But to really see a big difference in display page and video performance, I think you need to consider a multi-master application with an MC4x handling the 10 ms functionality, so that the MD4 can be set to a longer cycle time.