# How can I make the Ignition Maker Edition adapt to the speed of data transfer between Kepware and the software (matlab) , so that the data is not lost and is displayed correctly in the Ignition Maker Edition curve? **URL:** \ **Category:** General Discussion\ **Created:** [September 30, 2023, 8:48am UTC](https://forum.inductiveautomation.com/t/how-can-i-make-the-ignition-maker-edition-adapt-to-the-speed-of-data-transfer-between-kepware-and-the-software-matlab-so-that-the-data-is-not-lost-and-is-displayed-correctly-in-the-ignition-maker-edition-curve/79878 "2023-09-30T08:48:46Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Mohammed\_Abbas](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Mohammed\_Abbas](https://forum.inductiveautomation.com/u/Mohammed_Abbas)\ **Post date:** [September 30, 2023, 8:48am UTC](https://forum.inductiveautomation.com/t/how-can-i-make-the-ignition-maker-edition-adapt-to-the-speed-of-data-transfer-between-kepware-and-the-software-matlab-so-that-the-data-is-not-lost-and-is-displayed-correctly-in-the-ignition-maker-edition-curve/79878/1 "2023-09-30T08:48:46Z")
hi , I hope you're well. I have been sending data between the software (running with a 1ms sample period) and the Ignition Maker Edition via the Kepware. server via OPC UA, but the data is arriving so slowly that I am losing most of it, and when I display it in a curve in the Ignition Maker Edition that does not match the curve in the software, How can I make the Ignition Maker Edition adapt to the speed of data transfer between Kepware. and the software so that the data is not lost and is displayed correctly in the Ignition Maker Edition curve? ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [September 30, 2023, 9:27am UTC](https://forum.inductiveautomation.com/t/how-can-i-make-the-ignition-maker-edition-adapt-to-the-speed-of-data-transfer-between-kepware-and-the-software-matlab-so-that-the-data-is-not-lost-and-is-displayed-correctly-in-the-ignition-maker-edition-curve/79878/2 "2023-09-30T09:27:33Z")
> [@Mohammed\_Abbas](#): > > have been sending data between the software (running with a 1ms sample period) Ignition's primary use is for SCADA systems generally using OPC communications (such as Kepware's OPC servers). Typical scan rates would be 100 ms for a reasonably snappy HMI interface, to as slow as is adequate for data logging. 1 ms scan time seems unrealistic. You will push requests into the queue and it will handle them as best it can. It sounds like you are trying to use it as a (medium-)high-speed data aquisition system instead. You might find this post helpful. > [@Scanclass max speed](https://forum.inductiveautomation.com/t/scanclass-max-speed/18104/4): > > It depends on load. Look at the actual statistics for the specific device, particularly the average response time. That’s the round trip request from Ignition/response from PLC. Then look at the load factor. Anything close to or above 100% means there’s not enough bandwidth (somewhere, usually the PLC) to satisfy all of the subscriptions at the requested pace (scan classes), slowing everything down. The more tags monitored, the slower it all gets. You can use the system.opc.\* functions to… ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [September 30, 2023, 10:12am UTC](https://forum.inductiveautomation.com/t/how-can-i-make-the-ignition-maker-edition-adapt-to-the-speed-of-data-transfer-between-kepware-and-the-software-matlab-so-that-the-data-is-not-lost-and-is-displayed-correctly-in-the-ignition-maker-edition-curve/79878/3 "2023-09-30T10:12:53Z")
Please do not cross post. - Cross posting is against forum rules. - It's like pressing an elevator call button repeatedly. The elevator does not arrive any faster. 😉 * * * I'll answer here anyway, as I like the title of this post better... From a design perspective, things requiring that fast of sampling would require - special hardware or run on a real-time system -or- - have a buffer \>= than the request size. Running with KepServer in between will exacerbate your issue, as it's one more thing eating up clock cycles on your PC. It looks like Simulink supports MQTT, and MQTT has less overhead than OPC-UA. That may be an option for you, as then you wouldn't need KepServer.