Application process priority defines the process priority of Dewesoft:
- Usually, Dewesoft should run on its own in the OS and, therefore Normal priority is enough.
- High priority allows Dewesoft to increase its performance if other processes are also running on the system.
- Real time is useful only in special applications. Even though thinking that real-time priority would be the best, but in reality, it might stall acquisition low-level drivers which must have enough CPU time. Setting Dewesoft to real-time would mean that tasks like displaying data on the screen would have to high priority.
- Use multiple cores is a very important function to split the data acquisition and math processing between different CPU cores.
- Acquisition update rate defines the preferred rate of acquisition loop. The graphics part was always a part of acquisition loop (data acquisition, calculation, storing, graphics). The graphics were drawn at the same time and that did not allow us to run a faster acquisition. Now, the graphics can be done in parallel. As the result, we could lower the priority of graphics part and have faster acquisition times. Average acquisition loop was running with about 50 Hz and now it can run up to 1000 Hz. Set the acquisition update rate higher if you want to have the faster reaction times.
- Display update rate option defines the preferred refresh rate of displays. With defining lower display update rate, we can reduce CPU load of Displays. If we change the update rate from 50 Hz to 1 Hz, the CPU load of displays dropped from 30 % to 1 %. This is very useful when we are on the limit with our computer CPU.
- Decoupled acquisition and UI option are enabled by default. This option will use the dedicated thread for acquisition. One core will be used for acquisition and one core will be used for the user interface.
Memory sizes are important to run the software correctly for a different application. There are sizes which need to be defined for:
- Sync DB - This is the memory size in seconds for all synchronous channels (analog, counters, …). The value should be larger than the maximum refresh time - 2 seconds is the default.
- Async DB - This is the memory size for all asynchronous channels (CAN, GPS, and many others…). The default value is 50 seconds.
- Video Memory - Size of the video buffer; with lots of cameras the default 128 MB value should be reduced to half, for example not to run out of system memory.
Enable Freeze buffers should be enabled if we plan to use Freeze mode (to see data during the measurement).
When we enable it, the Freeze button is seen during the Measure mode.
When storing the data, you will see a special Freeze button. This is a sign for Grandview, enhanced freeze mode. Grandview allows the user to review stored data from the start of a measurement without interrupting data acquisition and storing process. The user is able to zoom into any region of data already stored on disk during the measurement and review any type of signal including video, which makes (long-term) measurements easier to manage.
- AO buffer length - when you use the Function generator function in Dewesoft, the software sends the data to Sirius. Sirius waits for the amount of AO buffer length (in our case, this is 1 second) before it starts to output the signal. This has to be done, to prevent data loss. By default, the buffer length is set to 1 second.
- Fill samples when the buffer is more than __ % full. Let’s say that we have a buffer of 2 seconds. The samples will be sent when the buffer will be filled with the defined amount of percentage (at 2-second buffer, 50 % means, that it will wait for 1 second). By default, the value is set to 50 %.