Improve digital/analog output lag on Dewesoft hardware

I have Iolite R8 and Sirius digital output that are all very laggy, with 400 ms (best case) to 1.2 seconds (tied to alarms) delay. I have analog output on the Sirius, iolite, and krypton, there not super fast but can at least get some output in 200 ms time frame occassionally.

I have tested the digital output response in couple of methods, tying them to alarms, tying them to user inputs, tying them to math. I am measuring the response by routing the digital output into an analog input channel and external daqs. On the iolite the acquisition rate is 20ks/s not that it appears the digital / analog output are tied to the acquisition rate in any way

Is there anything that can done to decrease the lag or at least make it more consistent? Yes I understand these are not realtime systems, I work with RTOS systems and don't expect a few milliseconds control rates.

Thanks

Gary

Hello Gary,

The 20 kHz specification is for use with third party masters, though we've only had luck to get it running without issues at 5 kHz using Beckhoff TwinCAT. At 10 kHz it was intermittently dropping out for seconds or more, while the Krypton 1xAO had no such issues.

In general you have to distinguish between two modes that DewesoftX supports. Those are the asychronous mode and synchronous mode (function generator). The latter has fixed delay that can be predefined in settings, while async mode works faster but is not constant jitter. The modes are described in the SIRIUS manual in chapter: 5.25.4. Channel output. You can configure the the delay for sync mode in Settings:

If you're asking about the performance when using DewesoftX, you're limited by the fact that only asynchronous output is possible with IOLITE 16xAO and that by itself is limited by the hardware, CPU load, and the fact that DewesoftX will only let you set the acquisition update rate to max 1 kHz:

The function generator functionality does work over EtherCAT, but both the device and software need to support it. That is only the case with Krypton/IOLite 1xAO where synchronous output (function generator) is supported and working very well. Synchronous mode is also supported on SIRIUS units with AO channels on the backside or MULTI amplifiers. 

​

With a good CPU and low CPU load apart from DewesoftX, you can get close to 1 kHz update rate from the IOLITE 16xAO, but it can never be used for signal generation due to potentially big and very random jitter caused by the non-real time performance of software running on Windows. The in-out delay is relatively low in this case compared to fixed delay in sychronous mode.

​

BR, Matic

I have tested out the analog side extensively, I had great hopes for the function generator but it complete lack of any basic functionality means I basically just wrote my old version).

Can you address the digital output side, alarm delays and why it takes so long for user input to cause an update in a digital output as there there does not appear to be any settings other than acquisition rate under performance settings. Which can be changed but appears to have little effect on A0 or digital output performance and just appears to fill the screens with higher fidelity graphs and use up more processing power. Setting it to 1000 hz even with a fast core I7 rarely yields 400 hz even with no controls, no alarms, and no math. Adding any of these will usually mean that it drops to 100 hz but none of the outputs are actually running that fast. And of course if there are multiple measurement tabs performance on the Ao and Do is very bad, as it appears that dewesoft is trying to keep them updated even though they can’t be seen even though the screen performance should have no affect on that since cpu/gpu usage is extremely low around 10%.

I am not complaining as I new going in that the dewesoft systems could not do used in any critical applications as the control side was a basically an after thought so has numerous limitations.

Dear Gary,

If you can prepare a basic setup on how you configure the alarms (sample rate, channel definition, etc) we can analyze if we can achieve any better results. It would be very useful if you share a DXD where you measured the delays so we can compare.

best regards