Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Controls Guy on June 04, 2020, 02:56:02 PM
-
Looking in the members inside $Main or other code block, there doesn't seem to be one element that gives total ticks consumed running that block, or scan time fraction, or anything like that. You can't use the scan counter or ran this scan, because a block with a small time slice and a lot of yield points may run often but not long each time.
The user might try recording elapsed ticks on entry and exit, but with yielding the entry and exit points will vary from scan to scan.
So far I haven't been able to think of anything. If there's no way currently, would you guys consider adding CPU fraction as an element of the heap item? Maybe a rolling one second average or something.
-
That would be worthy to have a tool that would give you the scan time of each module. I have done it several times and it is very helpful. Maybe current, Average, min, Max. However, I would want to be able to turn the monitoring on and off so as not to impact the scan time itself. I guess in some applications you could use the run bit in the trend viewer.
-
That would be worthy to have a tool that would give you the scan time of each module. I have done it several times and it is very helpful. Maybe current, Average, min, Max. However, I would want to be able to turn the monitoring on and off so as not to impact the scan time itself. I guess in some applications you could use the run bit in the trend viewer.
I thought about that but most of mine run most or all the time and control time slice with the time slice setting and/or frequent yields (usually explicit). The trend view only updates at 100s of ms rate minimum, so I need something that actually shows ticks or % elapsed while running the block.
How did you do it when you did?
And agreed, if there is an appreciable scan time impact for the monitoring, it needs to be able to be turned off. 99.44% of the time, you're not going to look at it.
-
I program in stage so I store TICKus() in the initial stage and and then store the value at different stages. I think that's what I did. Stages make it easier.
If you use interrupts, they already have it and latency in the code block properties. That was nice.
-
There aren't any interrupts in the program for functional reasons, but I was thinking about using them for this. Interrupt every 50us or whatever and increment counters based on which block is running, or something like that.
-
What about the matched register interrupts? Have the interrupt routine use the TICKus() and store values in some type of table that could be evaluated at the top or bottom of the scan. I have never used it, but there are 4 interrupts for it.
-
Sooooo....I'm guessing the Sim won't simulate interrupts, even timed ones? I know when not using the Sim, you can configure interrupts from the Dashboard. I can't seem to get the Sim to run in Model simulation mode, and neither the Dashboard Sim pic nor other interrupt config locations are available if DMD knows it's running on the Sim.
Also, locked up DMD (whitescreen) disconnecting from the Sim and had to kill DMD from Process Explorer. Haven't checked yet to see if there are dump files.
-
What do you mean, it worked. It interrupted Windows Explorer. :-\
-
Now, that's funny right there, I actually LOLed. ;D